Introduction
Every startup has more ideas than resources. The question is not "what can we build?", it is "what should we build first?"
Most roadmap discussions are actually prioritisation problems in disguise. Founders often debate features that should not be built yet. Choosing correctly often matters more than building quickly. The first feature should create customer value, not founder satisfaction.
This framework helps you decide which feature earns the next sprint, and which ones can sit on a list a while longer.
What it solves
What sharp prioritisation delivers
-
Faster customer value
A small set of well-chosen features delivers customer value weeks earlier than a sprawling roadmap. Sharper priorities produce sharper outcomes.
-
Shorter feedback loops
Shipping the right feature first gives the team customer signal in days. Shipping the wrong one first gives the team a debug log in weeks.
-
A clearer story for customers and investors
Products with sharp priorities communicate clearly. Customers understand what the product is for; investors see a team that can make decisions under uncertainty.
-
Less waste, less rework
Most rework comes from building features that turn out not to matter. Strong prioritisation keeps the codebase small enough to change as the team learns.
-
Team focus and morale
Teams that ship things customers care about ship faster. The reverse is also true: teams shipping the wrong things lose momentum, regardless of how much code they produce.
What it does not solve
What prioritisation will not fix
-
Unclear product strategy
Prioritisation is downstream of strategy. A team with a clear feature priority but an unclear product direction produces the wrong things efficiently.
-
Missing customer signal
Without customer conversations, prioritisation degenerates into opinion. You cannot weight what nobody is saying.
-
Engineering bottlenecks
A sharp roadmap meets a slow team and stalls. Prioritisation is necessary but not sufficient; throughput matters too.
-
Founder indecision
Strong prioritisation requires saying no. A founder who cannot say no produces roadmaps full of priorities, which is the same as having none.
-
Toxic stakeholder dynamics
If every meeting reopens the priority list, the problem is not the priorities. It is who gets to set them and how the decision is made.
Decision tree
Six questions for every candidate feature
Run each feature through these questions. The 'no's are where the backlog should grow shorter, not longer.
- Question 01
Does this feature create direct customer value?
No → Defer. Internal features, infrastructure work and 'nice for the team' projects rarely belong at the top of the list.Yes → Confirm with a customer who has named it explicitly, not implicitly. - Question 02
Does it remove friction?
No → Be cautious. Features that only add capability without removing friction often expand the product without improving it.Yes → Quantify the friction. 'Customers find it annoying' is opinion; 'they drop off here' is data. - Question 03
Will customers notice it?
No → Defer. Features customers cannot feel produce no signal, and the team cannot learn from them.Yes → Confirm with a measurable change: usage, conversion, retention, NPS, or a specific customer behaviour. - Question 04
Will it increase adoption?
No → Be careful. Some features deepen value but do not widen it. Both matter, but they belong at different stages.Yes → Quantify the adoption hypothesis. A small lift on a large segment beats a large lift on a tiny one. - Question 05
Can it wait until after launch?
No → Confirm by mapping the workflow. If the workflow works without it, the feature waits.Yes → Move it to a post-launch list. Customers will tell you whether it still matters. - Question 06
What happens if we never build it?
No → If the honest answer is 'nothing much', drop it. The backlog gets shorter when items lose their justification.Yes → Name the specific cost. 'Customers complain' is real; 'we'll feel incomplete' is not.
Common mistakes
Five common mistakes founders make
- 01
Building founder features
Features built because the founder wants them, rather than because customers do, populate roadmaps everywhere. They feel important inside the team and rarely move metrics outside it. Test every feature against a customer, not a feeling.
- 02
Building internal tools too early
Admin panels, audit logs, complex permission systems and ops dashboards are useful, eventually. At the start, they consume engineering time that could ship customer-visible features. Defer until usage justifies the investment.
- 03
Building edge cases
Edge cases are real but rarely on the path to fit. Build for the central use case until you have evidence; edges can wait for real customers who hit them.
- 04
Prioritising complexity
Complex features feel more important than simple ones. They are rarely worth more to customers. Simple features that move metrics beat complex features that signal effort.
- 05
Confusing activity with progress
Shipping features is not the same as making progress. The team that ships fewer, better features outperforms the team that ships more, average ones, especially in the first year of a product.
Alternatives
Practical prioritisation patterns
Four patterns that turn prioritisation from a debate into a decision.
-
One outcome per sprint
Pick one customer-visible outcome per sprint and protect it. Everything else becomes negotiable. Forces alignment on what matters this fortnight rather than this quarter.
-
Value vs cost scoring (lightweight)
Two numbers per candidate: customer value and engineering cost. The ratio sorts the list. Crude, fast, and usually surfaces the same answer as a long workshop.
-
Customer-led prioritisation
Build only what customers have asked for in the last 30 days. Restrictive on purpose; it stops the team from imagining customer demand and starts them building on real signal.
-
The 'kill list'
Maintain an explicit list of features you have decided not to build. Each item with a date and a reason. Removing items from the roadmap becomes routine; the list grows healthier over time.
Ronald's rule of thumb
The best feature is often the one customers feel immediately.
Features that customers notice on first use produce signal fastest. Features that only become valuable over weeks of use produce signal too slowly to course-correct. Bias the early roadmap toward fast-signal features; defer slow-signal features until the basics produce a customer base worth optimising for.
, Ronald · YourStartup.Expert
Summary
Summary
Prioritisation is the single highest-leverage activity in early-stage product work. The six questions above turn an open-ended argument into a decision: customer value, friction, noticeability, adoption, deferrability and the cost of not building it. Features that pass all six earn the next sprint; the rest belong on a list, or in the bin.
Most teams build too much, too early, and learn slower as a result. The discipline to build less is rarely taught, often resisted, and almost always the right answer in the first year of a product. The roadmap is a tool for choosing what not to do.
Common questions
Feature prioritisation, answered.
The questions founders ask before they fill the sprint.
- How do I prioritise features?
- Score each candidate on customer value, removal of friction, noticeability, adoption impact and deferrability. The features that pass on all five earn the next sprint; the rest go on a list to be revisited later or, more often, dropped. Avoid relying purely on personal opinion or stakeholder volume; use customer signal as the tiebreaker whenever possible.
- What should be built first?
- The single feature that delivers the clearest customer-visible value through the smallest amount of code. First-build features should produce fast feedback, not depth. Once that feature ships and customers respond, the next decision becomes much easier, and the work is grounded in evidence rather than assumption.
- How do startups build roadmaps?
- The healthiest startup roadmaps are short, weighted by customer signal and rebuilt frequently. A typical pattern: one explicit outcome per sprint, a small list of next-up items, a much longer 'parking lot' that gets reviewed monthly. Long, detailed roadmaps look impressive in slides but rarely survive contact with the next customer conversation.
- Should customer requests determine priorities?
- They should heavily influence priorities, but not blindly determine them. Customer requests are signal; aggregating them shows direction. The job of the team is to translate requests into the underlying problem and then choose the smallest feature that solves it. Building exactly what customers ask for, exactly as they ask for it, frequently produces features that satisfy nobody.
- How many features should an MVP contain?
- As few as possible while still solving the customer's one problem. A useful test: if a feature could be removed without destroying value, it does not belong in v1. Most MVPs have one core workflow and three to five supporting features. Beyond that, every additional feature delays learning and lengthens the time between launch and the next decision.