The first version of a product is where most of the budget is won or lost. Teams that try to build everything on the list spend a year and launch something large that nobody has yet used. Teams that cut too carelessly launch something that cannot be trusted. Good scoping sits between the two, and it is mostly a matter of asking the right questions in the right order.
Decide what the first version must prove
A first version exists to answer a question. Will these users change how they work to use this? Will customers pay for it? Can the hard technical part be done at acceptable cost? Write the question down. Every feature is then judged by whether it helps answer it.
One user, one job
Choose the single most important type of user and the one job they most need done. A booking product for clinics might start with the receptionist making and moving appointments. Patient self-service, reporting for the owner and billing can follow.
Then write out that one job as a complete path, from the first screen to the result. The path has to work end to end. Half of three journeys is worth less than the whole of one.
Sort the list honestly
Go through every requested feature and put it in one of three groups.
- Without this, the main job cannot be done.
- Useful, and people can manage without it at first.
- Wanted by someone, not needed for the question we are answering.
Only the first group is in the first version. A good test for a doubtful item: if it were missing on launch day, would the user be blocked, or merely inconvenienced? Inconvenience can be handled by hand for a while.
Do things manually behind the scenes
Many features can start as a manual process. Invoices can be sent from the accounting tool. A weekly report can be produced by running a query. New customers can be set up by your own staff. This shows which features are really needed, and with what details, before anyone builds them.
What not to cut
Some things are invisible in a demo and expensive to add later.
- Security basics. Proper authentication, permissions and protection of personal data.
- Backups. From the day real data is entered.
- Error reporting and logs. So you learn about problems before users tell you.
- A deployment process. So that fixes can be released quickly and safely.
- Sound data structure. The data model is the hardest thing to change once customers depend on it.
A first version can be small. It should not be fragile.
Time-box it
Set a fixed period, commonly eight to twelve weeks, and fit the scope to it instead of extending the date when new ideas appear. New ideas go on a list for the next version. A fixed date forces the sorting decisions that are otherwise postponed indefinitely.
Write down what is out
A scope document that lists only what is included invites misunderstanding. List what is deliberately left out and why. When someone asks in week six why there is no export to a spreadsheet, the answer already exists and the discussion takes a minute.
Plan to learn from it
Decide before launch what you will measure and whom you will talk to. Which actions show that the product is being used for its main job? Which five users will you interview after two weeks? A first version that is released and not studied has answered nothing.
Common mistakes
- Building administration screens before the main user journey works.
- Supporting every edge case from day one.
- Designing for a hundred thousand users when there are none yet.
- Treating the first version as a throwaway and skipping the foundations.
Summary
Name the question, pick one user and one job, include only what that job requires, keep the foundations and fix the timeline. Scoping is the first stage of our custom software development service, done before any estimate is given. If you have a product idea and a long feature list, we can help you cut it.