Deciding what to build: a guide for B2B product teams

Deciding what to build is an evidence problem, not a framework problem. The work runs in five stages: capture feedback with the account attached, split it into individual claims, group those claims into themes by meaning, weight the themes by revenue and trend, and decide against strategy. Most teams own the first stage and improvise the rest.

There is no shortage of advice on this question. Most of it offers a four-step process that begins with "start with strategy" and ends with "learn to say no," which is true, unobjectionable, and almost impossible to act on when you are looking at three hundred scattered pieces of feedback on a Monday morning.

The gap between that advice and the actual work is the middle. Everyone agrees you should build what solves real customer problems. Nobody explains how you get from a pile of support tickets, sales call notes, and Slack messages to a confident claim about what those problems actually are, and which ones matter most. That middle is a pipeline, and it can be described precisely.

This page walks the whole pipeline and links to a deeper treatment of each stage.

The five stages

Capture. Feedback arrives through whatever channels your customers already use, and the only thing that matters at this stage is that each piece stays attached to the account it came from and stays in the customer's own words. Categorising at capture time is where most systems quietly lose information.

Split. A single conversation usually contains more than one claim. Break each piece of feedback into its individual claims before doing anything else, because you cannot cleanly group records that each hold several unrelated problems.

Group. Cluster those claims into themes by the problem they describe, not the words they use. This is the hard stage and the one most systems skip by substituting tags.

Weight. Attach the accounts, revenue, and trend behind each theme, so the themes can be ranked by what they cost you rather than by how often they were mentioned.

Decide. Rank the weighted themes against strategy, commit to some, decline others, and tell the customers either way.

Each stage has a failure mode, and each failure mode produces a recognisable symptom in the decision at the end. The rest of this page covers them in order.

Stage one: what you're actually collecting

Before anything else, it helps to be precise about the objects you are handling, because three different things get called "feedback" and they behave differently.

Feedback is what a customer said: an event, from an account, at a time. A feature request is a solution that customer proposed, which is not the same as the problem behind it. A theme, or signal, is a problem you have confirmed recurs across multiple accounts, and it is the only one of the three that nobody can hand you, because it has to be constructed from the others.

Confusing these is the root cause of most downstream trouble. Ranking requests means ranking solutions by popularity. Ranking themes means ranking problems by severity. The full distinction is in the difference between feedback, a feature request, and a pattern.

The practical rule for capture: keep the customer's exact words, attach the account, and resist the urge to categorise yet.

Stage two and three: getting from scattered feedback to real themes

This is where the pipeline is usually broken, and it is broken in the same way almost everywhere: by tagging.

Tags are applied from a list that someone wrote in advance, which means they can only describe problems you already anticipated. A genuinely new problem has no tag and lands in "other." Worse, two people tag the same problem differently, so one real theme splits across two labels and neither looks big enough to act on. And because most feedback contains several claims, whatever tag you apply is true of part of the record and false of the rest.

What works instead is grouping by meaning. "Dispatchers can't reassign a route mid-shift" and "we end up calling drivers directly when plans change" are one problem in two vocabularies, and any method that matches on words will never join them. The full treatment, including why keyword and tag approaches fail and what replaces them, is in how to find recurring problems in customer feedback.

Two sources deserve their own handling at this stage. Support tickets are the densest feedback you own and the most commonly mis-analysed, because the instinct is to count ticket volume rather than weight by account: see how to analyze support tickets for product insights. Sales feedback is valuable but secondhand, usually a compressed summary of several conversations, and needs separating from what customers said directly: see managing product feedback from sales.

And if your feedback is scattered across channels that do not talk to each other, the grouping stage cannot work at all, because the same problem in three tools looks like three small problems. Managing customer feedback across channelscovers holding that context together.

Stage four: weighting, and why counts mislead

Once you have themes, you have to rank them, and the default instinct is to rank by how many people asked.

In B2B that instinct is wrong, and not marginally. A count measures who spoke, which correlates with who is engaged and articulate rather than who is affected or what they pay. Ten mentions from trial accounts outrank three from enterprise accounts approaching renewal, purely because the trials are chattier. The fix is to weight each theme by the distinct accounts behind it, their revenue, their renewal proximity, and whether the theme is accelerating. Frameworks like RICE are useful at the very end of this, applied to a weighted shortlist rather than to a raw list of requests. That argument in full is in how to prioritize feature requests without just counting votes.

