Current State
Prior product lessons, with the Joan layer still being assembled.
Project
Joan
The convergence: prior project lessons becoming one product direction.
The convergence: prior project lessons becoming one product direction.
Product directionBuilt project historyJoan
Flagship Case Study
The Product Idea Behind Joan
Joan is the product direction for the part companies are missing: capture what happened, keep the useful context, and bring it back into the next meeting, workflow, or decision.
This project shows the product idea behind Joan: keep the record of how work actually happened, then use it to make the next piece of work better.
Where the gap is
Teams keep rebuilding context, losing corrections, and starting cold when the work moves across tools, people, and models.
What had to be true
The product has to capture work, keep corrections, show evidence, and push useful context back into the places people already work.
Why it matters
The value is not the chat. The value is the company getting better at its own work instead of starting over every time.
Positioning Lens
Joan
The product starts with revenue and meetings because those workflows expose the problem quickly: context gets lost, corrections disappear, and follow-through lives in too many places.
Signature platform decisions
- Converged several prior projects into one clearer product direction.
- Made context, corrections, evidence, and reuse the core product language.
- Set revenue as the first domain while leaving the kernel portable to meetings, teams, and future worker paths.
The Problem
What problem was worth solving?
I build things to solve a specific pain, not to decorate a portfolio. This is the pressure that made this project necessary.
AI work is getting more capable, but the useful context is still scattered across chats, tools, files, meetings, CRM, and people's heads. Joan is the direction for pulling that work history into a product the company controls.
The Build
What I built around the problem
ATOM defines the build model; Joan is where that model becomes software for context, memory, evidence, review, and handoff across the tools people already use.
Architecture 1
ATOM gives the map: tools above, systems of record below, work and review in the middle.
ATOM gives the map: tools above, systems of record below, work and review in the middle.
Architecture 2
Joan turns that map into product work around memory, evidence, connectors, review, and agent management.
Joan turns that map into product work around memory, evidence, connectors, review, and agent management.
Architecture 3
The page separates what has already been built from the broader Joan direction still being assembled.
The page separates what has already been built from the broader Joan direction still being assembled.
Reality Check
Joan is the direction the prior work keeps pointing toward
The point is not to pretend the work was clean. This is what the project taught, where it changed shape, or where the boundary still matters.
01
What has been hard
The hard part is making the memory useful across meetings, revenue work, workers, approvals, and the systems people already use.
02
What had to change
Several earlier builds had to be folded into a cleaner product direction instead of being presented as separate finished wins.
03
Current boundary
Joan is active and emerging. The page should show the convergence clearly while staying honest that the broader product is still being assembled.
Value
What changed because it existed
This is the practical value of the work. Where a project is unfinished, shelved, or still changing, the value is tied to what it actually taught.
Product role
ATOM + Joan
ATOM is the model and Joan is the company/product direction.
Built history
Prior builds
Meeting Sidekick, SalesSidekick, VibeOS, WorkspaceOS, SignalClaw, and other systems show the pattern behind Joan.
Boundary
Emerging layer
The broader Joan product is still being assembled, while the existing projects show the pattern behind it.
Technical Layer
How the system is built
This is the implementation behind the work: the architecture choices, integrations, controls, and workflow decisions that made the project real enough to learn from.
Architecture across capture, memory, review, and reuse
ATOM model across AI tools, work execution, review, and systems of record
Product lessons from Meeting Sidekick, SalesSidekick, VibeOS, WorkspaceOS, and SignalClaw
Memory layer for decisions, corrections, receipts, skills, workflows, and agent behavior
Enterprise controls for policy, approvals, exceptions, auditability, and portability
Microsoft-aligned deployment direction: Microsoft 365, Graph, Azure, Azure OpenAI, AI Search, and Key Vault
Build Story
How the thinking unfolded
This is the reasoning path behind the output, not only the finished artifact.
01
Problem definition
The work starts from a concrete operating problem: the convergence: prior project lessons becoming one product direction.
02
System shape
Prior product lessons, with the Joan layer still being assembled. The public page focuses on the product vision, architecture, and current signal.
03
Current representation
Project media will be added after the reviewed creative assets are approved.
Evidence
What this project shows
This evidence is strongest when it is tied to specific work rather than broad claims.
Product direction
Product direction
Built project history
Built project history
Joan
Joan
Continue
Want to go deeper?
Ask the Latif AI Guide about the architecture, the commercial logic, or the hard lessons behind this project.