Product strategy
How to scope a digital product
The short answer
Product scope should define the smallest system that changes the target outcome and produces evidence for the next decision. Start with the problem and workflow, then define the boundary, assumptions, architecture and first release.
1. Define the operational problem
Describe what happens today, who experiences the problem, where the friction or risk occurs, and what a materially better state would look like. Start from the problem and let the features follow.
2. Map the workflow
Identify the states, actors, hand-offs, decisions, data and existing systems around the problem. The map shows which parts are product problems and which are process problems.
3. Draw the product boundary
Decide what the product owns, what stays in existing systems and what can be manual in the first release. Most of the complexity you can remove is found here.
4. Rank the assumptions
Separate desirability, feasibility, usability, safety and commercial assumptions. Let the riskiest assumption shape the first release.
5. Choose architecture after scope
Architecture should follow the product boundary. Platform choices made early tend to encode the very assumptions the first release was meant to test.
6. Define the evidence from version one
Decide what you need to learn from real use. The answer sets your instrumentation, your evaluation and the features that belong in the MVP.