Is It Worth Doing
Frequency, pain, number of people. If all three are low, don't.
A need being real doesn't mean it's worth doing. Between real and worth-it sit three numbers: how many people, how often they hit it, and how much it hurts each time.
What you'll run into:
- Every request is real, but after you build it, barely anyone touches it
- You build a complex feature for a scenario that happens once a quarter
- You can't decide what to do first, so you go by whoever asked loudest
Three dimensions
- People. How many people match this description? It sets the ceiling. Few people but high willingness to pay can still work.
- Frequency. When did they last hit this, and the time before that? It decides whether a habit can form, and it drives retention.
- Pain. When it went wrong, what were the consequences? It decides whether they'll pay, and how much.
The three dimensions are multiplied together, not added. If any one approaches zero, the result is zero—a minor annoyance that a million people hit once a year is less worth doing than a serious problem ten people hit every day.
Trading "this feels important" for three numbers you can challenge pays off not in precision but in testability. Vague phrases like "a lot of people" or "everyone probably has this" are dangerous precisely because they can't be falsified: you don't know it's wrong before you build, and you can't tell which step went wrong after.
Of the three numbers, frequency is the easiest to lie to yourself about. Ask "is this requirement important" and everyone says yes; rephrase it as "when did you last hit this, and the time before that" and the room for vague answers collapses. Turn frequency into concrete dates, turn pain into "how long did you spend handling it that time," and turn people into "how many people like this do you actually know." The more specific the question, the harder it is to pad the answer.
Do a rough calculation
It doesn't need to be precise—order of magnitude is enough. The point is to turn "feels important" into a number that can be challenged.
- Sizable: a target group of 50,000 small merchants, roughly 30% with this problem, hitting it twice a week at half an hour each time, about a tenth willing to pay $5 a month. That multiplies to 1,500 paying users and $90,000 a year. You can argue with that number, and you can make trade-offs against it.
- Not sizable: a target group of "a lot of people," "everyone probably has this," "comes up occasionally," "somebody would probably pay." That's not an estimate—it's a wish. It can't be falsified: you don't know it's wrong before you build, and you can't tell which step went wrong after.
When to cut
- If any of the three is near zero, cut it. Don't count on the other two to make it up—a zero in a product can't be offset.
- If you can't size it, don't build it yet. Not being able to size it means you don't know this group well enough; building now is just gambling.
- If only one person asked, park it. Put it in the pool and wait for a second. When a second person shows up, it's not an isolated case.
- High frequency, low pain isn't a revenue play. Its value is retention—it keeps people coming, and the money comes from elsewhere.
Plenty of models exist for ranking requests—KANO and others can serve as reference—but ask for these three numbers before you rank anything. kano Pain is the hardest dimension to estimate, and the most reliable way is to look at what people already spend in time or money dealing with it now: if someone is already solving the problem with a clunky workaround, the problem is real.
When do you run this rough math? Every time a request enters the pool, not just before a big commitment. Attach three numbers to every incoming request. The numbers don't mean you build it—they give you a shared language to argue in. "Only thirty people, but each one loses two hours" and "this sounds important" produce very different quality of discussion. A prioritization meeting stops being about who talks loudest and becomes about the numbers.