Build the Tool Your Team Needs
Day #15 of AI for PMs: One Day at a Time
There is a moment in a session where a problem stops being described and starts being built. It does not arrive when you say what you want. It arrives when you can say — precisely — who needs to see what, in what state, and with what permissions. That is domain knowledge crossing into architecture. It is also the only part that no model can do for you.
The Almost-Backlog
Most internal products fail not because the need is unclear but because the translation cost exceeds the perceived value. Every step — the spec process, the interpretation cycle, the prioritisation queue — requires the person who understands the problem to re-explain it to someone who can build it. By the time the overhead is justified, other priorities have moved ahead.
The products that survive are important enough to justify it all. Everything else sits in a permanent, almost-backlog: wanted, referenced in meetings, never scheduled. Not because no one cares. Because the translation layer killed them before they started.
The Workshop
Last month, I ran an AI workshop for the fraud teams at Booking.com. The format was deliberately hands-on — everyone in the room working on a real problem from their own work. My co-organiser and I wanted the session to feel like the actual practice, not a demonstration of it. For myself, and as the live demo for the room, I chose something that had been in the almost-backlog for a while — an internal solution for a commercial team in my organisation, understood clearly by everyone who encountered it, scheduled by no one.
React frontend. FastAPI backend. Role-based access for three operator types. Four request workflows. Built live, in the room, in a single session.
The Practice
The session had a shape I now rely on every time I build from scratch. Start with the domain, not the code.
Before any architecture, answer three questions out loud — as a conversation, not in a spec:
What are the entities? Not the screens, not the features — the things the system actually tracks and acts on.
What states do those entities move through? What triggers each transition, and who causes it?
Who can see and do what? Not “there are three roles” — what each role genuinely needs to see in each state, and why.
This is what breaks when you skip it. You describe what you want in product terms — “a dashboard where operators can manage requests” — and the model builds something plausible. Routes exist, components render, data flows. Then you check whether the right person sees the right state at the right moment, and the answer is: not quite. Role logic is slightly off. A state transition fires at the wrong point. You are no longer reviewing accuracy — you are reconstructing the domain inside a half-built system, which is a different and harder problem.
Once those three questions are answered precisely, the construction follows in a sequence with its own logic:
Data model first — everything else depends on what the system tracks. API routes next — their structure maps directly from entity states. Auth middleware third — access logic must sit at the layer where it can enforce. Request flows — by now the system knows what exists and who can touch it. Frontend last — the simplest part, once the domain is correctly modelled.
Throughout, I was not writing code. I was reviewing it for domain accuracy. Does this role see the right states? Does this request flow match how the team actually works? Not “does this compile” — does this reflect the domain correctly? The model handled construction. I handled whether what it built was correct. Fifteen years of product and engineering work turns out to be good preparation for exactly that kind of review.
What Changed
When I handed the first working version to my team, the conversation shifted in a way I had not fully anticipated. The question was no longer “what should this system do?” — that was already in the code. The conversation became: Does this model hold up to edge cases we have not seen yet? What does hardening look like at each layer? What needs to be instrumented before the first deployment goes live?
The domain knowledge was no longer in my head, waiting to be translated into a spec. It was in the system. My team could interrogate it directly.
My team has since picked up the work. First production deployment is planned for the APAC region.
The New Capability
You can convert deep domain knowledge about a needed internal product into working software — in a single session — by directing construction rather than writing code. The constraint that kept that product in the almost-backlog was translation cost. When the person who understands the problem can also close it, that cost disappears.
The Apply
The practice runs on a single input: a completed domain context file. This is the thing to build before you open Claude Code.
Create a file in a new project folder — call it CLAUDE.md. Fill in the following:
# Domain Context — [Your Project Name]
## Entities
What does this system track and act on?
List each entity and what it represents.
Example: Request (a submission from a team member),
User (an operator with a defined role)
## State Transitions
What happens to each entity over time?
For each entity: what states exist, what triggers
each transition, and who causes it?
Example: Request → SUBMITTED → UNDER_REVIEW
→ APPROVED / REJECTED / ESCALATED
## Role Permissions
Who can see and do what, in each state?
For each role: which states are visible,
which actions are allowed.
Example: Reviewer — sees UNDER_REVIEW;
can move to APPROVED or ESCALATED;
cannot see SUBMITTED queue
## Build Sequence
The model will follow this order. Do not skip layers.
1. Propose data model — review for accuracy before proceeding
2. API routes — structure maps from entity states
3. Auth middleware — access logic at the enforcement layer
4. Request flows — per role, per state
5. Frontend — last, once everything above is correct
If you can fill this in clearly, you are ready to build. Start the session with: “Read the CLAUDE.md in this folder. Propose the data model. I will review it before we proceed.” Do not describe what you want. Let the domain context do that work.
If you cannot fill it in, the problem is not ready. Write until it is. That is not a blocker. It is the most useful thing the practice reveals.
Something shifted in the workshop room that I did not expect. Everyone was building their own problem — not a toy exercise, not a tutorial example. By the end of the session, a few people had working data models for things that had been sitting unbuilt for months. The domain knowledge did not get faster to articulate. It got externalised. Once it was in a file, it no longer belonged exclusively to the person who wrote it.
That is a different kind of change than speed. The almost-backlog shrinks not because one person builds faster — but because domain knowledge that used to live in someone’s head becomes something the whole team can read, challenge, and build on.
Day #16 lands Tuesday, 19th May 2026.
— Vaibhav