Product delivery, end to end
Delivery starts where discovery ends: with an idea that has survived testing and a reasonable belief that it will move the outcome. The job now is to turn that idea into something real people use, without losing what made it worth building along the way.
This note is an overview. The stages that most often go wrong have notes of their own.
The stages
- Shape and specify. Write down what is being built, why, what is out of scope and how you will know it is done. See Writing the spec.
- Slice and plan. Break the work into thin pieces that can each be released on their own. See Slicing the work.
- Build, with review as you go. Design review, code review and quick checks against the acceptance criteria while the work is fresh, not at the end.
- Test and harden. The parts that are easy to postpone: edge cases, accessibility, performance under realistic data, security, and what happens when something it depends on fails.
- Release gradually. Put the change in front of a small group first, watch, then widen. See Releasing and measuring.
- Measure and learn. Check whether the outcome moved, then feed what you learned back into discovery.
On a small change these stages can take an afternoon between them. On a large one, each might take weeks. The sequence is the same either way.
Definition of done
Teams argue about whether something is finished more than about almost anything else. A shared definition of done, agreed once and applied to every piece of work, removes most of that argument. A reasonable starting point:
- acceptance criteria met and checked by someone other than the author;
- code reviewed and merged, automated tests passing;
- works on the devices and browsers the product supports;
- basic accessibility checks done;
- monitoring in place for anything that could fail quietly;
- support and other affected colleagues know what is changing.
Notice that “released to everyone” and “outcome achieved” are not on the list. Done means ready to ship safely. Whether it worked is a separate question, answered later.
What the product person does during delivery
It is tempting to think the product side of the work pauses once building starts. In practice, delivery is where small decisions pile up fastest, and a product manager who disappears for three weeks returns to find a dozen of them made by default.
The useful things to do are unglamorous: answering questions quickly, so nobody is blocked waiting for a decision; protecting the scope, so the work does not quietly grow; checking early versions against the original problem; and preparing the release — documentation, announcements, support notes — so it is not a scramble at the end.
Discovery does not stop either. The next outcome, or the next opportunity on the map, is being explored in parallel.
Where delivery usually goes wrong
Scope that grows a little every day. Each addition is small and reasonable. Together they double the timeline. A written spec with an explicit out-of-scope list is the best defence.
Edge cases found at the end. Empty states, permissions, very large accounts, unusual data. They are cheaper to find in the spec than in testing, and far cheaper than in production.
The big-bang release. Months of work switched on for everyone at once. When something goes wrong, it goes wrong for everybody, and it is hard to tell which part caused it.
Nobody looks at the numbers afterwards. The team moves on to the next thing, and nobody ever learns whether the last one worked. This is the most expensive mistake of the lot, because it makes the next round of discovery less informed than it should be.
Small and often
If there is one principle behind good delivery, it is that small changes released frequently are safer, easier to understand and quicker to learn from than large changes released rarely. Almost every practice in the following notes — slicing, feature flags, staged rollouts — is a way of making changes smaller.