For a long time, I've been asserting that most* B2B revenue-side executives can´t hear anything we say unless it includes a currency symbol. Sentences lacking a $ or € or £ are inaudible. That includes explanations about how we build things: roadmaps full of boxes and project names; agile methodologies; analytics that show how smart we are; inspirational lectures about product operating models… mostly wasted words that our GTM leaders are not interested in.
Over and over, we product leaders pitch only the technical or qualitative part of our arguments… about why one thing is (directionally) more important than another; how one more project will undercut (generic) delivery dates; the organizational (but not financial) impact of sales-driven one-off commitments; the emotional and morale costs of blowing up our roadmaps month after month (without identifying lost market opportunities). We often lead with the weaker portions of our recommendations.
I call this not finishing the sentence. Not translating technical pain and overcommitments into money. Not putting our audience's concerns ahead of our feature lists. Not closing the sale. We assume that our C-level GTM partners will remember last quarter's painful roadmap trade-offs. We assume that they are fascinated by the minutiae of building products. We assume that they understand and appreciate why engineering dates are optimistic estimates. We assume that they can consistently connect the dots between R&D deliverables and revenue.We assume that they can consistently connect the dots between R&D deliverables and revenue. Wrong, wrong, wrong and wrong.
We makers (product, engineering, design) live every day in our roadmap details and technical trade-offs, so (mistakenly) expect the rest of the company to track these as closely as we do. To remember our caveats and specifics and subtle inferences. To be entertained by our codenames. To retain every word we've ever spoken, in context. Would that it were so. In the real B2B/enterprise world, revenue-side execs* are busy with other things, easily distracted, and not fascinated by how we make stuff – so they tend to ignore our recommendations when we don't frame them in terms of future revenue.
HOW ABOUT SOME EXAMPLE MONEY SENTENCES?
Compare:
- "If we pull the platform team off our planned roadmap work to do Big Customer Thing X, we'll push back platform delivery by another quarter."
vs.
"We've agreed that the 3.0 Platform will enable new products worth $10M-$25M next year. So delaying that for Project X may cost us $3M-$6M per quarter. Plus the market risk that we may miss the market window. Is X big enough to fill the revenue hole this will create?" - "That's a great idea, but we need to size the engineering work and do product-led discovery. Maybe next quarter. How important is this (to you), and where do you think it fits in our product strategy?"
vs.
"We've already pulled 30% of Engineering off planned roadmap work for the JPMorgan Chase custom integration and Volkswagen real-time reporting one-off. Pulling another team off core products means no major new features next year, which jeopardizes a third of our €50M 2026 growth target… which assumed product improvements A and B and C. Will Sales commit to 2026 goals without those? Should we de-commit on JPMorgan or Volkswagen?”
- "If we pull the platform team off our planned roadmap work to do Big Customer Thing X, we'll push back platform delivery by another quarter."
vs.
"We've agreed that the 3.0 Platform will enable new products worth $10M-$25M next year. So delaying that for Project X may cost us $3M-$6M per quarter. Plus the market risk that we may miss the market window. Is X big enough to fill the revenue hole this will create?" - "That's a great idea, but we need to size the engineering work and do product-led discovery. Maybe next quarter. How important is this (to you), and where do you think it fits in our product strategy?"
vs.
"We've already pulled 30% of Engineering off planned roadmap work for the JPMorgan Chase custom integration and Volkswagen real-time reporting one-off. Pulling another team off core products means no major new features next year, which jeopardizes a third of our €50M 2026 growth target… which assumed product improvements A and B and C. Will Sales commit to 2026 goals without those? Should we de-commit on JPMorgan or Volkswagen?” - "It's great that Onboarding and Post-Sales Support voted up their 40 top fixes and improvements. We'll put those into the backlog."
vs.
"Support confirmed that the top predictor of churn is whether new customers do two or more transactions within the first week… but we lack analytics on that. And you've identified that configuring multi-factor authentication is the #1 blocker during onboarding. Every 1% we reduce churn adds £800k+ to the top line. Our top two roadmap items could drive 2-3% improvement for £1-3M incremental revenue. We will work on those first. Meanwhile, let's figure out what should be next."
Finishing the product sentence means including some (squishy, imprecise) future guesses or ranges about how much something might be worth.
My contention: until we frame product/engineering decisions as Exclusive-OR choices and attach vague order-of-magnitude financial outcomes to them, we're surrendering strategic product decisions to whichever exec is brave enough (or politically astute enough) to make up their own numbers. Until then, we're bringing a slide rule to the leadership gunfight. We must instead speak the Language of Money.
Talking qualitatively about platforms or architecture or agility or team morale or design systems doesn't frame hard choices for the C-suite. Saying something is "important" doesn't identify the specific item that's less important and would be canceled to make room for this new thing. Pontificating about product operating models deeply frustrates most GTM execs, who hear it as "product managers think they are smarter than everyone else, and want to make all of the decisions, when they are the ones slowing down delivery."
BUT THIS IS HARD!
Yes, for lots of reasons. BUT IMO guesstimating a project's value — before we start, before we spend major resources, before an important project is sacrificed to this week's hot deal — is essential to managing the chaos of C-suite roadmap ADHD.
SOME OF REASONS WE DON'T DO THIS
[1] We are not enabled, encouraged, or expected to do this. Shouldn't Sales forecast what a new product or feature is worth? Shouldn't Finance have a template or model good to three decimal places? Can't Support calculate how much we'll save if we fix bugs X, Y and Z?My observation is that most can't or won't.
Sales has little incentive to commit to product-specific revenue quarters from now, ahead of any individual customer's reaction to prototypes and details. And they aren't paid to dig into the fussy bits of use cases or data structure or assorted workflow choices. Besides, their expectation is that every big opportunity will need something a bit special, regardless of what's on today's roadmap.
Finance tends to focus on matching effort to SKU-level revenue. (Which might work if we charge separately for every feature.) And they have the irrational belief that we can predict the future to 4 decimal places. Marketing tends to be more interested in benefits and headlines than specs. Etc.
Maybe there is someone in your company who is better equipped to guesstimate the far-off results of major product initiatives. If so, sing their praises and ply them with drinks! Otherwise, we (product folks) need to do the work here: matching the fuzzy front end of what users/markets want with the fuzzy front end of money in/money out. If not us, then whom? And if not now, when?
[2] We don't know how to do this. Yup. Not part of a typical PdM job description, or podcast/blog post, or an explicit part of our training. And we often wait until long after a major commitment to start assembling a business case – when it's way too late to change direction.
See my lightweight approach in my Count The Digits or Business Cases Are Stories About Money or this Product at Heart Money Stories video... in short, I like to use no more than 3 numbers, with only the multiply operator. Simple enough that everyone can see where we're going and argue about our very few inputs. Such as…
- Upsell revenue?
installed base * upcharge amount * wild guess range of uptake
(5000 customers * €1000/year * 1-4% take rate = €50k-€200k/year) - Feature to close more new deals?
number of lost deals attributed to missing feature * average sale price * wild guess for how many would really have bought
(150 deals this year blamed on this item * $15k ASP * 5-10% we really believe would buy = $100k-$200k)
Our goal is NOT to be accurate or precise, but to quickly guess at the number of digits. Is this a 5-digit idea ($10k-$80k/year) or a 6-digit idea (€100k-€800k/year) or an 8-digit idea (£10M-£80M/year)? That lets us push back on executive fire drills about 5-digit interrupts by spitballing business outcomes instead of explaining development processes.
[FYI, I don't find it useful to justify long lists of small non-optional items with exec teams. We need to consistently allocate effort to UX/design, quality, performance, security, architecture, lightweight competitive items… but revenue-side leaders get frustrated wading through our long “keep the lights on” lists. I want them focused on the few big trade-offs that routinely torpedo product plans.]
[3] We're very uncomfortable predicting an uncertain future, offering up guesses, speculating about revenue or impact or improvement a year from now. Yup. As product folks, we value accuracy, precision, and analytics anchored in deep data. We want to tell the whole truth, and nothing but the truth. Hypothesizing on scant information feels wrong. But it turns out to be useful. And lots of good decisions can be made with order-of-magnitude judgments.
[4] Guesstimating impact for everything in our roadmap seems daunting, bottomless, wasteful. Agreed, let's not do that. I find this technique most useful to drive agreement about a few top initiatives, and to quickly discard incoming suggestions that don't make much sense.
Framed as conversations:
- (With Sales and Marketing leadership) We're probably going to spend $1-5M** building New Product Z, and our investors expect a 5x return on R&D. So before we put Z on the roadmap, I'd like Sales to paint a revenue picture in the $5M-$25M range, and Marketing to soft-commit that they can drive enough interest. Otherwise, we need to do more market sizing or move onto the next topic.
- Our development teams each cost €20k-€35k** per week, so we're not going to override their judgment on anything under €60k. They are great at finding small wins, fixing P1 bugs, understanding our end users, and balancing UX/ supportability/ infrastructure with customer-visible work.
BTW, since we will never, ever get to the bottom 85% of our backlogs, sizing everything in the backlog is fundamentally a bad idea. So quickly dispensing with low-value stuff lets us focus on what matters more.
SOUND BYTE
On the maker side, we communicate with each other in our maker language. That doesn't work well with revenue-focused executives and departments. Translating tech into the language of money, especially with quick order-of-magnitude impact guesstimates, makes us active participants in the leadership conversations we may have been missing.
______________________________________
* Yes, I'm being reductionist, caricaturing CEOs and GTM-side leaders. Yes, we've all worked with that rare VP Sales or founder CEO who really "gets" product and truly cares about how we build great stuff. But across my decades of managing product internally, my 15 interim CPO gigs and my thousands of hours coaching product leaders… they are unusual, atypical, outliers.
Especially at B2B/enterprise tech companies and internal R&D/IT organizations, I've seen a large majority of these execs demonstrate deep disinterest in how Engineering+Product+Design get things done. And react badly to our long-winded lectures about agile, discovery, product methodologies, fuzzy front ends, and reasons why we can't accurately size development work. "How hard could it be? It's probably only 10 lines of code. And AI should make this a snap."
BTW, Kent McDonald has some of the sharpest insights into internal R&D/IT organizations. Find him here.
** Ten years ago, I estimated that Your Next Developer Costs $1M/Year in Revenue. Said another way, each development team may cost $1M-$2M/year (depending on geography, team size, etc.) Typical investors expect 5x returns on R&D, or $5M-$10M+ revenue per team, and I don't yet see AI changing this. So if a major platform re-architecture might take 10 teams a year or two, we can ballpark the cost at $15M-$30M... and ballpark the opportunity cost at $75M-$150M. A back-of-the-envelope estimate can be very helpful in deciding if that’s a reasonable investment.