The thing your customer needed.
The value you were after.
The reason you started.
We look at the work the way the people it serves meet it. What they are trying to do, where it gets hard, and what they would notice if it changed.
What would be different, for whom, and how we would know. Written down before anything is designed, so you can judge the work against it.
The understanding stays with your team. We work in the open, use words everyone shares, and leave you able to carry on without us.
It is the same whether the thing is a service, a product or an automation.
In the order you will live it.
Thirty minutes about your situation: what happens now, what you have tried, who it is for. No brief needed. You leave with a straight view of whether there is useful work here.
If it is simpler than what we offer, or someone else’s job, we say so and point you there.
Before anything is designed, we look at the work as the people it serves meet it: who they are, what they are trying to do, where it gets hard. We name the value in plain terms, what would change and how we would know, and agree with your team what matters first.
Sometimes the honest finding is that part of it should be left alone. All of it is written down and yours. The Map Room is the fuller version of this step.
What we will do, what you will get, what it costs and what we need from you, in writing. Nothing starts until you say so.
The person who designs the screens is the person who builds them, so what was decided is what ships. Prototypes come early and are tried with real people and real cases. The smallest useful version goes first.
Anything that reaches your customers or your team has your approval before it does. The record of decisions is the status update, not a meeting about it.
The system, its operating guide, the reasoning behind it and the training your team needs. We check the value we named at the start against what is now true.
Then it is yours. Build the next thing with us, or with anyone.
At every step. A conversation does not commit you to a scope, and a scope does not commit you to a build.
Nothing goes to the people you serve, or to your team, without your approval.
The map, the measurements, the specifications, the system and the reasoning. Yours, whoever builds next.
The work page holds the cases we can show, each with what changed and what it does not prove.
See the work ↗No. A few lines about what happens now and what you want to change are enough to start a conversation. We can shape the brief together.
Yes. The Product Bench brings priorities and specifications alongside your builders. Agent Machines can focus on a defined job within your existing systems. The first conversation helps us find the useful boundary.
No. It is the fuller version of the understanding step, useful when the choice of work is still unclear. If you already have a well-defined job or need ongoing product judgement, we can begin there.
Then that is the answer. Some work is better left alone, and a written reason is worth more than a system you would take out in a year. You keep the map either way.
Yes. The thing changes; the way of working does not. Your customer first, the value in plain terms, your people in the work.
A stubborn bit of work. A product worth building. An idea you haven’t quite found the words for. Start there.
Let’s talk it through ↗