Battery's Take on Managing and Measuring R&D Spend

Live from Schenectady, New York, it's SaaS Talk with the Metrics Brothers, Growth and CAC.

And I'm Growth, better known as Ray Reich, founder and CEO of Benchmarkit.

And I'm CAC, better known as Dave Kellogg, EIR at Balderton Capital, independent consultant, and the author of Kellogg.

And together, we are the Metrics Brothers.

And we go together like research and development.

R&D, Keck, we're go-to-market guys. Why are we talking about R&D? I think I'd actually like to go back to food pairings.

Wow, food pairings. Well, first, Ray, to help with our New Year's resolutions, don't want to be tempting you at the start of every episode and vice versa. And second, because today we're going to be discussing one of the hardest measurement problems in enterprise SaaS, which is R&D.

Well, Battery Ventures recently wrote an interesting post on R&D, I believe.

Yeah, they did. It's called Decoding the Black Box of Software R&D Spend. It was written by a good friend of mine, Max Shearson, and one of his colleagues, Jason Mendel. And we're going to use that post today to guide our discussion here.

Okay, so before we do that, let's hear a word from our sponsor. The Metrics Brothers is proudly sponsored by Benchmarkit. The B2B AI and software industry's largest, broadest, and most contextualized benchmarking index. Dave Kellogg and Ray Groth-Reich have put the Metrics Brothers podcast on hiatus for the remainder of 2026. All episodes we have ever recorded are still available on your favorite podcasting app. You can reach Dave at Kellogg and Ray on LinkedIn at Ray Reich. Thank you so much for listening to the Metrics Brothers podcast.

So, you know, Ray, software companies spend about twice on sales and marketing what they spend on R&D, grosso modo. And thus, sales and marketing, it gets a lot more attention, not only because we're spending more on it, but because it's kind of infinitely more measurable, uh, and because, you know, everyone's an expert. A lot of the VCs are financial types, a lot of the independent board members are former go-to-market types. So there's a lot of energy and understanding put on analyzing go-to-market metrics. Um, but people don't put as much energy, like almost at all, into talking about R&D. So, you know, Ray, there is a— when it comes to metrics, there's a modest correlation between R&D spend and growth rate. So I, I would not attempt to tell my board that we should go spend more on R&D to grow faster using this data. But, uh, if you look, I think it's in Battery's post that people grow Yeah, it is. People growing less than 15% are spending on average 22% of revenue on R&D. People growing 15 to 25% are spending 26% of revenue on R&D. And people growing faster than 25% are spending 31% on R&D. But look, in the end, no matter how you slice it, software companies still spend a ton on R&D. So it might be half what you spend on sales and marketing, which is kind of 2 tons, but in R&D, they're spending on average around 30%. The range to me is typically somewhere between 20% and 40%, depending on your stage of evolution. That's a lot of money. R&D is a critical area. Product matters, right? Even though we talk about go-to-market here, I know we both believe that product matters. And because nobody's really an expert in it, we don't talk about it that much.

Totally agree with that. But, you know, Lauren Kelly at OPEX Engine did some interesting work that I'd love to share, if that's okay.

Yeah.

So, you know, we, you know, you're CAC and we like the CAC ratio, right? So we look at to get $1 new ARR, how much do we spend in sales and marketing? Well, they did something similar for R&D where they took the new revenue in a current period. So let's say it's calendar year 2024, and they divided that by the R&D investment for the previous year. Now, Lauren said the reason we did that was we think it takes at least 12 months for R&D investment to start paying off from a revenue perspective. And what they found, Dave, and it's very similar, it depends on stage of the company, but companies were getting anywhere from $0.80 to $1.40 in new revenue for every dollar they invested in R&D in the previous year. So I thought that was a really interesting metric about R&D return on investment.

Yeah, I think it's an interesting, interesting, kind of interesting metric. It's one of a class of indirect R&D productivity measures that people try to do. I don't personally like thinking of this as an ROI metric, that's too much of a stretch because the linkage is too loose, right? What's gonna drive new revenue growth is far more related to investment in sales and marketing than it is to R&D. Reductio ad absurdum, I could cut R&D to zero and I'd still have new sales next year. Some PE people try to do that, just kidding.

