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. Avoid starting with a proposed feature.
2. Map the workflow
Identify the states, actors, hand-offs, decisions, data and existing systems around the problem. This reveals which parts are product problems and which are process problems.
3. Draw the product boundary
Decide what the product owns, what should remain in existing systems and what can be manual in the first release. This is usually where unnecessary complexity is removed.
4. Rank the assumptions
Separate desirability, feasibility, usability, safety and commercial assumptions. The riskiest assumption should influence the first release more than the longest feature list.
5. Choose architecture after scope
Architecture should follow the actual product boundary. Premature platform choices often encode assumptions that the first release was meant to test.
6. Define the evidence from version one
Decide what you need to learn from real use. That determines instrumentation, evaluation and which features genuinely belong in the MVP.