Written by
The Bit Laboratory
Filed under
Strategy
Most scoping conversations start with a list and end with a compromise. Someone reads out thirty features, the room argues about which fifteen are essential, and a date gets attached to whatever survived. The list feels rigorous because it is long. It is usually the least rigorous artifact in the project.
A better first release is not the smallest version of the eventual product. It is the version that answers the questions you cannot afford to be wrong about, in the order that they threaten the plan.
Name the questions, not the features
Every new product carries a handful of open questions. Will this workflow actually replace the spreadsheet people trust? Does the integration expose the data everyone assumes it does? Will a clinician accept a suggestion from a system rather than a colleague? Each question has a cost if answered late and a cheap way to answer it early.
- /Which assumption, if wrong, changes the architecture?
- /Which assumption, if wrong, changes the business case?
- /Which assumption, if wrong, changes nothing important?
- /What is the cheapest honest test for each of the first two?
The third category is where most roadmaps quietly spend their first quarter. Polishing settings screens, building administration tooling, generalising something that has one known user. None of it is wasteful in principle, all of it is premature before the first two categories are settled.
Pick the workflow you will take all the way
A first release should do one complete thing extremely well rather than eight things partially. Completeness is what generates real usage, and real usage is the only reliable source of the information the next release depends on. A half-finished workflow produces polite feedback and no behaviour change.
One workflow taken all the way teaches you more than eight taken halfway, and it costs less.
Choosing it is straightforward once framed properly. Which single journey, if it worked beautifully, would make someone change how they work on Monday? That is the release.
Write the exclusion list and circulate it
Scope boundaries that live in someone's head are not boundaries. We publish an explicit list of what version one will not do, with a note on when each item is expected to return. It reads like a limitation and functions like protection: late additions become visible decisions with a visible cost, rather than assumed courtesies absorbed by the team.
It also changes the tone of stakeholder conversations. Nobody is arguing about whether something matters. They are choosing where it sits in a sequence, which is a much easier conversation to have calmly.
Estimate the shape, not the hours
Hour-level estimates on unresolved work are elaborate guesses in a respectable format. What is genuinely knowable early is shape: how many distinct data objects exist, how many integration boundaries have to be crossed, how many roles see different views of the same record, how much of the work is regulated. Those counts predict effort far better than a task breakdown built before the design exists.
- /Count the objects in the domain model
- /Count the integration boundaries and who owns each one
- /Count the roles with genuinely different permissions
- /Count the workflows that must survive an audit
Decide what launch means before you build
Teams that define launch as feature completion tend to ship late and evaluate never. Defining it as a measurable condition instead, a specific group performing a specific task without assistance, keeps scope honest all the way through. It gives the team a reason to say no in week six that everyone agreed to in week one.
Scoping done well is not about restraint for its own sake. It is about sequencing the work so each release earns the information, the trust, and the budget the next one needs.