Right.

But the formula doesn't work on the boundaries, But I get it because it's not easy to directly manage R&D. Many people, including our friend Lauren at OPEX Engine, come up with these indirect metrics.

Yeah, and I don't wanna jump ahead, but if you're looking at new product or expanding your current product portfolio, that is one measurement you want is how much revenue is this gonna drive, right, for a new product?

Well, certainly, yeah.

When you've launched a new product, that's a special case where things are kind of measurable because you know how much you spent to build it. And you know pretty quickly how much of your selling of it. So, that's a case where you can do it. It's one of the cases I highlight in this episode, where by breaking down the R&D budget, you might be able to get kind of ROI on different pieces of it. But in my experience, Ray, when you dig in, and if you go to QBRs and ops reviews at software companies, here are some of the metrics you might hear brought up, not so much in a board meeting, but more in a QBR, you might hear about story points, right, as an attempted productivity measure. And this is really a misuse of the concept. I think story points are primarily about breadbox sizing or t-shirt sizing, right? This project is small, medium, large in terms of effort, and not really to be used as a productivity measure, although I have seen people try to use them that way. You'll see bugs used pretty commonly as an R&D measure, but it's kind of a weird negative measure, right? I don't wanna only measure my software development team by the absence of bugs. Uptime, really a tech ops measure, a very important one, by the way. I mean, systems need to be up. Test coverage, at some SaaS companies, particularly kind of immature ones, they don't even have coverage for most of their code. So you can put it at a very rudimentary quality measure. Sometimes people will go higher level and try to use GRR, gross retention rate, which is a coarse measure that may or may not be product-related. You may have a wonderful product, but a new entrant that came in, Google announced a free thing, and you're losing business to that. It doesn't mean your product got worse.

Right.

Or it could be you have very bad implementation and support, so people don't renew, right? There's a bunch of reasons why people don't renew. Product is just one of them. So, you'll also see people try to use CSAT in this way. They'll do either overall customer satisfaction or in their survey, they'll do product satisfaction. But really, nothing kind of measures R&D itself. Thoughts, Ray?

Yeah. Well, I remember when, you know, we first started using story points in one of the companies where I was the CEO. I said, you know, I understand how you're doing story points, but let's actually measure lines of code as a productivity metric. You should have seen the looks I got, Dave. It's like, man, you really don't get this if you want to measure software productivity by lines of code, because it doesn't mean that the code is going to be efficient, effective, or work as advertised.

Yeah, yeah, it's definitely a less-is-more kind of problem. I remember one of the companies I ran, the chief architect was famous for— a developer would check in code, and the next morning, they would come in and find it rewritten, because he would literally look at it and just rewrite it rather than give comments on it. And his rewrites were like a quarter as long as the original code, right? So this guy was so good that people would just say, you know, they wouldn't even fight. They were like, oh my God, it does everything mine did in a quarter of the code. So in that case, you actually, you know, much like the old saying about, I didn't have time to write you a short letter, so I wrote you a long one, it's the same thing. more is probably worse. So, yeah, lines of code is a terrible metric. I think we can agree on that. I do think— so it was amazing. I was thrilled when I saw that Max Shearson, a good friend of mine and one of the smartest people I know, had written this post called Decoding the Black Box of Software Spend, because I was hoping to find, ah, you know, they've cracked open the key, they found the holy grail of R&D productivity measurement. And while I still recommend reading the post, Ray, I don't think it does that, but in a minute, let's just talk about what it does do. But before we dive in, any more kind of intro thoughts?

No, because what we wanna dive into next, I really like because they have some benchmarks with some of these metrics they are recommending, Dave.

