A typical product team in the US costs $900k–$1.2M per year. Most companies have no idea if that investment is paying off.
Marketing gets measured. Sales gets measured. Product gets vibes. That’s a problem.
Every other startup domain has a rough framework they follow.
- Marketing is held to a CAC to LTV ratio. 3:1 is the often quoted target.
- Sales teams are expected to produce 4x to 6x their salaries in new deals.
Why does product not have the same? Let’s discuss.
You’re Burning More Money Than You Realize
A product team is typically 4-6 engineers, a product manager, and a designer.
Let’s say they’re all in the US, and all making $150k per year. So that’s $900k to $1.2M per year to run the team.
You have 52 weeks in a year, so that’s 26 sprints. Assume you’re losing 2 of those to holidays and time off.
Remove 2 sprints for holidays, have 24 sprints in a year, so that $37.5k to $50k every two weeks.
If you aren’t building things that make you more than $50k, then you’re going to go out of business.
Do Your Features Actually Do Anything?
As we talked about last week, the best way of measuring the health of your product is thoughtfully setting a north star metric.
A well-defined north star metric measures both the user value and business value that your product creates.
If you are good at product development, you can reliably improve your north star metric.
Full Stop.
If you have a solid north star metric and it’s not moving, you are working on the wrong things.
The Portfolio Approach
This is probably not the right balance
At Uber, I was able to see product management happen at a huge scale. Dozens of teams with hundreds of engineers.
At the beginning of each quarter, we split all the projects that we wanted to do into three categories.
- Big bets
- Tech Debt
- Run the Business
Leadership would then check:
- Are we “spending” the right % of our resources on each area?
- Within each area, are we working on the right things?
- Have we balanced the right way across the teams to hit our goals?
Think of your engineering hours per quarter as dollars (because they are) and your projects as investments.
You want the highest risk-adjusted ROI for your spend.
A typical quarter for us with Uber Eats would probably be 40% big bets, 30% tech debt, 30% run the business items. But this depends on the team and the maturity of your area.
The more mature your product, the more technical/design/feature debt you have to keep paying down. If you are an early-stage product, you might be 70% big bets, 10% tech debt, 20% run the business.
The exact ratio can change depending on your product and what you want to do each quarter, but you should measure this each time.
Big Bets
To grow, you need to make enough big bets and control the risk.
These are the most exciting projects, but also the riskiest. New features, new platforms, etc.
These projects are where you create impact on your north star metric.
You only get a few of these per quarter; if you miss, it really hurts.
If enough of these projects don’t produce results, that’s how PMs get fired, and companies go out of business.
You should do your homework ahead of time during planning:
- Potential Headroom
- Cost Estimates
Once you have both, you want to stack rank these projects to make sure you get the most impact for your eng investments.
Headroom Analysis - If you ship this, can it actually work?
Headroom is an industry term for estimating the potential impact of a project on your north star metric.
What you don’t want is to spend 3 months making a 50% improvement to something that only 3% of your users see.
When it matters, do the math.
Said another way, you should be estimating the impact that each idea for a big feature can have on your north star metric.
Let’s say that I was running a team and the north star metric was “activation”.
If I wanted to rebuild my lifecycle email campaign, that could be estimated as
- Emails sent per month x open rate x the CTR x the potential % of people activate back on the product
If I wanted to redo my homepage to increase sign-ups.
- Traffic x potential lift in conversion rate x activation rate of current signups
The key point is that you measure the potential impact of each feature in your North Star metric.
Cost: Keep the Timeline Under Control
Equally important to the impact is how much each project is going to cost, typically measured in weeks. Even more typically, engineering weeks.
To do this, you need to be able to describe to the engineers roughly what you want and to have them estimate it.
There are a lot of frameworks that work here.
- T-shirt sizes (S, M, L, XL)
- Weeks
- Stack rank in relative cost.
I won't go too deep into this here. Each of them works better in different scenarios, but the important thing is that you do one of them.
A few tips:
- You want to do the estimation relatively quickly, take 1-2 days, not weeks.
- Get your most senior engineers involved.
- This isn't the time to discuss a detailed scope. If there are a few ways something can be implemented, pick the average cost.
Technical Debt
The bigger a codebase, the more things the engineers could, in theory, do to improve it.
If you don’t routinely pay down this debt, the codebase becomes too hard to work on, and your velocity slows to a crawl over time.
If you can’t ship quickly, you can’t innovate as the market changes, and you slowly lose PMF.
The key point is to work on things that will increase the velocity of the other work that you’re going to do.
Think about this as “clearing the path”.
The clearer you can describe where you want to go, the better your engineers will be able to help you here.
Typically, choosing these investments should be up to your engineering team. However, you need them to articulate the impact. Don’t let this be a black hole.
Still follow all of the project management best practices. Set milestones, clear scope, metrics if possible, etc.
Run the Business
This bucket is for things that just have to happen, and typically quickly.
Sometimes you know them ahead of time; if so, put them in your roadmap. Other times, you just leave capacity for them when they come up.
These can be bugs in key areas, small UX optimizations, helping out other teams, installing new tools, etc.
If you make it too hard to get the simple things done, especially across teams, it kills collaboration, which kills innovation, which eventually kills growth.
Don’t overthink them, just ship them. If you can measure them, great. If not, it’s fine.
So What Do You Do With This Information?
Typically, this is easiest to do at the beginning of a quarter and as a part of your annual planning process.
- Make sure you have a north star metric.
- Start with your big bet projects. List all of your ideas. Estimate cost and impact.
- Work with engineering to geta technical debt idea
- Add any known run the business ideas
- Calculate how much engineering capacity you have using whatever framework you want
- Build your roadmap in the highest ROI configuration that you can.
Good luck out there,
Dan
P.S - Interested in scaling your revenue and fixing issues like this?