Oct 26, 2017 6 min read

“My CEO is a Finance Guy Stuck on ROI…”

“My CEO is a Finance Guy Stuck on ROI…”

(combining a series of similar conversations)

Head of Product: My CEO is a finance guy*, and is pushing the product team hard to prioritize all engineering work solely on ROI. As VP Product, I’m having trouble selling him on investing in user experience, software quality, “meet the competition” features, and other work that doesn’t immediately convert to revenue. We’re both frustrated. How do I get my point across?

Rich: A great question! Before we dive into possible arguments, it’s worth framing some organizational realities:

  • The CEO job is tremendously tough. Your investors hired him to run the company for long-term value, but still thrash him every month about current revenue. Each VP is lobbying him on some issue. Endless meetings induce ADHD. And you work for him, so in the narrowest sense, he doesn’t have to “buy” your prioritization approach.
  • Most first-time CEOs come from some functional role: sales, finance, marketing, engineering, occasionally product management. (Or they are first-time founders who haven’t done any of these jobs before.) It’s natural for them to apply their familiar mental models to the broader company-wide problem, to “use what they know.” So far, your CEO’s ROI tools have led him to success.
  • A lot of product management is meeting customers and prospects where they are: finding language and benefits and arguments that resonate with an audience. The same applies here: we might try finance analogies to explain product strategy concepts. And then have a dialog about outcomes, rather than ROI spreadsheets.

So let’s see if we can recast product strategy and prioritization in financial terms. Humbly though, without talking down to the boss, and open to the possibility that we all learn something along the way.  Here goes…

[1] Engineering “spending” looks a bit like corporate budgeting

Corporate OpEx covers a range of departments and expenses that keep the business running, but aren’t all directly tied to current-quarter revenue. Sales has the clearest ROI (since we assign each rep revenue quota), but there’s diminishing returns in hiring more sales teams as we run short of marketing, engineering, recruiting, phones, and Accounts Payable. Plus, we have mandatory cost-of-doing-business areas (legal, HR, health insurance).

An engineering budget has some natural categories as well. (See my product pies.) For instance at a consumer/SMB SaaS company, we might expect:

50% spent on user-visible functionality, UX and customer requests

  • 20% on hosting, DevOps, analytics, scalability and security
  • 20% on quality, bug fixes, test tools and refactoring
  • 10% on staffing, training, engineering management and long-term research

[The numbers are fake but representative, measured in story points or some unit of engineering work. Look back at your own spending last quarter, or create your own pie slices.]

Within the hosting/DevOps slice, we want to sort projects or opportunities based on rough ROI, but with different units. We might pick some projects with high ROS (“return on scalability”) to prepare for Cyber Monday; high RONS (“return on network security”) to keep us out of the news; or high ROAI (“return on analytic insight”) to improve understanding of how our consumers behave. All are necessary for us to stay in business, none have a straight line to current-quarter revenue.

If we short our quality budget (as so many companies do quarter after quarter), we risk losing whole customer segments when our online service misbehaves. So it makes sense to sort this work based on qualitative ROQ: fund projects with the highest expected quality-bang-for-the-buck. Cost of staying in the software business.

[Gut check: three paragraphs in, is your CEO still listening? If he’s checked out or left the room, you should consider other approaches.]

[2] Short-Term and Long-Term Revenue Goals

Finance folks know that some corporate investments have quick payoffs and others take years. As well, different kinds of projects carry different risks. We could (for example) spend more on training our resellers this quarter, and expect more revenue/partner from them next quarter. We could add tech support headcount, to improved NPS by next year. And we might invest $M’s into new factory production equipment or acquisitions, which take years to hit breakeven. Timeframes and goals matter. So it’s important to be explicit about why (and how and when) something should pay off.