Sure, so let's dive in. So this post, as far as I can tell, was actually inspired by one of their portfolio companies, LinearB, that sells what I'm just gonna call roughly an engineering metrics platform. And this is an emerging space in SaaS. I actually have an angel investment in this space with a company called Ferrous. And these products are designed to basically better help you manage engineering, and they give you lots of metrics and dashboards. And in this post, they talk about metrics in really 3 areas. One, efficiency, metrics like merge frequency and deployment time. DORA metrics, DevOps Research and Assessment, like deployment frequency, change lead time, change fail percentage, and failed deployment recovery time, so super operational. And then metrics like quality and predictability, refactor rate, Rewrite rate, planning accuracy, and all the stuff to me was interesting. I think the post is worth reading, but to me, Ray, it's really not going to be useful at a QBR level, let alone a board level. So, I think these are really almost engineering review meeting kind of metrics, not C-level metrics. Thoughts?

Well, I guess the only thing I would say is maybe not at the board level, but definitely at the executive team level, right? When we have our Quarterly goals and objectives. And we all want to know what the other, you know, our peers are doing. Because the benchmarks that LinearB provided, things like the rework rate, right? It showed that elite, which is the best, they had less than a 2% rework rate, while companies that were only fair had a 5 to 7% rework rate. Or they did things such as deployment frequency. How quickly are you deploying? new software, which is the DORA metric that you mentioned, right? You know, best in case is they do it more than once a day, and needs improvement is less than once a week. So, I actually really did like some of the metrics and the benchmarks because it gives me a feeling as a CEO, how is my development team doing against similar-like companies?

Yeah, I think it's a fair point, Ray. I may have gone too far. I don't believe I'd bring these metrics to a board meeting. But I do think they're appropriate for a company-level, i.e., a C-suite QBR for the engineering update. So I'd agree with you there. And again, this post is full of those metrics, so go read it. I found the primary value in the post at the next level up, however, because they do 2 things in this post. They talk about some of the operational metrics that Ray discussed. And for me, the real value came when Jason and Max proposed a 5-step framework for measuring and allocating R&D budget. And those 5 steps are: 1, allocate top-down. 2, break R&D into granular buckets, of which I am a massive fan. 3, listen to product-adjacent teams that are customer-facing. A lot of syllables, but an important point. 4, be deliberate about measuring the success of R&D projects. And 5, hold the whole team accountable. Great.

You know, I really like this because it reminded me, and when we first started doing the SaaS Talk podcast, McKinsey and Company had just recently released their Can You Measure Software Productivity? And it was, it created a firestorm on Twitter/X. And they had a similar framework where they focused on outcomes, optimization, and opportunities, i.e., new products. So I really like this framework because I do think being an ex-sales guy, I was always measured every quarter, right? I love the idea of being able to measure the, basically the output that we get from the input of R&D budget.

Totally. It's a holy grail for that reason. We never did an episode on that. I know we had it on the long list, but we never did one, did we?

Nope, we never did it. And in fact, anyhow, do you know what McKinsey said back then? And this is a little bit of a slide, but they said, if you take this framework and holistic approach to software development productivity, You can actually reduce product introduction timeframes by 30% to 40%. So, they were focused on getting R&D teams to get new products out the door faster.

Awesome. Awesome. Okay, let's jump into these 5 steps. Step 1 seems to have been stepped on in the script. I don't see it there anymore, so I'll do it from memory. Step 1 was allocate budget top-down. And I think, look, the argument There's not a great argument for this if you're explaining it to a child. It's just the way things work. Software companies use benchmarking. They build P&Ls. They look off industry standard comparable metrics. So, you know, if the typical R&D spend in your space is 25% or 40%, your board's gonna know that. And they're gonna talk to you about your total R&D spend compared to those metrics. There are certainly exception cases, particularly in the early days of a startup where you're trying to get to a key milestone, like a minimum viable product, where literally it's just cost driven. Yeah. Percent of anything driven. It's, you know, in order to get the thing to the state where we want to sell it, we need 10 developers for 5 quarters, and that costs this much money, right? So that is kind of phase zero of a company. But as soon as you start to build a real business, you're in the $1 to $10 million range, people are going to start looking at your overall R&D spend in a top-down way. And unless you have really good arguments to the contrary, you're going to be compared to these benchmarks.

