I’m part of many discussions where tech company execs try to apply Return on Investment (ROI) tools to make hard choices about what to build, or where to invest costly-and-scarce development resources.  It rarely turns out to be as useful as we hoped.  Where ROI is absolutely fundamental to pure financial decisions, it’s typically a very poor fit for the uncertainty and complexity of product/engineering planning and trade-offs.  And often makes the product team appear incompetent.  (Or makes Engineering appear lazy and disorganized.)  Let’s unpack some ROI challenges and propose alternatives.

Some reasons why ROI doesn’t help (as much as we’d like) with decisions about priorities:

[1] Both “return” and “investment” for big development efforts have huge error bars.  We usually focus on why Engineering (or Product) can’t estimate a piece of work accurately, but tend to ignore that our revenue (outcome) estimates are even less accurate.

• It’s nearly impossible to write a complete spec in advance for any major development project.  Instead, this is an onion (or fractal) problem: we understand the overall goals and architecture, then dig into the next big chunk to figure out how it needs to work, then uncover new issues.  Software systems have lots of layers, built on various platforms and third-party products, with complex logic and assumption-handling scattered throughout.  Our estimates necessarily don’t include exactly how we’ll validate data item X or define workflow Y or synchronize with the system of record.  So we’re constantly discovering/designing/inventing the details of how our next module will work.  After 40 years of engineering estimates, I assume that any big effort is undersized by 25% to 100% or more.  Hint: most developers are optimists.  [IMHO, anyone who claims the ability to accurately estimate medium-to-large development efforts is misguided, dishonest, or is building something nearly identical to previous work with exactly the same team.]
• Most future revenue estimates make development estimates look precise.  I’ve unpacked dozens of hypothetically huge revenue opportunities to find the uncertain assumptions underneath: “expanding into the European market would add $40M to our top line” is rarely scientific – guessing at actual vs. perceived customer demand, hidden competition, time-to-market, willingness to pay, obscure technical requirements, buyer inertia, etc.  I generally assume that our ‘one year from now’ sales estimates are 3x-10x too high.  Hint: sales organizations are strongly incented to over-estimate unserved product opportunities until it’s time to bake those into their sales compensation plans.
• Takeaway: dividing an uncertain number by another uncertain number (“R” over “I”) gives us a very wide range.  Most inputs are slippery, hazy, precarious.  Rather than “this project’s ROI is 2.4x,” I’d go with “this project’s ROI might be 2x to 9x.”  I’m unwilling to quick-decide that Project Thor (with future ROI of 3.9x) is actually better than Project Storm (with future ROI of 2.5x).  In fact, I round to the first digit and insist on calling out ranges (e.g. €4M  +/-  €2M revenue guess) rather than suggesting that 3.24 is any different from 3.76 or 2.8197.

[2] Financial portfolios aim for diversification and low correlation, but product portfolios don’t.  Every good retirement planner reminds us that as one asset class goes up, another goes down – so we spread our investments across government bonds and high-dividend stocks and startups and crypto – precisely because they don’t always move together, and we don’t really care which of them makes us money this quarter.
If we choose to add lots of unrelated features and disconnected capabilities to our products, they turn into Frankenstein’s monster: scary, unfocused, confusingly complex, and not solving the user’s #1 or #2 problem in a satisfying way.  Instead, our feature and project choices must be part of a product strategy – tied to painful customer problems – that we carefully curate to completely solve one or two essential Jobs To Be Done.  I’m constantly seeing roadmaps full of unrelated efforts that address 20% each of 5 different problems.  

[3] Risk goes up exponentially with project size.  We really can estimate small work items, and we really can estimate small revenue effects.  But the bigger (longer) our development effort and the bigger (juicier) our revenue hopes, the more likely that our optimism is clouding our judgment.  Agilists have been teaching us this for decades. 
My own qualitative/inaccurate working assumption is that 2x the effort means 4x the development uncertainty; 5x the future revenue guess means 15x the market/revenue risk.  Simple ROI calculations bias us toward huge future opportunities, away from better-understood incremental wins.
(Hint: one-year digital transformations take three to five years.  And migrating the last of our customers from our old platform to our new platform may take even longer.)

[4] Attributing actual revenue (financial value) to individual features or improvements is fraught, especially in large product suites and B2B/enterprise solutions.  When spitballing ideas, we are glib about how “adding this feature to our Bronze package will drive lots of upsell to our Silver package” or “integrating with ChatGPT will boost our new account close rate.”  But actually measuring that may be more sorcery than science.  For example, an enterprise company that closes 40 new deals/quarter can’t regress that against 8 new features.

