Deciding what goes in version one

Every app project starts with more ideas than a first release can hold. That’s healthy. The trouble starts when all of them go into version one, the launch date slips, and the most important part gets less attention than it needs. Scoping is the work of choosing, on purpose, what ships first.

Start from the core job

Write down the one job the app has to do well. Then walk through the shortest path someone takes to get it done: open the app, sign in if they must, do the job, see that it worked. Every screen on that path is in scope. Everything else needs a reason.

Sort ideas into three piles

Take every feature idea and put it in one of three piles:

• Must have: the core job doesn’t work without it.
• Should have: it makes the core job noticeably better, and it’s small.
• Later: everything else, however good the idea.

Be strict with the first pile. A feature that “users will expect” isn’t a must-have unless the app is broken without it. The second pile is where the negotiating happens, and it’s fine if some of it slips.

Count the work you can’t see

Some things never appear on a feature list but still have to ship: sign-in and password reset, account deletion, a privacy policy, error and empty states, settings, crash reporting, analytics and the store listing. Together they can be a large share of a first release. Put them in the plan from the start, so they don’t surprise you in the last two weeks.

Start manual where you can

Some features can begin as a manual process behind the scenes. Approving new accounts can start as a person checking a list each morning. A weekly report can start as a query someone runs by hand. Automate once you know the feature is used, and how. It’s a cheap way to learn what people actually need before you build it properly.

Give “later” a home

Ideas that wait need somewhere to go, or they creep back in. Keep a simple list for the next version and review it after launch, with real usage to guide you. Some items on it will turn out not to matter. A few will matter more than anything on the original list, and you’d never have known without shipping first.

Fix the date, flex the scope

A fixed launch date with a flexible scope is easier to hit than the other way around. When the plan runs long, move features to the next version instead of moving the date. It keeps the release small and gets the app in front of real people sooner, which is where the useful feedback starts.

The short version

One core job, a strict must-have list, the hidden work counted from day one, and a home for everything else. A first version that does less, well, gives you something real to learn from. A first version that tries to do everything rarely ships.