Product Planning & Roadmaps
Most software projects do not fail because the code was bad. They fail because nobody agreed what was being built, so scope grew quietly until the budget ran out with nothing shipped.
Product planning is the work that prevents that. It produces a document you can hand to any development team — including one that is not us.
What a Planning Engagement Produces
| Stage | Output |
|---|---|
| Problem definition | Who has the problem, what they do about it now, and what has to be true for them to change. Written down in a page, not a deck. |
| Scope boundaries | An explicit list of what is out. This is the document that protects the budget, and it is the one most projects skip. |
| Sequencing | What ships first and why. Ordered by what removes the most uncertainty, not by what is easiest to build. |
| Costing | Each block estimated separately, so you can cut scope without renegotiating the whole engagement. |
| Success measures | What you will look at after launch to decide whether it worked — agreed before anyone writes code. |
Deciding What Goes in Version One
The useful question is not "what should the product do" — it is "what is the riskiest assumption we are making, and what is the cheapest way to test it". If the risk is that nobody wants this, a landing page and a payment link tests it faster than an application. If the risk is that it is technically hard, build the hard part first and nothing else.
This reorders most roadmaps considerably. Features that feel essential often turn out to be assumptions nobody has questioned, and the login system almost never needs building in week one.
Why Scope Documents Have to List Exclusions
A scope that lists only what is included leaves everything else ambiguous, and ambiguity always resolves in the direction of more work. Writing "no mobile app in phase one, no multi-currency, no admin reporting beyond X" is uncomfortable to agree and saves the relationship later. It also lets you price honestly, which is why our project quotes are itemised rather than a single number.
Who This Is For
- Founders who have been quoted wildly different prices for the same brief — usually a symptom of an unclear scope.
- Businesses that have started a build and lost track of what "done" means.
- Teams that ship steadily but cannot explain why they chose this quarter's work.
Related: product management consulting for ongoing prioritisation, and startup consulting if you are at the idea stage.