Also: enterprise sales teams worldwide consistently report that we won major deals because of great salesmanship and lost any major deals because of product weaknesses and pricing and lack of flexible configurations. So our CRM “reason for win/loss” field rarely sheds much light.  This makes actual post-facto measurement of actual financial returns on individual features pretty suspect.  We seldom revisit our earlier ROI guesstimates to tune our thinking/methodology.

Said another way, ROI is a fundamental tool for financial analysis but wildly imprecise for difficult forward-looking product/technical trade-offs.  To a hammer, everything looks like an engineering organization unwilling to do precise-enough project sizing to let us choose major investments solely on the numbers.

[Frequent false analogy: “If I were building a house, I’d insist on an accurate estimate from the general contractor before we started.”  In real life, most of those projects run far over budget/time.  If you watch DIY/home improvement shows, you know that in 11^th minute of every 30-minute show, the crew discovers mold in the basement or an endangered species in the barn or an undocumented power line next to the foundation or a critical shortage of those lovely Italian kitchen tiles.  Changing specs is how contractors make their money.] 

[5] We’re also constantly doing technical work that doesn’t directly deliver revenue or cost savings, but keeps bad things from happening.  Security work, scalability, bug fixes, improved user experience, architectural simplification, better software development tools, meeting  regulatory/compliance requirements, onboarding and training new members of the team, tracking shifts in user behaviors, translating error messages for non-English-speaking audiences, planning platform migrations that don’t suck for customers… the list goes on. 

My decades-long position is that roughly half of all of the development work we do for in-market products is required for us to stay in business – whether we call that “keeping the lights on” or “business as usual” or “delighting users” or “not letting the wheels fall off the wagon” or “meeting our primary obligation to support paying subscribers.”  Not sexy but not optional – postponing all of it 'just for this one quarter' which always turns into 'just for this year' is a gift to our competitors and a short-selling opportunity. This work needs to be done, with or without ROI justification, or we end up with poor products, technical dumpster fires, customer churn, and updated résumés.

So What Do We Do Instead?

OK, so I may have convinced you that ROI is a blunt instrument, not useful for separating hypothetical 2.4x R&D returns from equally hypothetical 5.9x R&D returns.  Yet it’s a constant request from our Board and exec team, who deeply understand it in its original investment context.  A savvy CPO response doesn’t start with “hey stupid, ROI is worthless, my intuition and user insight are so brilliant that you should let me decide what’s next on the roadmap.”  Instead:

[A] Keep the discussion focused on top-level strategy and broad revenue ranges. Let’s pretend that your company has 2-3 Board-level goals tied to both revenue and new product work.  As product/engineering leaders, we should repeatedly and relentlessly connect those together.  "We’ve all agreed that opening up the Latin American market will be worth €30M-€40M next year, and reducing SMB churn with better onboarding/UX should put €8M-€15M on the top line.  Project Sisyphus doesn’t support either of those goals.  I don’t want to delay the 12 roadmap items supporting those top two initiatives unless we think Sisyphus is worth a lot more than our current goals...
And in the LatinAm swim lane, I'm happy to review each major work item that supports our €30M-€40M target.  BTW we may shuffle those around – or swap in something new – if it open up the market mas rapido."

[B] Use rough/vague team costs as a way to highlight risks and trade-offs. A typical whole product team of 7-9 people costs $1M-$2M/year, depending on where we are.  And half of that team’s work is keeping our current in-market products from flaming out.  So a one-year project for 3 teams (dedicating all of their available half time to this, and ignoring all other customer-facing work!) might cost $1M-$3M.  And our investors expect at least a 6x return, so we need to theorize $6M-18M in first-year revenue for this to pencil out.

That reframes the discussion from “can we build it?” to “do we feel strongly enough about our market sense to make this $M bet?”  Or perhaps “we’ve already committed 120% of R&D capacity on project P and product M.  Which of those do we want to postpone for a year to free up teams for this?  How much revenue did we postulate for P and M that we would have to replace?”

[C] Go on the offensive sometimes. When pushed for a hard delivery date and precise development sizing, I like to turn the question around.  “So if we commit right now to deliver Y at the end of Q2, will Sales commit right now to selling $5M of Y in Q3 and $8M of Y in Q4?  Called out separately in the 2026 sales comp plan?” 
That’s when the hemming and hawing start.  “How can we commit to revenue next year without seeing the finished product with complete feature detail?  What about new competitors or market changes?”  It’s not (just) to put Sales and Marketing on the spot, but to highlight that the biggest unknowns may not be on the development side.  And that good product discovery work helps reduce risk all around.

Sound Byte

When we’re in the executive suite, we have to talk the language of money rather than the language of product development processes.  That means basic financial literacy is a job requirement for CPOs.  But ROI is a seductive tool that (in my experience) isn’t as powerful as it seems, so let’s avoid using the wrong tool for the wrong reason.