One technique that I teach in my product courses/workshops is something I call “count the digits.” It’s a quick-and-dirty way of sorting incoming suggestions into those worth spending real thought/discovery time on – and the vast majority that aren’t worth serious effort right now.
The basic idea is to spend no more than five minutes per item by finding 2 or 3 numbers that we can multiply… and get a rough order-of-magnitude idea of impact. Is this a 4-digit idea ($2k-$10k) or 5-digit suggestion (£30k-£100k) or a 7-digit opportunity (€1M-€5M)?
We won’t be accurate, of course, but we’ll be able to sort huge from tiny with a bit of practice. (And we’ll be speaking the language of money, not technical processes.)
First, some context-free examples to demonstrate the math:
If this new feature is intended to drive upsell from our entry tier to a higher-priced tier...
- Generic math: [entry-level installed base] * [upsell conversion SWAG] * [incremental revenue]
- Filled in example: [50k "bronze" customers] * [1-3% upsell to "silver"] * [incremental $1000/year per license] might deliver high 6-digit to low 7-digit revenue
If fixing this bug is intended to reduce our support costs...
- [guesstimated tickets] * [improvement SWAG] * [cost/ticket]
- [30-40 tickets/week] * [4-6% reduced] * [€75/support time/ticket] = low 4-digit staff savings †
If new capability C is intended to increase sales to first-time buyers…
- [guesstimated deals lost due to lack of C] * [guesstimated % we could realistically win if we had capability C ] * [Average new buyer price]
- [40 lost deals/quarter blamed on C] * [10% more we’d realistically win] * [£20k ASP] = high 5-digit incremental sales
I don't give much credence to the specific number, since we're multiplying guesses. This won't help us separate mid-5 digits from high-5 digits, but order-of-magnitude comparisons may let us ignore 85% of incomings – so that we can put strategic thought and discovery into the top 15%.
(Remember, we’ll only put 3 or 4 major things onto the roadmap, so any list longer than 15 is wasted effort. Asking Engineering to size 250 things so we can choose 20 that show “high theoretical ROI” on our spreadsheet is a criminal waste of their time.)
Seems too easy and imprecise to be useful
I’ve assumed a lot of context here, and ignored tons of reasonable objections. To be useful, Count The Digits and similar heuristics fit into a larger framework where we have strong customer insights and thoughtful goals/strategies/OKRs. ††
Here’s a scenario:
You’re a product manager at an Enterprise software company and get a blizzard of incoming requests and demands and tickets and suggestions and ideas. Each submitter expects a deep dive on their item including customer interviews and engineering estimates and hard dates. But that’s 20x more time than you can possibly investigate even if you spend all of your time sorting incoming tickets and ignore everything else product managers do.
Happily, you have some strategic underpinnings: a company strategy, a product strategy, and a few OKRs or other metrics around what’s most important for your product/portfolio.
- Company level: “Our Enterprise logistics software company needs to open up the mid-market ($20k-$80k), which will have lower ASPs but faster closes than our existing base ($100k-$700k). That’s our #1 challenge for 2025.”
- Product level: “Installation and usability are huge challenges for the mid-market, which can’t afford the outside consultants and long implementations of our whales. So our product focus in Q2/Q3 is on TTV (time to value) and highlighting each customer’s first big success.”
- Metric: “Our team’s key OKR is reducing total clock time for successful installs by semi-technical users. Tests with first-time users show an average 8.5 hours to install. The first insights don’t arrive for 45-60 days. We believe that cutting TTV roughly in half would also cut our non-renewal rate roughly by half, which would be $20M-$40M/year of top-line revenue.” †††
- Analysis: “Watching users in our lab… they struggle most setting permissions, importing their SKU catalogs, and finding the right reports. Let’s focus there.” (See Teresa Torres’ Opportunity trees.)
All of this means we could sort our own ideas – and incoming suggestions – into four piles: stuff that might help with permissions; stuff that might help with SKU imports; stuff that might help locate reports; and None Of The Above.
Now (finally!), we might grab 30 or 40 ideas for configuring permission and throw them onto a conference room table. With a common goal and metric, we can ask “which of these are intuitively the biggest wins?” and “what common assumptions work across most of the tickets?” and “if we count the digits, are any of these vaguely big enough to justify serious validation and sizing?” and “which do the designers and developers in the room think are non-starters?” and “is this metric leading us in the right or wrong direction?” BTW, I’ve never actually seen a spreadsheet or RICE algorithm solve these more strategic questions.
About those None Of The Aboves…
I usually see 40-60% of incoming tickets not matching any of our top objectives. Let’s use the same technique to handle those (very, very, very quickly).
Suggestion/idea: “If we switched our reporting engine in the Cloud to ProductX, online reports would complete much more quickly. I’ve heard several customers complain about slow reports.”
Polite engagement: “Hmmm. Before we dig into solutions, let’s scribble a few numbers. Guessing that 10-15 customers might have this issue… so maybe 3 or 4 might actually cancel over this… and ASP is $90k. So there might be $200k-$400k/year saved on renewals. But we’re focused in Q2/Q3 on improving TTV, which we hope will save $20M-$40M/year. Bigger, and already promised to the Board. So we’re holding off evaluating improvements outside our OKRs unless they smell closer to $2M. Give my numbers some thought, then we can revisit.”
(With some practice, this really can be a five-minute conversation. Also, I’ve found that the same 3 or 4 core assumptions pop up on most tickets, so I keep those guesstimates handy for comparison. Re-use, consistency, better guesses over time.)
The Language of Money
Note that we’re talking about business outcomes and strategic goals in the language that go-to-market (GTM) folks and execs use every day: money. So not doing something new that’s worth much less than our guesstimated outcomes is a reasonable response. It also avoids the jargon-filled process language that we love [stories, tech debt, architecture, backlogs, test harnesses, sprints…] but GTM hears as excuses or obfuscation or laziness.
SOUND BYTE
We get an onslaught of demands, and can’t do deep analysis on everything. Let alone build everything. So we need techniques to focus our effort on likely candidates and let the bottom 85% go. Anything really important will come around again. How do we put more of our energy into strategic work, market realities, and deep thinking – rather than the mechanics of managing infinitely long backlogs full of probable non-starters?
...
What About Our Customers?
The above is an internal discussion: how much money will we make if we do X instead of Y or Z? It's not useful for customer discussions. (FYI: customers are folks who pay us for our products. Our execs, stakeholders and other employees are not customers.)
There's similar math, though, to translate product capabilities/features into customer money stories. Product Marketing and Sales are hungry for these stories, even though the math is just as fuzzy:
- "Manufacturers who use our AI-based materials management software save an average of 7-9% on raw materials costs by reducing excess inventory. Your company spends €80M/year on raw materials, so we think you could save €5M - €7M/year by using our product."
- "Banks using our consumer address verification tool for pre-approved credit card mailings get 1.5% higher conversion rates and new accounts. Since you're sending 65k pre-approved offers per month and your Customer Lifetime Value (CLV) is $820..."
We often need to help prospects do the math, even with squishy inputs. They need something to run up their management and Finance chains for permission to buy our stuff.
† Yes, we can make the argument that fixing bugs improves Customer Sat/NPS or eventually reduces renewal churn. But those are generic arguments and very hard to trace back to any one ticket. Assuming that we’re going to fix some bugs, we might start with the ones that are most frequent or cost us the most support time.
†† Yes, most company strategies are a mess. And many organizations stumble the first time they try OKRs. But like Archimedes, we need a place to stand.
††† Before we spend months building something, we should know what our current metrics show and have a very rough guess about how much that improvement might be worth to the company – within 4x either way. See Melissa Perri’s Product Kata.