How to prioritise feature requests into a roadmap you can defend

In short: To prioritise feature requests, stop logging them as features and log them as problems with a segment attached. Weight each problem by how many stores hit it and how much revenue those stores represent, then check usage data before you commit, because what merchants ask for and what they do are often different. Only the top of the ranked queue gets a full ticket. Everything else stays as a tagged problem until it earns its place.

Why does the feature request list keep growing?

Requests arrive from three places, and each one lies in its own way.

Founder ideas come with conviction and no sample size. Customer requests come through support, sales calls and App Store reviews, and they are biased toward whoever talks the most. Usage data is honest about what merchants do but silent about why. A roadmap built from any one of these alone is wrong in a predictable direction: founder-only roadmaps build for the founder, request-only roadmaps build for the loudest ten accounts, and data-only roadmaps polish what exists and never add what is missing.

The list grows because requests are logged as features. "Add a Klaviyo integration", "add CSV export", "add a dark mode". Features do not merge, so the list only gets longer. Problems merge. Five feature requests often turn out to be one problem, and the problem is what you should rank.

How do you tag requests by problem instead of by feature?

When a request comes in, write down the problem behind it before you write down the feature. The request "add a Klaviyo integration" from a Shopify brand usually means "I want to email affiliates who have not posted in 30 days, and my email tool is Klaviyo". The problem is re-engaging quiet affiliates. The Klaviyo integration is one of four ways to solve it.

Each logged request gets five fields:

Field	Example
Problem	Merchant cannot re-engage affiliates who stopped posting
Segment	Brands with 50+ affiliates, mostly Growth plan
Source	Support ticket, sales call, App Store review, founder, usage data
Requester revenue	Monthly plan value of the store that asked
Count	How many distinct stores have raised the same problem

The Count field is what makes this work. When a new request matches an existing problem, you add one to the count and add the store's plan value to the revenue total. The list stops growing and starts stacking. After a quarter you have twenty problems with real counts, not two hundred features with none.

When I was the account manager for the top brands at Social Snowball, their requests reached me first, and they were a tiny share of the merchants on the app. A request that makes sense for a brand with a thousand affiliates can be invisible to a store with ten. Tagging by problem and counting stores is how you keep one big account from writing the roadmap.

How do you weight requests by revenue at risk and reach?

Once requests are problems with counts, ranking is arithmetic. I use two numbers per problem and one divisor.

Reach is how many stores hit the problem in a month. Count it from the tagged requests, then check it against usage data (next section), because the number of stores who complain is always smaller than the number who have the problem.

Revenue at risk is the monthly plan value of the stores affected, plus the plan value of stores showing a churn signal that this problem explains. A problem that only annoys stores on the free plan ranks below one that is making a paid store go quiet, even if the free-plan problem has twice the count.

Effort is the engineering estimate in weeks, rough is fine.

This is a simplified version of RICE. Intercom's original RICE post defines Reach as how many customers a project will impact over a period such as a quarter, scores Impact on a scale from 0.25 to 3, sets Confidence at 100%, 80% or 50%, and divides by Effort in person-months. I keep Reach and Effort, swap Impact for revenue because in e-commerce SaaS the revenue of the affected stores is a number you have, and I keep Confidence as a plain label: measured, reported, or guessed.

The ranking formula is reach multiplied by revenue at risk, divided by effort. Do not treat the output as precise. Treat it as a sort order, then argue about the top five. An invented example:

Problem	Reach (stores/month)	Revenue at risk	Effort (weeks)	Confidence
Cannot re-engage quiet affiliates	180	High	3	Reported
Payout CSV rejected by PayPal	40	High	1	Measured
Wants a dark mode	6	Low	2	Reported

The payout problem is small in reach but cheap, high in revenue and measured. It goes first. The dark mode request stays tagged and waits.

What should you check in usage data before building?

Three questions, in order, and PostHog answers each one if you have the events wired.

Do merchants reach the place where the feature would live? Build a funnel from install to the screen the feature would sit on. PostHog's funnels documentation describes funnels as a way to visualise flows and see where friction points are, with overall conversion and step-by-step conversion rates. If 70% of merchants never reach the affiliates table, a better export button on that table helps 30% of them. The real problem is upstream, and it probably belongs in Shopify app onboarding.

Do merchants who do the related thing come back? Use a retention insight. PostHog's retention docs define it as how many users return during subsequent periods, with a start event that defines the cohort and a return event that shows who was retained. Compare stores that used the adjacent feature against stores that did not. If stores that send one affiliate email in week one are still active in week eight at a higher rate than those who do not, the quiet-affiliates problem is worth solving. If there is no difference, be careful. That is a correlation, not a cause, and it only tells you the problem is worth a closer look.

How many stores actually hit the condition? Requests give you the count of stores who complained. Usage data gives you the count of stores who could have. A query for stores with 50+ affiliates where fewer than half posted last month is the true reach. It is usually several times the request count, and sometimes it is smaller, which is the finding that saves you a month.

If the events are not there, that is itself an answer: wire them now, build the feature next quarter. The events are cheap, and the first thing a new ticket should carry is the analytics it needs to be judged later.

Write the ticket only for the top of the queue

Full tickets are expensive to write well. They need a problem statement, evidence, design, states, acceptance criteria and analytics, and I cover that format in how to write a product ticket. Writing that for twenty problems is a waste because fifteen of them will never be built.

Write full tickets for the top three to five only. The rest stay in the problem list with their counts and revenue. When a new request lands on one of them, update the count and reply to the merchant with the honest status: "logged, 12 stores have asked, not scheduled yet". Merchants accept a no with a reason. They do not accept silence.

A monthly routine keeps this from rotting:

Week	Task
1	Tag every new request from support, sales and reviews to a problem. Update counts.
2	Re-rank the list. Pull reach and retention for the top ten from PostHog.
3	Write or refresh full tickets for the top three to five. Design starts.
4	Close the loop: reply to every requester whose problem moved, up or down.

What should you ignore?

Three kinds of request get tagged and then deliberately left alone.

Requests from stores that are about to churn for a different reason. If a store's health score is already red because they stopped getting orders, the feature they asked for will not save them, and their revenue should not weight the problem.

Requests that describe a competitor's feature rather than a problem. "Competitor X has this" is a source, not a problem. Ask what the merchant would do with it, then tag that.

Anything with a count of one and no usage signal, unless the one is a measured problem that blocks a core flow. A single store wanting dark mode is a preference. A single store whose payouts fail every Friday is a bug.

Where to start

1. Export your current feature request list and rewrite each entry as a problem with a segment. Merge duplicates. Expect the list to shrink by half.
2. Add the five fields (problem, segment, source, requester revenue, count) to wherever you track requests, and back-fill count from the merged list.
3. For the top ten problems, build one PostHog funnel and one retention insight each. Note which ones have no events, and add those events to the next sprint.
4. Rank by reach times revenue divided by effort. Write full tickets for the top three.
5. Reply to every merchant who raised one of those three. Tell them it is scheduled and why.