SaaS Conversations Podcast: R&D ROI With Jellyfish
In a new episode of SaaS Conversations, we sit down with Ryan Kuchova, Head of Customer Strategy and Operations at Jellyfish, to explore frameworks for measuring and managing R&D ROI in SaaS. We discuss strategies for optimizing R&D investment and how to encourage alignment between finance and engineering teams. This episode is essential listening for anyone responsible for R&D investment, cost management, or strategic planning in SaaS.
Key takeaways:
- R&D’s impact on revenue is nonlinear, shaped by factors like innovation cycles, market readiness, and time-to-market variability, making direct ROI measurement challenging but essential for strategic alignment.
- Using frameworks like OPEXEngine’s R&D ROI metric (current year’s revenue growth as a percentage of prior year’s R&D spend) and aligning R&D investment with growth targets (e.g., 30% R&D spend for 30% revenue growth) helps quantify the value of R&D in real-time and forward-looking scenarios.
- Operating model-specific and maturity-adjusted benchmarks are critical for context. For instance, a high-growth SaaS firm may need proportionally higher R&D spend than a more established one.
- Prioritizing the right R&D initiatives, assessing ROI with the right metrics, and continuously refining strategies are all key to driving long-term business growth.
- Beyond quantitative metrics, prioritizing qualitative insights, such as evaluating how effectively resources are deployed across growth-focused, maintenance, and support initiatives, helps refine allocation strategies and ensure alignment with organizational goals.
- The concept of DevFinOps – the fusion of R&D with finance and strategy functions of a business – is a critical ingredient for efficiency. Bridging the gap between CFOs and CTOs and finding means of “speaking the same language” is key to building a shared understanding of R&D’s role and impact on growth.
With Ryan's extensive experience working across finance, engineering, and product teams, this conversation is packed with actionable insights that every SaaS leader should hear. Ryan brings a wealth of practical advice to optimally measuring and managing R&D efforts and ultimately setting your company up for more efficient growth and profitability.
Listen now to hear all the insights and get actionable takeaways to apply to your own R&D strategy.
Click here to listen to the episode on Spotify.
Transcript: R&D ROI With Jellyfish
Host: Welcome to SaaS Conversations, a podcast from OPEXEngine by Bain & Company. Today, we're speaking about efficient R&D investment strategies and their impact on business growth.
“If I were speaking with a CFO today, my number one piece of advice is don't be afraid to ask for the information you've always wanted.” - Ryan Kuchova
Host: That's Ryan Kuchova, Head of Customer Strategy and Operations at Jellyfish. He explains the sometimes contentious relationship between R&D and financial returns, emphasizing measurement approaches for R&D ROI. Let's listen in.
Andy Rooks: Ryan, thank you so much for joining us today on SaaS Conversations – why don't we start with just a quick introduction about who you are and the role you have at Jellyfish.
Ryan Kuchova: Yes, absolutely. Andy, thank you so much for having me today. I’m excited to dive in. My name is Ryan Kuchova and I'm the Head of Customer Strategy and Operations here at Jellyfish. My background is a 50/50 split between operating and consulting roles. So I spent half my time working closely with R&D teams on all things technical and all things software delivery. The other half of my career has been focused in advisory in a consulting capacity working with CTOs, CFOs, board advisors, etc.
Jellyfish is a SaaS platform. We sit above the tools that engineers use day to day, and we're servicing insights to empower engineering leaders to get key insights into their organizations and work better cross-functionally. One of our most recent features is actually diving into AI’s impact and understanding what the impact of new code assist tools like Copilot are actually having on the engineering organization and the impact that they are having across their teams.
Andy Rooks: Oh, that's super cool. We would love to talk about that if we have time at the end, but why don't we start at the highest level. One of the things that we discuss here and one of the key metrics that we measure at OPEXEngine is R&D ROI, which we calculate as the revenue growth in the current year as a percentage of the R&D investment in the previous year. So tell me – because this is something that, obviously, Jellyfish seeks to measure – from a high, conceptual level, how do you approach measuring the ROI of R&D in this context? And what should CFOs consider when evaluating the return of software investments?
Ryan Kuchova: That's a great question, and I want to start with saying that I like the way you asked it. And what do I mean by that? You asked about the ROI of R&D and I think it is critically important to measure R&D as opposed to engineering as an individual function in R&D. So let's define R&D here as the combination of both engineering and product. And let's lead by addressing the elephant in the room on this topic. There's a very contentious – maybe complex – relationship between R&D and the bottom line, right? It's not a direct-line correlation, so it's actually really hard to get a good feel or a crisp measure of what the R&D ROI actually is. You look at the current year's revenue and compare that to the previous year's R&D spend. I love models like that, and I think that is because at the core, they are a great indicator to help you understand how you are performing against benchmarks.
But I think it's also critical to go a few layers deeper to understand the context. Are you above benchmark? Is that good or is that bad?
One of my favorite rules of thumb is that R&D spend as a percent of revenue should equal your growth rate. So if today, maybe you are doing your budgeting for 2025 and you might turn around and say, “Hey, we're increasing spend. This is a little off.” We start going through our current R&D ROI calculators, looking at R&D as a percent of revenue or whatever metric you're looking to go for. Now if you're trying to inflect your curve – you're trying to get to 40%, 50%, 100% growth depending on the stage of company you are at and what you're looking to do – you have to put that investment into R&D. So I think it's a great forward-looking momentum when you are trying to do your planning, as well as a way of getting that real-time answer to: “is our spend actually correlating to the returns that we are expecting?”
Andy Rooks: Oh, that's a really great way to look at it because you have backward looking R&D ROI or “how well did it work last year?” and [looking at the] impact on this year. And then you have this rule of thumb of matching your growth rate to your R&D investment. Do you have any examples of seeing that work on the client side?
Ryan Kuchova: To answer that question, I actually want to offer a little bit of a framework – going back to the original question – and then talk about how that correlates to what we have seen in the market.
When I think of a framework here, what I really want to do is make sure that when people think about even R&D spend as a percent of revenue matching your growth rate or R&D ROI as you characterize that in your historical analysis is making sure that people get the context. And so there are three core things that you should be thinking about when you tie it to ROI:
- The first is understanding, even if you are at your number, are you effective? Are you working on the right things? This is your absolute biggest lever to understanding R&D ROI and driving effectiveness across that. So what do I mean by that one specifically? You should be able to characterize your work for every product in your portfolio. How much of your R&D spend is going towards growth, that new product that is supposed to drive net new revenue for you.
- I think about “KTLO” as the second bucket. We're just keeping the lights on. That's infrastructure, that's maintenance, that's technical debt, and things of that nature. This is helping you understand your bottom line, if you will. You have to do this work regardless.
- And I'm going to characterize [the third] as support, which is anytime engineering gets involved in customer work, whether that be implementations or support or escape defects – things of that nature. That's a great proxy, for example, of unit economics. So make sure you're working on the right thing.
The second area or component of this framework is: are you delivering effectively? Now a key note here is do not be myopically focused on trying to get your team to be more productive. Don't try to squeeze water out of a rock. Every team has things they can do to be more effective – whether that be removing bottlenecks, improving tool sets, enabling the teams, etc. – but if you are myopically focused on that, you are going to miss the forest through the trees because telling people to run faster and jump higher just does not cut it.
So instead, focus on other key questions like are you making the right trade-off decisions? Are you producing quality output? And maybe most importantly, are you actually achieving the intended outcomes? If you are focusing on a feature looking for certain revenue growth, are you actually getting that? Are you seeing the sales lift? The last bucket here is: are your resource costs optimized? And what do I mean by this? This isn't always about finding low cost geography or looking for the lowest cost resources. This is actually something slightly different.
The things I like to hit on first are your employee sentiment and retention. A good model that I've used mentally is replacing a resource in engineering is sometimes characterized as somewhere between 1.5x or 2x the cost of that engineer. You want your people to stay. You want your best people to stay. You want everybody to stay if they're enabled and driving good business, right?
The second is: are you efficiently deploying your resources? So you have a Palo Alto data scientist at $400,000 or $500,000 a year working on support tickets. That might not be your best bet, right? So you have to have that level of view into what they're actually working on and is it tied to the return for the individual resource?
The last bit here I like to characterize as ROI – but in a different context. I think this is more like deliverable ROI and specifically measuring, are you able to spend what you anticipate on a deliverable?
So given that framework, have we seen this come into practice when you think about R&D as a percent of revenue matching the growth rate of a company? We get to see this across all of our customers, and what we often see is that when one of those three levers is not where they want it to be or has significant room for improvement, the balance is thrown off. What you're starting to see now is those companies are actually running into situations where they start to diverge. The growth rate starts to drop. So in conversations we have with our CTOs, CFOs, or whomever, they start saying, “Hey, we're not delivering. Can you help us understand what's going on?”
Companies who are able to stick to those three buckets figure out what exactly makes sense in their business and measure against those.They are actually able to maintain and maybe even get additional leverage, where maybe they are spending at 20% but growing at 30%. They are finding that these levers are actually the biggest ones to inflect that curve and actually get above that line, if you will – where they're actually at a lower percentage but growing faster than the percent of spend as a percent of revenue.
Andy Rooks: Oh, that is a really cool way to look at it. So we are starting to also bridge the topic of investment going into that. I would love to shift the conversation a little bit to the relationship between the CFO office and the CTO office. There are some common friction points that will come up – what are some things that you have seen there and what have you seen be successful in helping mitigate those friction points?
Ryan Kuchova: That is a great question, and at its core, engineering is a nonlinear endeavor with varying degrees of complexity. That on its own can drive tension between engineering and every function. You'll have everybody ask – the sales and marketing is like, “When is this feature going to be done? I need to be able to sell it. When can I put it in my projections? I have a whole launch process – when can I kick that off? What is it actually going to look like? What is the end feature going to be?” And they can build on that friction or tension in between it.
Finance might wonder how much something is going to cost or how much you spent on something. They might need inputs, they want to do annual planning, and they are not getting what they need. So you find this natural friction in many organizations between engineering and the broader business.You think about the idea of engineering being this complex black box at times. It fundamentally makes the questions that these other departments are asking to them extraordinarily hard to answer. They might even be impossible in some ways.
I think it breaks down to three key areas:
- The first comes from this idea of when finance is seeking an exact answer or R&D perceives the seeking of an exact answer. What did that feature cost? Or a specific process, for example, cost capitalization or R&D tax credits? Who worked on what and for how long? And in what month? When did this thing release? Is it actually ready to go? Etc.
- The second area of friction is when engineering and finance are speaking two different languages. For example, they are going to answer a question like what headcount is needed for next year? Are you improving productivity of your team by 15%? Then why can't we have 15% efficiency gains on our headcount model for next year?
- And the third area where I see friction start to come up is when engineering is treated as a silo. We talked about that just a minute ago – as opposed to putting it in partnership with product – getting more to the insights and the actual question behind the question keeps the conversation at the right depth.
Andy Rooks: Right, and I think that is a really great way of putting that, in terms of speaking that common language. One of the things that we do at OPEXEngine when we benchmark R&D is try to break it down into: here's the percentage spent on net new features versus technical debt versus so on and so forth. We look for those specifics and hopefully have language that is spoken by both teams. [The teams will] have to collaborate if they are going to really get to the bottom of not only their performance, but also their benchmarks and how they measure up. So that is a really great point.
I want to skip ahead a little bit. You’ve written about the concept of DevFinOps. Tell me what that's all about. What is this in terms of a workflow? This may be a new concept to our listeners, so I would love it if you could bring us through that.
Ryan Kuchova: Absolutely. DevFinOps really represents the fusion of R&D with finance and strategy functions of a business. On its surface, maybe its thinnest definition, it means opening those communication channels that we were just talking about a bit and reducing the friction points between engineering and finance.
So for example, software capitalization and R&D tax credits, spend by product, and things of that nature. As you dig deeper, DevFinOps actually represents a few more things, right? It's actually helping serve critical insights to ensure that R&D and the company strategy are aligned. Every year in annual planning, engineering leaders want more. Finance is not going to give them all of them. Why do you actually need it? How do you communicate that? How do you change that conversation? How do you make that headcount case? What growth targets are achievable? Addressing the relationship between R&D effectiveness and EBITDA margins, if you will.
So DevFinOps is actually the fusion of all of that. It's bringing together the key insights inside what's often a black box (that is engineering) and surfacing that and saying “Hey, here's what's actually happening.” Here is a way of understanding and communicating it and also doing so in a frictionless way. So engineering leaders can focus on building while finance leaders, strategy leaders, and others can focus on, “what does that mean to our business and our long term growth objectives?”
Andy Rooks: So that's a pretty interesting way that an engineering group or an R&D group can communicate back to finance leaders. I wonder about the other side of the coin a little bit. What are ways that finance leaders can communicate with the engineering leaders and the R&D leaders and find common ground with metrics? Have you seen any of that?
Ryan Kuchova: That's an excellent question. I think it's a question that's eluded software teams and software organizations for all of the history of software to some extent. I think what you're really asking there is how to finance teams say, “Hey, I need X in terms of efficiency out of engineering and here's how I'm going to measure you.”
And largely what DevFinOps will help do from that perspective, and even more broadly what we're seeing across our customer base, is when you do establish that common vernacular, right? And [finance] might say, “Hey, we need a certain gross margin on this product.”
That conversation will never be successful if an engineering leader is talking about the technical debt that they want to remediate, right? Or if they're talking about the complexity of the team, or [that they] don't know what a product might look like in 6 months, or if they're talking about sprints and story points.
None of that will ever move the needle. So what we have actually seen as successful is in that common vernacular or how they talk is instead saying, “Hey, we're not seeing, for example, the gross margin we're looking for on product X, right?”
If you go and look at allocation of work – and we talked about that framework a little bit earlier – you're working on the right stuff.
What we often see is the ability to say, “Okay, we're putting a lot of cumulative spend into product X, and a lot of that is actually going into support. What's actually happening there?” And you're changing the conversation where an engineering leader can say, “Oh because we haven't solved some technical debt that we have out there. Or we haven't released some component that's not revenue driving. Instead, we're actually taking engineering resources, which are not the cheapest resources in the world, and we're deploying them to do functional work that could be productized. Or maybe we're moving too quickly and haven't gone back to address some of the bugs that we released into production.”
By establishing that framework and talking more about outcomes, we've actually seen that finance leaders are asking better questions that can be answered by CTOs and it allows them to have a more constructive conversation.
Andy Rooks: It just goes to show how much of a pain point it can be between these two teams if they're speaking very different languages and they're looking at different metrics. It's important to be outcome-focused. I think that's one of the themes you are driving at here – how can we construct a collaborative environment where we can be more focused on: here's how we help the business together. And maybe that involves being open in the way that we communicate that.
So I want to segue a bit to the next question here in terms of impact on the long term. We were talking about short-term projects; talk to me about impacting the long term of financial planning. Do you see this as an advantage?
Ryan Kuchova: I see it as one of the biggest competitive advantages that a company can have. We talked about, like you mentioned, in the micro – we are looking at a quarter of planning or maybe annual planning. In strategy you're looking at 3, 5, or maybe 10 years out – depending on size of company – on multiple horizons. If you think about the slight deviations that happen when it's not a software informed strategy or when the team's not running as effectively as it can – those small assumptions compound on top of each other and end up in this divergence by which companies become ineffective. If you're a publicly traded company, are you actually going to be able to give accurate forecast if you don't know whether your team's able to deliver said feature?
Or maybe you're working to get to an acquisition. Absent that common vernacular or absent the insights that you're seeking in DevFinOps, you end up in this world I think we've all been living in for a bit too long. [A world where] finance leaders are struggling to understand what they're seeking to be able to model that out (whether it be in their go to market model or their spend model or their P&L – whatever it might be).
They want to make sure they understand where things will actually be, and I think bridging that gap – in my mind – is one of the biggest strategic advantages you can have because eventually these things catch up to you.
Andy Rooks: That's really powerful. Thinking about the future, these functions are going to become more and more interdependent. It's a competitive advantage, as you mentioned.
What advice do you have for CFOs that are seeking an outcome like this? If you could give advice to a CFO client right now, what would it be?
Ryan Kuchova: That’s an incredible question. If I were speaking with a CFO today, my number one piece of advice is: don't be afraid to ask for the information that you have always wanted. And don't look at that with, “Oh, I want to know exactly what's happening in engineering.” That's not what you're really asking. You actually want to know: what is that spend by the product? Why can't we get higher gross margin? Why can't we move faster? Why do you need that extra headcount? Seek data driven answers that are in an insight or at a level of depth in a vernacular by which you can actually challenge your technical counterparts.
The second thing I challenge you on is the role of efficiency. Now, remove all friction points that are not value additive to your business. If there's a rote task or if there's process reporting, all of that should be automated.
Seek those little points of competitive advantage. For example, automating your cost capitalization, your R&D tax credits, or your spend by product analyses. All so you can spend more time collaborating on what you do with that information versus deploying sets of folks and valuable capital to be able to do a reporting that helps inform your strategy.
Andy Rooks: Yeah, and that will be a cultural win too for the engineering team. They'll appreciate that that bit is being automated so that they can focus on the more interesting strategic tasks as well.
Ryan Kuchova: Spot on. I think what you don't want to have engineers do is not building product. They don't even like working on bugs sometimes, right? Oftentimes they want to build the next competitive thing. So if you can move that off your plate, it would increase the general sentiment of the team. It might drive greater retention, and you can have some incredible cost savings from that type of work as well.
Andy Rooks: Yeah, brilliant. That just about wraps it up. Thank you so much for joining us today, for sharing, and for speaking to me. The relationship between finance and R&D – it's a huge topic in the space and it’s top of mind, so thank you so much for joining us. We really appreciate this great insights.
Ryan Kuchova: Andy, thanks so much for having me. It was a great time.
