Scope the release, not the roadmap

Most product conversations start with a feature list. The list is usually honest about ambition and vague about sequence. Six weeks later, the team is building the third priority while the first one still has not been used by a real person.

The fix is not a longer discovery phase. It is a smaller promise.

Write the release in one sentence

Before wireframes, before a repository, write one sentence:

A [specific person] can [do one meaningful job] without [the current workaround].

For BundleWala, the sentence was: a Pakistani prepaid user can find the best plan for their SIM, see the activation code, and compare two options without opening five carrier websites. That sentence excludes accounts, social features, a web dashboard and half the settings screen. It also makes the first screen obvious.

If the sentence needs the word "and" three times, it is probably two releases.

Keep three lists, not one

A roadmap hides decisions. These three lists force them:

1. Must ship — the product is not useful without it.
2. Can wait — real, but the first release survives without it.
3. Not now — explicitly out of scope, with a reason.

The third list matters most. "Not now" is not a rejection; it is a promise that the team will not quietly spend three weeks on it because someone mentioned it in a meeting. Write it down and revisit it at the next release.

Find the riskiest assumption

Every product has one assumption that can invalidate the rest. It is rarely the UI. It is usually one of these:

• the data exists, is legal to use, and is clean enough;
• a third-party integration behaves the way the docs claim;
• users will do the extra step the product depends on;
• the content can be produced at the quality the design assumes;
• the economics work at the expected volume.

Spend the first week on that assumption, not on the design system. For BundleWala, the risky assumption was data quality: five carriers, inconsistent plan names, shared activation codes and offers that expire silently. The first build was a catalogue and a normaliser, not a chat screen.

Put a clock on the unknown

A spike is a timeboxed answer to one question. It is not a prototype you quietly promote to production.

Write the question, the time limit and the decision it unlocks:

Can we page the whole catalogue from the API in under one second on a mid-range phone? If yes, the launch refresh can fetch everything. If no, we ship the bundled seed and refresh in the background.

Then stop when the clock stops. A spike that runs for two weeks is a project with worse planning.

Make the scope changeable

A release plan should have milestones that can be cut from the end, not a single big-bang date. Each milestone should leave the product in a usable state:

• M1 — the catalogue renders from bundled data.
• M2 — search and filters work on that data.
• M3 — the live API refresh replaces the seed.
• M4 — compare and favourites.
• M5 — accounts and sync.

If the deadline moves, you can ship M3 and still have a product. If the plan is "the app", you have nothing until the end.

What this looks like in practice

A recent engagement started with 34 screens in a Figma file. We shipped 11 in the first release. The other 23 were not deleted; they were moved to a list with a trigger for each one ("after 50 weekly active users", "after the first support request about X"). The first release went live in six weeks, and the next two priorities came from watching people use it — not from the original file.

That is the point of a release. It buys information. The roadmap can wait for better information.

A template you can copy

For the next project, fill this in before opening a design tool:

Release sentence:
Primary user:
Job to be done:
Must ship:
Can wait:
Not now (and why):
Riskiest assumption:
Spike question + timebox:
Milestones (each independently shippable):
What would make us stop:

If the team cannot agree on the sentence, the problem is not the backlog. It is the product decision. Have that conversation first.