Why build in phases at all
The alternative to phases is to specify everything, build everything and launch everything. It appeals because it promises a complete product and a single budget. It fails for a simple reason: the plan is written at the moment you know least. Requirements are guesses about what users need, estimates are guesses about effort, and both are tested only when real software meets real people. A single large release delays that test until the money is spent.
Phasing moves the test forward. A first phase puts something small in front of users quickly. What happens next tells you which of your assumptions were right, and the second phase is planned with that knowledge. Phasing also protects the budget. If the idea proves weaker than hoped, you stop having spent a fraction. If it proves stronger, you invest with confidence.
What makes a good phase
A real phase
- Ends with software that someone can use for a real task
- Answers a stated question about users, value or feasibility
- Small enough to finish and evaluate in a predictable period
- Leaves the system in a state you could live with if funding paused
- Has a clear measure that decides what happens next
A phase in name only
- Phase one is the database, phase two the screens
- Nothing usable until the final phase
- Phases defined by budget instalments alone
- Each phase depends on a later one to be worth anything
- No one can say what would cause a change of plan
The commonest mistake is to slice by technical layer: build all the foundations, then all the logic, then all the interface. Nothing works until the end, so nothing is learned until the end. Slice by user outcome instead. A first phase that lets one kind of user complete one task, end to end, on a thin version of every layer, is worth more than a perfect foundation.
Choose what goes first
- 01
List what you do not yet know
Will people use it? Will they pay? Can the integration with the old system work? Is the core calculation feasible? Write each uncertainty down.
- 02
Rank them by consequence
Which, if the answer were no, would end or reshape the project? Those belong at the front.
- 03
Find the smallest release that tests the top ones
One user group, one workflow, the minimum integration. Our comparison of an MVP and a full product discusses how small is small enough.
- 04
Include the riskiest technical piece early
If a difficult integration or an unproven technique underlies everything, prove it in the first phase, even crudely. Leaving the hardest part to last is how projects fail late.
- 05
Leave out what can be done by hand
Administration screens, reports and automation can often be handled manually at low volume. Build them when volume justifies it.
- 06
Define how you will judge it
The measure, the target and the date, agreed before the phase starts.
Sequence the later phases
| Ordering principle | Put earlier | Reason |
|---|---|---|
| Learning | Whatever answers the most consequential open question | Later phases depend on the answer |
| Value | Features that the most users need most often | Benefit starts sooner and builds support |
| Risk | Hard integrations, performance limits, regulatory approvals | Bad news is cheaper early |
| Dependency | Things other features cannot work without | But only the minimum of them |
| Cost of delay | Items tied to a date: a season, a contract, a regulation | The deadline will not move |
| Reversibility | Decisions that are easy to change can wait. Hard ones need evidence first | Avoids locking in too soon |
These principles pull in different directions, and that is the point of writing the roadmap with the people who fund and use the product. Record the reason each item sits where it does. When circumstances change, the reasons tell you what can move.
How much detail, and how to budget
Plan in decreasing detail. The next phase is specified closely enough to estimate and build: users, workflows, screens, integrations, acceptance criteria. The phase after is a list of outcomes with rough sizes. Beyond that, the roadmap names themes and intentions. Detailing phase four today is wasted effort, because what you learn in phases one to three will rewrite it.
- 01
What is committed, and what is indicative?
Budget questions to settleA firm budget for the next phase. Ranges for later ones, clearly labelled as estimates that will be refined.
- 02
Is there a reserve?
Budget questions to settleEach phase will surface something unexpected. A stated contingency, used openly, is healthier than padding hidden in every estimate.
- 03
What does running it cost?
Budget questions to settleOnce phase one is live, hosting, support and fixes continue while phase two is built. Include them.
- 04
Who approves the next phase, and on what evidence?
Budget questions to settleNamed people, a review meeting and the measures agreed in advance.
- 05
What happens if a phase is not approved?
Budget questions to settleThe product must remain usable and supportable as it stands, and the agreement with your supplier should allow a pause.
- 06
How is the team kept together between phases?
Budget questions to settleLong gaps lose the people who know the system. Plan reviews so that a decision is made before the current phase ends.
A worked example
A roadmap for a training provider's platform
This example is invented to show phases ordered by what needs to be learned. A training provider wants a platform where companies book courses for their staff, track certificates and receive renewal reminders.
- UncertaintiesWill corporate clients book online instead of by email? Can certificate data be imported from the old system, which has no interface? Will clients pay extra for renewal tracking?
- Phase oneBooking for existing corporate clients only, with invoices still raised by hand. Includes a trial import of certificate records for three clients, to test the old data. Measure: share of bookings from invited clients made online within the first two months.
- Phase two, in outlineCertificate tracking and renewal reminders, if the import proved workable. Otherwise, certificates start fresh from the launch date.
- Phase three, as a themeSelf-service for new customers and online payment. Details to follow from what phases one and two show.
- ReviewAfter phase one, most invited clients book online. The import works for two clients and fails for the third, whose records are inconsistent. Renewal tracking is the feature clients ask about unprompted.
Phase two is reshaped: renewal tracking moves to the front, and old certificates are imported only for clients with clean records. The original plan had put online payment second, which no client had mentioned.
Review each phase, and change the plan
- Hold a review at the end of every phase. What was delivered, what the measures show, what was learned about users, effort and technology.
- Compare with the question the phase was meant to answer. A clear yes, a clear no or still unknown. Unknown means the phase was too vague, or the measure was wrong.
- Decide explicitly. Continue as planned, continue with changes, pause or stop. Each is a legitimate outcome. Drifting into the next phase without a decision is the one to avoid.
- Re-estimate. Actual effort in the finished phase is the best evidence for sizing the next. Update the ranges honestly.
- Rewrite the roadmap. Move, add and remove items, and record why. A roadmap that never changes is not being used.
- Tell everyone. Users and stakeholders who were promised a feature in a later phase need to hear when it moves, with the reason.
Stopping after a phase is not failure. A first phase that shows the idea does not work has saved the cost of all the others, which is exactly what it was for.
Phasing when you work with a development company
Phasing changes the commercial relationship in your favour. You commit to one phase at a time, and the company earns the next by delivering this one. A sound arrangement fixes scope and price, or a tight range, for the next phase, gives indicative ranges for later ones and lets either side pause between phases with a clean handover. Ask in the proposal stage how the company handles a change of direction after phase one, since the answer shows whether they plan for learning or only for delivery.
Keep continuity in mind. The first phase should be built to be extended, with the repository, accounts and documentation in your hands from the start, so that later phases can go to the same team or another. Our guides to the software development RFP template and to evaluating software development proposals show how to ask for and compare phased proposals.
Roadmap checklist
Phased roadmap checklist
0 of 11 checkedWhat to do next
Write down the three things that would have to be true for your project to succeed, and which of them you have evidence for. The one with the least evidence and the largest consequence is what your first phase should test. Then ask what the smallest usable release that tests it would be.
A product discovery workshop produces a roadmap of this kind with estimates, and our startup MVP development page explains how we build first phases. Tell us what you are planning.
Common questions
How many phases should a software roadmap have?
As many as it takes to keep each one small enough to finish and judge. For most business systems that means a first release followed by a few further phases, with only the next one planned in detail. A roadmap listing a dozen fully specified phases is a single large plan in disguise, since the later ones will change.
How long should a phase be?
Short enough that you learn something before much money is spent, and long enough to deliver something usable. The right length depends on the product and team. If a phase cannot produce working software that users can try within a predictable period, it is probably sliced by technical layer and should be cut again by outcome.
Does phasing cost more than building everything at once?
Per feature, slightly, because each release needs testing and deployment. In total it nearly always costs less, because features nobody needs are discovered before they are built, estimates improve with real data and serious problems surface early. The single large build looks cheaper only on the assumption that the original plan was right.
What if stakeholders want everything in phase one?
That is the usual starting position. Ask which uncertainty each requested item resolves and what happens if it waits. Show the date and cost of a first phase with everything, beside a small one. Most stakeholders accept a later phase for their feature when they can see the sequence, the reason and a review point.
Can we change supplier between phases?
You should be able to, even if you never do. It requires that each phase ends with the code in your repository, documentation for building and running the system, and accounts in your name. A supplier confident in their work has no objection, and the option keeps both sides honest about quality.