A first release should prove one thing: that a specific group of people will use the product to solve a specific problem. Sort every proposed feature into must prove, can wait or not needed, and build only the first column. Measure success by activation, repeat use and the cost of change, not by feature count.
- A first release exists to prove one thing, not to do everything.
- Sort every feature into must prove, can wait or not needed.
- Unresolved assumptions get more expensive every week they reach development.
- Good discovery leaves you with decisions, not just documents.
Watch any kickoff meeting closely and you’ll see the feature list grow in real time. Someone mentions a dashboard. Someone else needs exports. A third person asks about notifications, then roles, then an admin panel, then “maybe a bit of AI”.
Every item sounds reasonable. Together, they turn a focused product into a year-long build that launches into silence.
What is a first release actually for?
A first release isn’t a smaller version of the final product. It’s a question you ask the market, with software.
Will this group of people use this to solve this problem? That’s it. Everything in version one should help answer that question. Anything that doesn’t can wait until you know the answer.
Framed that way, cutting scope stops feeling like a compromise. It becomes the fastest route to learning something real.
The cut we make
We take every feature on the list and put it in one of three columns:
- Must prove. Without it, the core question can’t be answered. These go in.
- Can wait. Useful, maybe important later, but not needed to test the idea. These go on the roadmap.
- Not needed. Nice in a pitch deck, irrelevant to the user. These go away.
The conversation is rarely comfortable. It is always worth having before a line of code is written, because that’s when changing your mind is cheapest.
Ambiguity is free in a workshop and expensive in a sprint.
Look wider before you cut
Here’s the twist: the right first release sometimes needs a wider view, not a narrower one.
With LingoLane, the obvious brief was educational activities for children. The real opportunity was bigger. A child learning on their own, a teacher who needs to see progress, a parent who wants to stay connected. Seeing all three changed what the product had to be, and shaped a connected ecosystem instead of a standalone app.
Discovery isn’t only about removing features. It’s about making sure you’re cutting the right ones.
What should a discovery phase produce?
Not a slide deck that sits in a folder. A short set of decisions the whole team agrees on:
- A clear summary of the problem and the opportunity
- The user journeys that matter most
- A prioritised scope for the first release
- A high-level view of the solution and how it connects to existing systems
- The key assumptions and risks, written down where everyone can see them
- A practical roadmap into design and development
If you finish discovery and can’t say in one sentence what version one is meant to prove, it isn’t finished yet.
How to measure the impact
Set a baseline before you change anything, then track the same measures for at least a month afterwards. These are the numbers we use with clients:
| Metric | How to measure it | What good looks like |
|---|---|---|
| Time to first release | Weeks from kickoff to real users using the product | Shorter than a full-scope plan |
| Activation rate | Share of new users who complete the core action at least once | Rises with each release |
| Repeat use | Share of users who return within 7 and 30 days | Holds or improves after launch |
| Scope change after build starts | Features added or removed once development begins | Low, because decisions were made in discovery |
| Validated assumptions | Key assumptions confirmed or rejected with real usage | Each release answers at least one |
Frequently asked questions
What should be included in an MVP?
Only the features needed to test the core question: will this group of people use this product to solve this problem? Everything else goes on the roadmap until real usage answers that question.
How do you prioritise features for a first release?
Put every feature into one of three columns: must prove, can wait or not needed. Build the first column, schedule the second, and drop the third.
What does a product discovery phase produce?
A problem and opportunity summary, the key user journeys, a prioritised first-release scope, a high-level solution direction, the main assumptions and risks, and a practical delivery roadmap.
How do you know if an MVP is working?
Track activation (users completing the core action), repeat use within 7 and 30 days, and how many key assumptions each release confirms or rejects.