With software, we should have a strategic reason for each investment, not just a naked ROI. Back to our consumer/SMB SaaS product, this might sort improvements into a few sub-slices:

  • Upsell current customers. Our offering probably uses feature tiers to segment customers. Bronze is for occasional users (and is priced lowest), Silver has power tools for frequent users (higher price) and Gold adds delegated departmental security. Introducing something cool into our Silver tier may encourage a bunch of Bronze users to upgrade. An incremental $40/month * 5000 users = happier investors.
  • Retention, Churn Reduction, New Users. Subscription customers expect a steady stream of improvements and new toys throughout the year, not just what they got on Day One.  And getting new subscribers through our sign-up funnel could be easier. So we have to show our current customers love throughout the year by delivering incremental value that they don’t pay extra for. (We measure their love through reduced churn and higher renewal rates.) Likewise, better onboarding and customer experience will shrink our dropout rate. (Measured via conversion.)
  • New Revenue Sources. Some products are intended to open up entirely new segments or Jobs To Be Done. These should deliver clear incremental revenue. (Our ROI might match the cost of development against two full years of sales forecasts.)

All of these eventually translate into revenue, but in different ways and for different audiences. So we need to think about balances and trade-offs as well as raw ROI. Otherwise, if we invest only in new revenue sources, our current customers walk away and our renewal revenue suffers.

[Conversational note: we’ve gently hinted at product strategy here, but with revenue-related metrics that make it more approachable and less pompous. This should generate lots of tough questions from your CEO.]

[3] Risk-Reward Portfolios

The stock market demands higher rates of return for riskier investments, for instance BBB-rated corporate bonds pay more than T-bills, and 10-year notes more than overnight funds. Most smart investors don’t buy only high-yield, long-term securities, but build a diversified portfolio weighted toward lower-risk/lower-yield offerings. And they know that credit ratings have been very imperfect risk indicators.
In our product planning analogy, two huge contributors to software risk are project size and lack of rigorous validation.

First, large projects are much riskier than small ones: probably as the square of size. Even if we have a major initiative in mind, we get much more done – and dramatically reduce risk of complete failure – if we build and ship quarterly improvements to live customers rather than spend a full year engineering a huge monolithic upgrade. Delivering smaller increments to the market lets us discover wrong assumptions, adapt, and inexpensively replan. (See )

Second, I see the majority of product initiatives moved into the development cycle without thoughtful, objective, quantitative confirmation that they solve real problems for large numbers of users. AKA honest market validation. Instead, we go with “Someone in sales told me…” and “I hope…” and “I had a meeting with this one customer who…” and “Our CEO said…” and “The competition has announced…”

Osterwalder/Strategyzer: Managing Risk
Osterwalder/Strategyzer: Managing Risk

Having product managers do extensive, focused, serious field validation of customer problem and solution fit probably triples the likelihood of success. (See Alexander Osterwalder or Teresa Torres.) In risk terms, that’s a 3x payoff for not building the wrong thing. So CEOs should be pushing product managers for solid market evidence about problem definition and product/market fit, not just ROIs.  What do we know and how do we know it?  They should also view all ROI spreadsheets suspiciously: revenue and cost estimates are +/-50% at best, so there’s no difference between a 2.4x and 2.7x ROI.

Which means that savvy CEOs (from Finance or elsewhere) will weigh tough-minded market validations and right-sized delivery chunks at least as much as forecasted ROIs.

[Phew! If you and your CEO are still talking, this has been time well spent.]

Wrapping up, you’ve made strong financial arguments that part of the development budget is measured with ROI, but part isn’t. And ROI is only one of several tools to prioritize work. That gives your CEO a sense of where to lean in, and where to let other folks drive the process.

Sound Byte

Prioritization is really hard, especially since it means saying NO to lots of valuable things. Framing this for a particular audience may mean translating it into their own concepts or terminology. So we engage constructively by reaching people where they are.

* With apologies and noting English’s lack of inclusive neutral pronouns, I’m using “guy” for this hypothetical CEO. I vary gender across posts, opting for readability.

Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Rich Mironov's Product Bytes.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.