Scope a version one
Cut your idea down to a version one you can afford to build
We take an idea or a long feature list and turn it into a bounded first version. First comes the problem statement every decision gets tested against. Then we draw the line around version one: what's in, what's out and what waits for later, with the reason for each call written down.
What you get
What’s included
Problem statement
Who has the problem, what it costs them today and what a fix looks like, in a few sentences you can test every feature against.
First users
The specific group version one is for, so features aimed at other groups can wait their turn.
In, out and later list
Every feature you've collected, sorted, with a one-line reason for each decision.
Version one description
A written account of the smallest product that solves the problem, ready to hand to a designer or developer.
Success measures
What you'll check after launch to know whether version one did its job.
Assumptions and open questions
What the scope depends on being true, so you know what to check first.
A good fit if
- Founders whose feature list grows every time they talk to someone new
- Gym, studio and coaching businesses that know the problem but not the smallest product that fixes it
- Founders collecting quotes who want every agency pricing the same scope
- Anyone whose budget and plans don't match yet
Not included
- User stories, acceptance criteria or a full backlog (see the PRD or the sprint)
- Architecture or technology choices
- A build estimate
How it runs
From kickoff to handover
- Step 1
Intake
You share the idea, the feature list and anything users or customers have told you.
- Step 2
Problem statement
We draft the problem and the first users, and agree them with you before touching features.
- Step 3
The cut
Every feature gets tested against the problem and sorted into in, out or later.
- Step 4
Review and final document
We go through the calls with you, adjust where you disagree, and deliver the final scope.
Questions
Questions about Problem statement & MVP scope
How is this different from the MVP Planning Sprint?
The scope is the first part of the sprint, sold on its own. The sprint goes on to user flows, a prioritised backlog, a release roadmap, architecture options and a build estimate.
Can I send the scope to several agencies for quotes?
Yes, and it's one of the best uses for it. When every agency quotes from the same written scope, the differences between quotes reflect price and approach instead of different guesses about what you want.
What if I disagree with what you cut?
You make the final call. If you move a feature back in, the document records the trade-off, so everyone can see what it adds to the build.
My idea is still vague. Is it too early?
A vague idea is a normal starting point. If it's still too loose to scope, the 90-minute workshop is a smaller first step.
Does this only work for apps?
No. It works for any product you're about to build, including member portals, booking systems and web platforms.
More from Product Strategy
Keep exploring
Often paired with this
Work with us
Ready to start Problem statement & MVP scope?
Tell us about your business. We'll confirm the scope and send you a start date.