Most useful products do not begin with a complete specification. They begin with a founder describing a painful workflow, a team asking for “a dashboard”, or an existing system that has become too risky to touch. Ambiguity is not a reason to wait. It is the first thing to design around.
My delivery workflow is less about ceremonies and more about reducing the cost of being wrong. Each step should turn a vague assumption into something visible: a decision, a thin working path, a production observation, or a clear reason to change direction.
01 / Constraint
Translate the request before estimating it.
“Build an invoicing dashboard” is a request. It does not explain who needs it, what decision they cannot make today, or which existing systems constrain the answer. I start by rewriting the brief into four lines:
- User: who has the problem and what context are they carrying?
- Job: what must they be able to complete or decide?
- Constraint: what business rule, integration, or legacy state cannot be ignored?
- Release condition: what observable behaviour means the first version works?
This exposes disagreements while they are still sentences. It also separates the part the business truly needs from the interface somebody happened to imagine first.
02 / Walking slice
Prove one path through the whole system.
The first milestone should cross the real boundaries: interface, validation, domain rule, persistence, external service, and deployment. It can be visually plain and narrow in scope. What matters is that it exposes the difficult integration points before dozens of screens depend on them.
A walking slice also gives the team something concrete to critique. Product feedback gets sharper when people can use a real flow rather than debate a diagram.
03 / Decisions
Write down why, not every meeting.
Documentation becomes noise when it tries to preserve the entire conversation. The useful artifact is the decision and its pressure: what we chose, what alternatives mattered, which constraint drove the choice, and what would cause us to revisit it.
Decision: store invoice totals at issue time
Why:
- issued documents must remain reproducible
- tax rules and product defaults may change later
Revisit if:
- the product introduces explicit document revisionsKeep these notes beside the system they explain. A short record near a migration or module is more likely to survive than a polished document nobody opens after kickoff.
04 / Delivery
Ship increments that answer a question.
A useful increment is not “backend 80% complete.” It is a working behaviour that can be reviewed against the release condition. Each slice should answer a product or technical question and leave the main branch in a releasable state.
Weak progress report
Finished services, started frontend, database almost done.
Useful progress report
A manager can approve one request end to end; audit history and notifications are next.
Tests follow the risk. Calculation rules, permissions, tenancy, payment state, and data migrations deserve strong automated coverage. A static marketing panel usually does not. The goal is confidence in change, not a flattering coverage number.
05 / Handover
Production is a beginning, not the last task.
A release is incomplete if only its author knows how to operate it. The handover should explain environment setup, migrations, external dependencies, failure signals, routine support actions, and the decisions that are expensive to reverse.
I also leave a short map of the next likely work: known trade-offs, deferred edge cases, and areas where usage should determine the design. That is more honest and useful than pretending the first release eliminated uncertainty.
Good delivery does not remove every unknown. It makes the remaining unknowns visible and cheap enough to handle.