Most prioritization frameworks assume you have enough data for frequency to mean something. RICE wants a reach number. ICE wants a confidence score you can defend. Both fall apart at the sample size most early-stage teams actually have: fifteen customers, thirty support tickets, four sales calls that mentioned the same thing. Here's what to count instead, and the threshold that tells you when you've got enough of it to commit.
Why frequency counting breaks at low n
RICE and ICE were built for products with enough users that a request showing up ten times out of ten thousand is a real signal and a request showing up zero times is a real absence. At twenty customers, both of those readings lie. Ten out of twenty isn't a trend, it might be one vocal account plus friends who agree with them in your Slack Connect channel. And zero mentions doesn't mean nobody wants it, it might mean the eleven customers who'd use it if it existed haven't thought to ask, because customers request features in the language of their current workaround, not the language of the fix.
We've watched founders run a real RICE calculation on eight data points and present the resulting score with two decimal places, as if the underlying number had that kind of precision. It didn't. The framework didn't fail; it was just never built for a denominator this small. The instinct to reach for RICE anyway comes from wanting the appearance of rigor, but a spreadsheet formula run on thin evidence just launders a guess into a number that looks measured.
What to count instead of frequency
At low n, the question isn't "how many people asked for this." It's "how many independent sources are pointing at the same underlying problem, even when they describe it differently." That's a different count, and it's the one that actually holds up at small sample sizes.
Independent-channel counting means treating a mention as evidence only if it comes from a distinct signal channel: a support ticket is one channel, a sales call is another, a churn exit interview is a third, an NPS verbatim is a fourth. Three complaints from the same customer across three tickets is one data point, not three. But one complaint each from a support ticket, a lost-deal call, and a churn interview, describing the same underlying gap in different words, is three independent confirmations, even though it's technically a smaller raw count. This is the same discipline behind separating signal from noise at the decision layer instead of just tallying mentions.
The distinction that matters here: count distinct evidence sources, not distinct utterances. A founder who reads ten support tickets from the same three accounts and calls it "ten requests" has three data points wearing a costume.
A threshold table by decision type
Different decisions warrant different amounts of confirmation before you commit. A reversible UI tweak doesn't need the same evidence bar as a two-sprint backend investment.
| Decision type | Reversibility | Minimum independent channels | Example threshold |
|---|---|---|---|
| Copy or UI microcopy change | Fully reversible, cheap to undo | 1 | One clear signal, ship and watch |
| Small feature addition (under 1 week build) | Reversible, low sunk cost | 2 | Two channels, e.g. a support pattern plus one sales objection |
| Roadmap-level feature (2+ sprints) | Expensive to reverse | 3, from at least 2 different channel types | Support tickets alone, no matter how many, don't clear this bar alone |
| Pricing or packaging change | Hard to reverse, affects existing customers | 3+, plus at least one revenue-linked account | Churn interviews and lost-deal calls carry more weight here than feature requests |
| Deprecating an existing feature | Hard to reverse, breaks existing workflows | Usage data confirming near-zero adoption, plus zero active-account objections | Absence of complaints only counts once you've confirmed nobody's using it |
The pattern across every row: cost of being wrong sets the bar, not how loud the request was. A founder with twenty customers can still make a defensible call on a two-sprint feature. They just need three independent channels agreeing, not three hundred people.
Independent-channel counting is the practice of treating a customer signal as confirmed only when it appears across multiple distinct evidence sources, such as a support ticket, a sales call, and a churn interview, rather than counting repeated mentions from a single source or account as separate data points.
Where P8 fits without pretending it's the whole answer
This counting discipline works whether or not you have a tool doing it for you. What a system like P8 changes is the labor of holding it in your head: instead of scanning ten Intercom threads, three call transcripts, and a spreadsheet of churn reasons every time you want to check whether a feature request has cleared its threshold, the channels get tagged as they come in and the count is already sitting there when you need to decide. That's a time saver, not a data conjurer. If you only have three customers total, no software fixes that; you're still going to be making calls with an evidence based product management approach applied to a genuinely small n, and being honest about that beats pretending three affiliated support tickets are three markets. This is the same discipline behind the decide layer, acting on confirmed signal instead of the loudest one.
The information gain: a worked example at n=20
Here's a case size that most prioritization content skips because it's below the threshold where the standard frameworks feel usable, but it's exactly where most post-seed founders live.
A twenty-customer B2B tool gets these signals over six weeks: four support tickets mentioning slow CSV export, one lost-deal call citing "no Salesforce integration" as the reason, two NPS verbatims mentioning wanting bulk actions, and one churn interview blaming "too much manual work." Naive frequency counting says CSV export wins with four mentions. Independent-channel counting says something different: the four CSV tickets all came from two accounts (two channels, same underlying account cluster, so it counts as one confirmed channel with internal repetition, not four). The bulk-actions verbatims came from two different customers on the same NPS wave (one channel type, two distinct accounts, still one channel category). The lost deal and the churn interview are two separate channel types citing two different problems.
Run the threshold table on this: CSV export has one channel type confirmed (support), with account-level repetition inside it, useful evidence but not enough alone for a roadmap-level build under the three-channel bar. Bulk actions has one channel type (NPS) with two accounts, same situation. Neither clears the bar solo. But "manual work is driving people out," which shows up across the churn interview and indirectly in the lost-deal call's Salesforce complaint (both are forms of "this doesn't fit into how we already work"), is a two-channel pattern pointing at integration and automation as the deeper theme, not any single feature. The naive count would have shipped CSV export. The channel-counted read points toward investigating integration options first, because that's where two independent, high-cost-of-loss channels agree, even though no single feature request "won" by volume.
Frequently asked questions
How many customers do you need before RICE or ICE start working? There's no hard cutoff, but as a rule of thumb, once you have enough users that a single account's opinion is structurally incapable of dominating a frequency count, usually somewhere past a few hundred active accounts, reach-based scoring starts producing numbers worth trusting. Below that, independent-channel counting is the more honest method.
Doesn't independent-channel counting still involve subjective judgment? Yes, deciding whether two complaints describe "the same underlying problem" takes judgment. The difference is that RICE's reach and confidence inputs hide that same subjectivity behind decimal points, while channel counting makes the judgment call visible and arguable. A commit-log entry that says "three channels: ticket #4021, call with Acme on 8/14, churn interview with Beta Corp" can be checked by someone else. A RICE score of 47.3 can't.
What if all my signal comes from one channel, like support tickets? Then you don't have independent confirmation yet, no matter how many tickets say the same thing, and that's useful information on its own. It means the next move is deliberately going looking in a second channel, a handful of customer calls or a quick NPS follow-up, before committing engineering time to a roadmap-level build.
The takeaway
Frequency counting isn't wrong, it's just calibrated for a sample size most early-stage products haven't reached yet. Swap it for independent-channel counting: treat a signal as confirmed when distinct evidence sources agree, weight the bar by how expensive it is to reverse the decision, and be honest when you don't have enough channels yet instead of dressing up a thin count in a framework built for a bigger one. For the broader question of turning any of this into a committed roadmap call, see how to decide what to build next.