And I have nothing to add to that other than I think I need a QA organization to make sure I don't screw up your script.

Yeah, yeah, I was wondering where that piece went. I was just— I look at it, it's like, oh, that's gone. Um, okay, number 2, break R&D into granular buckets. Look, I am a huge believer in this idea because in my experience over 35 years in software, an R&D— like, I don't know, some people probably feel this way about marketing, but you can literally just keep dumping money in and they'll never say You know, you could just keep dumping money into a black hole and you don't know what you're getting. So I like to break the black hole up. You can do it by existing versus new products. You can do it by industry versions. You can do it by use cases. But I wanna know what I got. Like, if I add these 10 features, I'm now able to compete more in this use case. So I should get more business from this use case, or I can build this new product, right? So to me, R&D budgeting, measurement, management is all about splitting it. Because I think the worst thing you can do is just have kind of a black hole conversation with the head of engineering about how many people they need, to which the answer is always more. I find this somewhat frustrating because one of my kind of personal credibility tests for a VP of engineering is like over a beer, you ask them if they've read The Mythical Man-Month and do they believe that adding resources to a late project makes it later. And everyone goes, yeah, yeah, I agree with that. And then you see them in a budget meeting and it's like they completely forgot everything in that book. Thoughts on this, Ray?

Yeah, well, one of the reasons I love these granular buckets is number one, I mentioned it earlier, that when we're launching a new product, because we want to create more of a platform which creates higher retention rates, hopefully, and more expansion, right? So I can increase the NRR. I really want to know for that new product, for companies who adopt that, what was the NRR for those companies? How did my retention rates actually increase? But there's another thing going on today in PLG, product-led growth companies, being able to actually say, I'm going to invest 10% of my R&D budget to have a better activation rate, which is that point, which is the aha moment, which may get them to go from a freemium to a paid product. R&D can be held responsible for having the right product capabilities to get that aha moment and activation rates. In fact, the other thing I'm seeing, and Gainsight's doing a good job of this, they're building in-app guidance capability in their product so that when a user gets to a particular point in the software, that they know, hey, they should also be doing this because companies who do this typically have a higher retention rate, they pop that up in an in-app experience. So I think there's a lot of different things R&D can do today that directly impacts customer retention and expansion, and it should be measured.

Yeah, Ray, and you're leading directly into Battery's taxonomy. So, so while we all agree with the idea of breaking R&D into granular buckets, the question is kind of along what dimensions. And Battery is very much in the camp you were talking about, which is they suggest 4 buckets Spend to win more in your existing market, spend to expand usage and revenue in existing customers. You talked about that. Spend to expand your market. I don't think you talked about that, but it's a good one. And then spend to retain your customers, which a lot of people forget. And in a SaaS world, you know, in a GRR world, that's very important. Now, number 3, listen to product-adjacent teams that are customer-facing. To me, this is a lot of syllables to say PMs should do their job. In my mind, and I started my career in, of course, tech support, then training and consulting, but then product management. And the whole job of a PM is to be the center of a bunch of spokes, right? What do sales want? What do SEs want? What do customers want? What do new businesses want? How do we beat this competitor? What do analysts want? What does tech support want to make it more supportable, right? And that's the job of PM. And I always feel like sometimes people are trying to second-guess PM on that. And somebody has to be at the center of that wheel, and that's PM. And yes, they need to listen to a whole bunch of inputs, including, by the way, what's the company vision, right? This is what makes PM such a hard job, is you gotta look and you should know, like, you should be able to recite, what does tech support want in the next release? What does consulting want? What do sales want? What do SEO want? What do we need to do to beat competitor X, right? And they should know the answer to all those questions. And then the hard part, synthesize that into a product roadmap, that appropriately kind of moves the bar across those different fronts in a logical way. So, I'm a big believer in this concept. But to me, I think it's just about, hey, have a good PM team and let them do their job.

