How to Prioritise Features for Your First Product Release

Feature debates go in circles when the team has not agreed who the first release is for, and the loudest voice in the room usually wins. A product aimed at “small business owners” invites every feature imaginable, because almost anything could help some owner somewhere, even if it helps nobody in particular. A product aimed at “a bakery owner tracking daily wastage across two outlets” invites a shorter, sharper list, because each feature either helps that owner or does not.

The choice is not permanent. It scopes version one only. Later releases can widen the audience or add a second job, but every first-release debate should be measured against that one user and job.

List the assumptions first. These are the beliefs that, if wrong, sink the product however well it is built, so write each one as a plain sentence before any feature gets a score. For a bakery wastage tracker, one might be that staff will log unsold croissants and sourdough loaves before closing. Another might be that owners check the numbers often enough to change their flour and butter orders.

Each assumption names a journey. If staff behaviour is the riskiest assumption, one flow is essential. A counter assistant must log a tray of unsold pastries in under thirty seconds, with one tap on a tablet beside the till. A detailed reporting dashboard is not. A plain morning email listing yesterday’s unsold loaves by outlet would test the owner’s side just as well, at a fraction of the build effort.

Rate each surviving feature low, medium or high on three things: what it would teach you, how risky the idea becomes without it, and how much effort it takes. Cheap and risk-covering means yes. Expensive and demo-only means no.

The hard cases sit in between, with moderate effort and moderate value, and there the tie-breaker is the assumptions list you wrote earlier. Does the feature test something the whole idea depends on, or does it only make an already-working journey nicer for users who are already getting the job done? The first kind earns a place in version one far more often than the second, and the second usually waits for version two.

One category never gets cut, whatever its score: whatever keeps the core journey correct and user data safe from the wrong eyes or a careless edit. Take a wastage app that occasionally loses a day’s entries, or one that lets staff at one outlet see another outlet’s numbers. Either wrecks the test, because the owner stops trusting the figures and the product fails for a reason unrelated to the idea.

That puts input validation, sensible error messages and correct access permissions in version one, however dull they look on a feature list. They protect what you learn. Without them the test means little.

Produce two lists, not one. One holds what ships in version one, and the other holds what was deliberately excluded, with the reason, so nobody has to reconstruct the debate months later. Written exclusions give the team a clear answer when someone asks why the product lacks something, and they give version two a starting point instead of a blank page.

Date the excluded list. When version one’s results arrive, revisit it with real evidence in hand instead of the original guesswork, and move any entry that now looks wrong. Some will matter a great deal. Others will not matter at all. That difference is the MVP’s job.