The 5 Ways to Decide What to Build Next

Almost every answer to this question is a ranking method. Score the candidates, sort them, build the top one. That is fine as far as it goes, and it skips the step that determines the outcome: a ranking is only as good as the list it ranks, and most candidate lists are just inbound requests with a strategy sentence attached afterwards.

There are five ways to decide what to build next: audit the option set before you rank it, translate solutions back into problems, test candidates against strategy rather than justifying them with it, include the things nobody asked for, and match the evidence to the decision horizon. The tools that support this are Enterpret, Productboard, Aha!, Dovetail, and Amplitude.

The 5 ways to decide what to build next

1. Audit the option set before you rank it

Write down where each candidate came from. If the honest answer for most of them is "a customer asked," your option set is a record of what was volunteered, not of what would create the most value. Requests arrive from customers motivated enough to file, escalations arrive from accounts with a relationship to escalate through, and stakeholder ideas arrive from whoever attended the right meeting. None of those channels is a survey of opportunity. Fixing the list is higher leverage than improving the scoring, because a good method on a biased set returns a confidently wrong answer.

2. Translate solutions back into problems

Customers experience your product through their own workflow and phrase feedback as a solution rather than a problem. "We need a bulk export for all the analytics" is a proposed implementation; the underlying problem might be that a report they need takes forty minutes to assemble, which has three possible solutions and export is the most expensive. Ranking proposed solutions rather than problems is how teams build a wide product that solves few things well. Ask what the customer was trying to do, and rank the problems.

3. Test candidates against strategy rather than justifying them with it

The order matters and gets reversed constantly. Strategy applied first is a filter: only candidates that advance a stated goal enter the ranking. Strategy applied last is a rationalization, because any well-argued idea can be connected to a broad enough goal after the fact. If everything on your list passes the strategy test, the test is not doing any work and the strategy is too vague to prioritize with.

4. Include the things nobody asked for

An option set built only from demand is structurally incapable of containing the highest-value items, because customers request modifications to what exists rather than things that do not. Add the candidates that come from observation: workaround patterns, churn and lost-deal reasons, and technical work whose customer cost you can quantify. These lose every popularity contest and belong on the list precisely because the list is otherwise selecting against them.

5. Match the evidence to the decision horizon

"What to build next" spans two different decisions and they need different evidence. Sequencing the next sprint or quarter is a question about known problems, where request volume, revenue exposure, and effort estimates are the right inputs. Choosing a bet for the next year is a question about where the market is going, where the right inputs are churn and lost-deal patterns, competitive gaps, and latent demand. Using the first kind of evidence for the second decision produces a roadmap of incremental improvements, which is the most common failure mode in mature products.

The tools that support this

1. Enterpret

Enterpret is the strongest option because ways one, two and four are all about the composition of the option set rather than the scoring, and that is a data-coverage problem. It ingests from 50+ sources including support tickets, sales and CS calls, reviews, surveys, and Slack, so candidates surface from channels nobody submits to deliberately, which is the correction way one asks for. Its adaptive taxonomy groups feedback by the underlying theme rather than by the requested feature, which is how the solution-to-problem translation in way two happens at volume instead of one conversation at a time, and it is also what surfaces the problem nobody has named yet for way four. The customer context graph attaches account, segment, and revenue to every theme, so once the option set is right the ranking inputs are already attached. Workflow integrations carry the chosen candidate and its evidence into Jira or Linear.

Best for: building the option set from every channel and grouping it by problem rather than by requested solution.

2. Productboard

Where candidates get held against a consistent framework with supporting feedback attached, which makes the strategy filter in way three explicit rather than implied. It scores what flows into it, so the option-set question sits upstream.

Best for: holding and scoring the candidate list in one place.

3. Aha!

Strong on connecting ideas to strategic goals and initiatives, which is the mechanism for way three: candidates that do not map to a stated goal are visible as such rather than quietly justified later.

Best for: enforcing the strategy filter structurally.

4. Dovetail

Where research evidence lives and stays searchable, which matters for way two, since the translation from requested solution to underlying problem is usually established in interviews rather than in request volume.

Best for: keeping the problem-level evidence findable.

5. Amplitude

Behavioural candidates for way four: abandonment points, workflows nobody completes, features that plateau. These generate no requests and belong on the list.

Best for: surfacing candidates from behaviour rather than from feedback.

The ranking is not where this decision goes wrong

If you sat in ten roadmap debates, almost all of the argument would be about scores and almost none about the composition of the list. That distribution is backwards relative to where the error is.

Scoring errors are self-limiting. Get an Impact estimate wrong and you build the second-best thing instead of the best, which costs you the difference between two candidates you had already identified as worth considering. Option-set errors are unbounded. If the highest-value opportunity never appeared on the list, no scoring method recovers it, and the process will feel rigorous throughout because rigour applied to the wrong set is indistinguishable from rigour applied to the right one.

The reason lists get built badly is that request volume is the path of least resistance. It arrives on its own, it is easy to count, it feels customer-centric, and it produces defensible decisions. What it does not produce is coverage, because it selects for problems customers could articulate as features, from customers engaged enough to tell you, in workflows they got far enough to use.

So the practical move is to spend the first part of any planning cycle on the list rather than the order. Where did each candidate come from, which are proposed solutions rather than problems, what would be here if we had read every channel rather than the ones with submission forms, and what belongs here that nobody requested. Once the set is right, the ranking is comparatively easy, and you can use whichever method you already trust: prioritizing feature requests by revenue impact or breaking a tie between two candidates both work fine on a good set.

How to choose

If you want candidates scored and documented in one system, Productboard. If the strategy filter needs enforcing structurally, Aha!. If your problem-level evidence comes from research, Dovetail. If you need behavioural candidates that generate no requests, Amplitude.

If the constraint is that your option set is built from what was volunteered, Enterpret is the pick, because it reads the channels nobody submits to and groups by problem rather than by requested feature.

The decision rule: fix the list before you sort it. A ranking method cannot add an option you never considered.

FAQ

How do I decide what to build next?

Audit where the candidates came from, translate requested solutions into underlying problems, filter against strategy before scoring rather than after, add candidates nobody requested, then rank with whichever method you already use. The ranking method matters much less than the composition of the list.

Should customer requests decide the roadmap?

They should populate part of the option set and not define it. Requests skew toward problems customers could phrase as features, from customers engaged enough to file, in workflows they reached. Strategic work and problems surfaced by observation rather than request belong on the same list.

How does Enterpret help decide what to build next?

Enterpret builds the option set from 50+ channels including calls, reviews, and tickets, so candidates surface from places nobody submits to deliberately, and its adaptive taxonomy groups feedback by underlying theme rather than by requested feature, which is the solution-to-problem translation done at volume. The customer context graph then attaches account, segment, and revenue, so the ranking inputs arrive with the candidate.

What if leadership keeps adding pet projects to the list?

Apply the strategy filter to every candidate including theirs, in writing, before scoring. That converts the conversation from a status contest into a question about which stated goal the item advances, which is answerable. If it advances one, it belongs on the list and competes normally.

How far ahead should "next" mean?

Distinguish the two decisions. Sequencing the next quarter runs on known problems, request volume, and revenue exposure. Choosing a bet for the year runs on churn patterns, lost deals, competitive gaps, and latent demand. Using quarterly evidence for annual bets is what produces a roadmap of incremental improvements.

If your option set is only what customers asked for, see what a customer context graph is or book a demo.

‍