Scoping is the part of building a product that decides almost everything else: the date, the cost, and whether the first users get something that works. It's also where most first releases go wrong, usually by trying to do a little of everything.
This is the method I use. Each step comes from a real cut on a real product, and the case studies show the details.
What is a first release actually for?
A first release has one job: to put the part of the product people will use most in front of real users, working completely, so you learn from real use instead of guessing.
That sounds obvious, but it changes how you scope. You stop asking "what features does the product need?" and start asking "what does the part people use every day need to work end to end?"
On KpiClock, a team management product that replaces three tools, the answer was time tracking. Time tracking is the tool teams open every hour. So V1 shipped it completely: manual and automatic tracking with offline sync, screenshots with a blur mode, desktop apps for Windows, macOS and Linux, six integrations, three role dashboards, reports, and per-user billing. HR and e-signature waited for V2. I wrote about that decision in Replace three tools with one: why we shipped time tracking first.
How do you decide what to build first?
These are the six steps, in the order I take them.
- Find the daily-use part, and build it completely. Daily use is what earns you the right to add the rest. A complete part people open every day beats five half-built parts.
- Put money paths on fixed rules. Anything that charges, bills or pays should follow rules you can check. On LeanDeck, AI drafts proposals and agreements, but invoicing follows fixed rules, because a plausible-but-wrong invoice is worse than a slower one.
- Integrate before you build. If a tool already does something well, use it. SportsOnTV's 24/7 channel runs on an existing stream with its TV programme guide, plus YouTube live and playlists and a third-party TV-listings widget. That's a big part of how it went live in 5 weeks against an 8-week plan.
- Cut reports and settings to what day one needs. In my experience they grow fastest and are needed least at launch.
- Write the rules down in week one. Who can do what, with what limits, and what happens at the edges.
- Plan room after launch. Real users will show you things no plan did. Leave time to act on them.
What can you cut from an MVP?
Here's what stayed and what moved on real projects.
| Keep at launch | Move after launch | Real example |
|---|---|---|
| The daily-use part, complete | Other modules | KpiClock: time tracking complete in V1; HR and e-signature in V2 |
| Money on fixed rules | More billing options | LeanDeck: invoicing on fixed rules in the beta; milestone billing moved to Phase 2 |
| What existing tools already do | Building your own version | SportsOnTV: the channel and listings run on existing tools |
| Core reports | The rest of the reports, gift cards and add-ons | Mark Andrews Creative: core reports at launch; some reports, gift cards and add-ons after |
| What a company needs on day one | About 30% of modules, features and reports | SmartPeople: the cut that let a fixed 16-week plan hold |
| Features every customer shares | Anything that needs more work to share | Find Your Calm: those features moved to a later release to hold the August launch |
The SmartPeople cut is the one I'd point founders to. An audit before launch found 23 critical points where people got stuck, and fixing everything wouldn't fit in 16 weeks. So we cut about 30% of modules, features and reports, with one rule: keep what a company needs on day one. The product launched in April 2024 and is used by 100+ companies today.
Should an MVP use existing tools?
Where they do the job, yes. Building your own streaming, payments, calendars or e-signature is weeks of work that doesn't make your product different.
The trade-off is real, though: you depend on someone else's tool. On SportsOnTV we accepted that dependence, because building custom streaming infrastructure on a five-week clock wasn't sensible. The parts we did build were the ones nobody else could provide: AI-written sports summaries, and one master template for 20 sports pages.
My test is simple. If the thing you'd build is what makes your product worth choosing, build it. If it's plumbing, integrate it.
How do you stop scope growing during the build?
By writing the rules down early, and agreeing them before the build starts.
On Mark Andrews Creative, the brief was one sentence. I wrote all the requirements, specs, feature definitions and business logic, and the developers built from my specs. Looking back, I'd put the commerce and subscription rules into one written, signed-off rulebook in week one, so every edge case (users per plan, download limits, course access) had a single reference. When the rules are written down, a new request is easy to judge: does the first release's one job need it? If not, it goes on the after-launch list.
The same applies to cuts. On Find Your Calm, I cut by one rule to hold the August date: anything that needed more work to share across all operators moved to a later release, rather than being squeezed in or built as a one-off for a single operator. A rule like that makes each decision quick, because you're applying a rule instead of arguing each feature.
What happens after launch?
Plan for it as part of the scope. Real use shows gaps no plan does, so I leave time for them.
On KpiClock, the client saw people start the time tracker but forget to check in, so attendance showed them absent while they were working. Starting the tracker now checks the person in. On Mark Andrews Creative, customers wanted a single book, course or module without a whole subscription, so they can now buy those on their own, alongside the subscription. Neither of those was in a plan. Both came from leaving room.
For a sense of how scope turns into weeks, see How long does it take to build an MVP?, and for where AI belongs in a first release, Where the AI acts in LeanDeck.
Frequently asked questions
What should be included in an MVP?
The one job people will come back for, built completely, plus whatever that job needs to work for real users, including payments if it charges. In KpiClock that was time tracking, with offline sync, desktop apps, integrations, dashboards, reports and billing. HR and e-signature waited for V2.
What should you leave out of an MVP?
Reports, settings, extra roles and features that only some users need. At SmartPeople we moved about 30% of modules, features and reports to later releases, keeping what a company needs on day one. Leave things out on purpose and write down when they come.
How many features should an MVP have?
I don't count features. I check whether the first release does one job completely. A short list that works end to end is worth more than a long list that's half built.
How do you stop MVP scope from growing?
Write the rules and the cut list down in week one, and agree them with the client. When a new request comes in, it goes on the after-launch list unless it's needed for the one job the release is for.
