Use casePrioritize the roadmap
Rank the candidates for the next roadmap with the customers who will use them, then judge each late escalation against that list and give the account team whose request slipped a reason it can take back.
Every roadmap has more candidates than capacity, and the planning meeting goes better when customers have already done the first round of choosing.
The brief lists each candidate as the outcome a customer would notice, such as approving invoices from a phone, in place of the internal project name, and Pulse shapes each interview around that list.
Decide whose ranking counts before fieldwork, such as the enterprise accounts the plan is built on or the new users growth depends on, so a vocal segment the strategy has moved past does not set the order.
A survey alongside the interviews asks customers to rank the candidates, and the AI-moderated follow-ups ask why each one placed where it did, so the order reflects real trade-offs across the segments in the study.
The world's most ambitious teams research with Pulse.
GrowwThe list is tested hardest mid-cycle, when a large customer escalates and the team needs something firmer than opinion to decide what gives way.
A new request from a large account is written up the same way as the other candidates and set against the customer ranking, so the team can say which item it would displace and whether that trade is worth making.
Open questions about the job customers are trying to complete surface needs no candidate meets, which the team hears about before committing capacity to a list that turns out to be incomplete.
When a request slips, the account manager gets the reason in customers' terms, what other accounts needed more and how they described it, to take back to a customer who expected their item next.
Roadmap prioritization weighs customer value against strategy, effort and technical dependencies, and research supplies the customer side. Qualitative interviews explain what problem each candidate would solve, the workaround customers use today and what a good solution would look like, and jobs-to-be-done questions can reveal needs no candidate addresses. Results are read by segment, because enterprise accounts and new users often value different things, and requests are separated from underlying needs, since the feature asked for is not always the best answer. Rating scales tend to make every feature look important, so the ranking itself usually comes from a forced-choice method. MaxDiff is the common choice: respondents see small sets of candidates and pick the most and least important in each, repeatedly, which produces a clear order and a measure of how far apart the items sit.
Work on the platform, which customers never see, competes with features they do. Asked about slowness, outages and workarounds, customers describe what the debt costs them, and those quotes let engineering put its case on the same list as features.
Removing a little-used feature frees capacity, and a few customers will object. A list pulled from the usage data reaches the customers who still rely on it, and they explain what for, so product knows what a replacement must cover before retiring it.
Some candidates are integrations a partner has asked for. Recruiting people who use both products shows whether the integration matters to shared customers or mainly to the partner's own sales team.