Two related questions live at this stage. The first is how much evidence justifies building at all, which turns out to depend on the strength of the evidence and the cost of being wrong rather than on any threshold number: how many customers need to ask before you build it. The second is catching a theme while it is still small, since the problems that hurt most are usually slow trends that never trigger an alert: how to spot a trend in feedback before it's obvious.

Stage five: deciding, declining, and closing the loop

A weighted ranking narrows the field. It does not make the call.

Strategy still vetoes. A high-revenue theme that pulls you away from where you are going is one you may correctly decline, and no amount of well-structured evidence removes that judgment. What the evidence does is make the decision defensible: you can show which accounts, how much revenue, and what the customers actually said, rather than asserting that something is important. The mechanics of that final step are in how customer feedback becomes a product decision, and for the harder cases where everything feels urgent, how great product teams make decisions.

Most decisions are declines, so declining well is most of the job. The honest no rests on being able to show a customer where their request sits and why, rather than on finding a softer phrasing: how to say no to a feature request.

Then the loop closes. When something ships, the customers whose feedback formed the theme hear about it, in the channel they originally used. This is the step teams drop first and the one that keeps feedback flowing: closing the feedback loop.

Does the roadmap come before or after all this?

Both, at different altitudes, and conflating them causes most roadmap dysfunction.

Strategy is an input. What market you serve, what bet you are making, what you refuse to build: these should be stable for quarters, and no amount of feedback should reorder them weekly. Sequencing is better treated as an output, rendered from the weighted evidence and updated as the evidence changes, rather than negotiated once a quarter and defended for nine months. The argument, including the honest case against it, is in should the roadmap be an input or an output. The balance between strategic intent and customer demand is covered further in why both strategy and customer needs matter for prioritisation.

The pipeline, stage by stage

When this doesn't apply

If you have few enough customers that you speak to all of them, you are already running this pipeline in your head, and doing it better than any system would. Read everything yourself for as long as that is possible. The machinery matters at the volume where one person can no longer hold it all. Where to keep feedback before that point is covered in where should customer feedback live when you're a team of one.

If you sell a genuinely novel product, feedback will underdetermine your direction. Customers describe problems inside the frame they already understand, and the pipeline will tell you what confuses your early users without telling you what to invent next. Weight it as one input among several.

And if your revenue is concentrated in one or two accounts, the weighting collapses toward whatever those accounts need. That is not a flaw in the method, it is an accurate reflection of an uncomfortable commercial fact.

Frequently asked questions

1. Do I need software for this? Not at low volume. The pipeline is a discipline before it is a system, and a shared document organised by problem rather than by request will carry a small team a long way. Software earns its place when manual grouping and counting starts consuming the time you would otherwise spend building.

2. Where do most teams break this pipeline? At the grouping stage. Capture is usually solved, and everyone has a prioritisation framework. The missing middle is turning scattered, differently-worded feedback into a reliable set of themes, and most teams substitute tagging for it, which caps what they can ever discover at what they already expected.

3. Isn't this just doing whatever customers ask? The opposite. Requests are inputs to themes rather than instructions, themes are weighted by who is affected rather than who asked loudest, and strategy still vetoes the ranking. The pipeline makes it easier to decline a loud request, because the reasoning behind the ranking is visible.

4. How is this different from a prioritisation framework? A framework scores items you already have. This is about producing the right items to score. RICE applied to a raw list of feature requests ranks solutions by guessed impact; applied to weighted themes, it compares real problems. The framework is the last step, not the method.

5. How long does it take to set this up? The habits matter more than the tooling and can start immediately: capture with the account attached, describe things as problems rather than solutions, and review what changed rather than what is biggest. The tooling question only becomes pressing once volume outgrows what you can group by hand.

Lane is built around this pipeline: feedback stays verbatim and tied to its account, claims are grouped into themes by meaning rather than tags, and each theme carries the revenue and trend behind it, so the decision at the end is one you can show rather than assert.