I'm going to just have one addition to that. One of the most enlightening things I heard was I was talking to Amit Bendov, who's the CEO at Gong. He said one of their best practices was taking their conversational intelligence tool, recording customer support and customer success calls, And with the CI tool, it could highlight things that were really kind of most important to things like retention and having the R&D leaders listen to some of those calls about what customers wanted in their products or what was frustrating. And the product managers were more effective in getting R&D to move quicker on some of those requirements.

Yeah. At some point, Gong's messaging was like the reality connection tool or something along those lines, that Gong kind of connects you to reality. And it It does in sales. It can also do it in customer support. It can do it in customer success. It could do it for R&D. There's nothing like people hearing directly from a customer's mouth what they want and why they want it. So I think that's a great idea. Number 4, be deliberate about measuring success. Define business goals that are linked to products and features outcome. For example, measure revenue from an existing product if you want to see that refactoring investments pay off. So are we getting more expansion revenue on existing product? Because gosh, we invested a bunch of money in refactoring one of its core engines? Or example, GTM metrics. Hey, we implemented a bunch of features designed to accelerate POCs. Is it actually shortening our sales cycles? And 5, Ray, I'll do 5 and let you comment on both 4 and 5 together. Hold the full team accountable for those business results. I.e., the reason you were hitting or missing them may or not be directly tied to the product. This, you know, welcome to the world of highly indirect management. I thought marketing attribution was indirect. Now meet R&D, right? And then basically to me, they don't say this, but I do limit finger-pointing. by engaging the whole team in analysis and a focus on solutions. So it's less about whose fault it is that the new product didn't hit its revenue goal. It's more about why do we think it didn't hit the revenue goal and what are we as a team going to do to hit it? Thoughts?

Yeah, well, I'm going to go to number 4, being deliberate about measuring success. One of the current trends are managing your cloud third-party costs. Because sometimes we're architecting software so quickly just to get it out there, new feature function, We're not optimizing the use of AWS or Azure. So now, I think another key measurement is if I'm investing engineering or architectural resources to re-architect, refactor that architecture, how does that reduce my third-party cloud costs as a direct expense reduction impact?

Awesome. That's a great point, Ray. So, let's wind this up now. We're hitting the time limit, basically. Look, I was hoping for a holy grail when I saw the title of this thing. I didn't find one, but I did find a good article that taught me a couple of things. One, about an emerging SaaS space for engineering management metrics that certainly companies of any kind of scale should be evaluating. Second, this is a space, by the way, where I have that angel investment in Pharos, so not my first exposure, but an exciting space. Second, we got a link to a detailed post on developer productivity metrics, which is actually a link inside the Battery post out to a LinearB post. And then finally, we found this Battery's practical framework for kind of thinking about allocating and managing R&D spend. Back to you, Ray, to wrap it up.

Yeah, 2 things that I love. That LinearB framework for establishing developer metrics, I really love that. Allowed me to really think about that beyond the McKinsey article I mentioned. And number 2, I must admit, I've been thinking about how generative AI and copilots are going to improve R&D productivity, primarily as measured by R&D percentage of revenue. And I really think that is going to take developer productivity to another level. And now we can talk about how to measure it.

Awesome, Ray. Well, thanks for doing this episode with me, and I'll see you next time.

Okay. Bye, everyone.

The Metrics Brothers AI, SaaS, and More is a production of The Metrics Brothers Growth and CAC and a member of the Benchmarkit Podcast Network. By accessing this podcast, you acknowledge that The Metrics Brothers make no warranty, guarantee, or representation as to the accuracy or sufficiency of the information provided. Or the humor content of the jokes told. Ray, information, opinions, and recommendations presented are, according to our spouses, probably wrong and provided for information purposes only. This podcast should not be considered professional, or for that matter, unprofessional advice. We disclaim any and all liability for any direct, indirect, indirect, misdirect, incidental, special, ordinary, consequential, inconsequential, or other damages arising out of any use of or help you rely upon the information presented here. Ray Grothreich is based in New York City and available on X @rayreich. Dave Kellogg is based in Silicon Valley and available on X @kelblog. Schedectady, which is French for unspellable, is not our actual production location. Thanks for listening.