As tech product managers, we’re often pitching the need for larger development teams. There’s an implied revenue obligation, though, that we should understand. Here are some back-of-the-envelope numbers — in three steps — for a likely discussion with your CFO or General Manager.
[1] R&D as a Portion of Revenue (CFO View of the World)
The typical big software company spends 12%-18% on development. (See MSFT or SAP.) Said another way, five out of every six revenue dollars goes toward something other than product engineering: $2 on Sales & Marketing, $1 on administration, $1 for profits to shareholders, etc.
So when a big software company is going to spend an incremental dollar on development and not dilute earnings, it somehow needs to deliver six in incremental revenue. (Say this out loud: “Eventually, my big company will expect $6 in revenue for every $1 I spend building my product.”)
Of course, different companies have different goals and situations.
Pre-revenue startups don’t (by definition) have any revenue. They urgently need to build products that they can sell, so form development teams now and push-push-push to get products launched. Ratios are for later.
- Early-to-market companies invest heavily to scale up. Development spending often exceeds total revenue, and marketing/sales spending is usually exceeds development. But they hoping some day to get big, and the scale-up of software companies is all about selling the same software bits thousands of times. The marginal cost of adding licenses or users or transactions should be close to zero.
- Later-stage private companies will eventually want to go public, and stock markets like 6:1 revenue-to-development ratios. Or they hope to be acquired by a big public company, which prefers not to dilute its earnings. So tech companies at 2:1 or 3:1 or 4:1 ratios like to move toward what the financial markets want.
- Internal IT teams are generally scored on how much they save their parent corporation, rather than how much revenue they produce. And Corporate Finance will often demand a 3:1 or 4:1 payback on software investments. Why spend time and money and development risk for a 2:1 payback when there are so many deserving 4:1 projects in the backlog?
In any case, choose your situation and your ratio. The exact math is less important than the concept. We’ll stick with 6:1.
[2] Development Teams Cost Money (Engineering Budget View of the World)
Once we’re lucky enough to hire the developers and test automation engineers and UX/UI designers and dev ops wizards (and product managers), we typically have to pay them. Salary + benefits + taxes + office space + adjustable standing desk for a US-based tech hire costs about $160k/year. (Chosen for easy computing, not fussy accuracy.)
Again, your local talent pool and costs will vary. But it’s a mistake to fall into a Moneyball argument: the hope that talented-but-underpaid developers are just waiting for you to discover them. (“Couldn’t we hire folks on the cheap, or start a developer internship program, or identify great technical talent at the competition who are secretly yearning to come work for us?”) Unless you’re Google and have a mountain of time/money/resources to grow a pipeline of developers, you’re better served hiring an experienced development team and getting urgent technical work done now.
(Say this out loud: “When I demand an incremental person for my development team, s/he will cost us roughly $160k/year.”)
[3] Multiply
So if your company expects a 6:1 revenue return on development spending, and your next hire costs $160k/year, you should expect each new technical person to generate $1M/year in additional revenue. Eventually. Somehow. If not recouped in the first year, imagine an accumulating “revenue debt” to be paid off alongside technical debt. (Again, my math is simplified to be memorable, not accurate. Feel free to substitute your own numbers.)
You might claim that your product is “strategic.” In financial terms, that means someone else’s product has to earn more than it’s 6:1 ratio to cover what you’re spending. If too many of the company’s products are “strategic”, the Board fires your CEO. Before that happens, expect executives to start canceling “strategic” products like yours.
Say this out loud: “When I demand an extra head for my development team, someone should ask how this will drive an additional $1M/year of revenue.” Perhaps no one at your company knows to ask that question, but you should have an answer ready.
And if you’re pitching the need for an incremental scrum team of 6-9 people, then you should have a $6M-$9M revenue explanation handy. You’re a brilliantly anticipatory product manager, so probably negotiated with your VP Sales for some support. (“Absolutely! If we had that NetSuite-to-Meerkat ETL connector today, we’d have closed another $15M this quarter!”) Or Director of Field Operations. (“A prediction engine for field replacement parts would cut our repair costs by $2M-$4M a month. We should fund that work out of the Field Ops budget.”) Or VP Online Marketing. (“Adding a mid-priced athletic tracker fills a $20M hole between our entry-level wristband and gold-plated IoT earrings.”)
The startup version of this? “It may be years before we hit scale, but this should eventually be a $20M+ opportunity or it’s hard to justify a 20-person development team. Have we done a good job of sizing the market?”
Bottom line: when you ask for incremental development resources, you’re making a future revenue commitment. It’s worth understanding what that commitment is, and not spending precious development resources frivolously. Make sure that you’ve not only validated customer interest, but also penciled out financials that support your team.
Sound Byte
Product managers should understand how our product-level spending aligns with company revenue goals. Eventually, our products need to pay their own way.