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 domain of start ups has a rough framework they follow.

Why does product not have the same? Lets discuss.

A product team is typically 4-6 engineers, a product manager and a designer.

Lets say they’re all in the US 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.

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 metic measure both the user value and business value that your product creates.

If you are good at product development, you can reliably improve you north star metic.

Full Stop.

If you have a solid north star metric and its not moving, you are working on the wrong things.

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 spit all the projects that we wanted to do into three categories.

Leadership would then check:

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 typically 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, likely the more technical/design/feature debt you have to keep paying down to

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.

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 start 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:

Once you have both, you want to stack rank these projects to make sure you get the most impact for your eng investments.

Headroom is an industry term for estimating 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.

Lets 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

If I wanted to re do my homepage to increase sign ups.

the key point is that you measure the potential impact of each feature in your North Star metric.

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 them.

There are a lot of frameworks that work here.

I won't go too deep into this here. Each of them work better in different scenarios but the important thing is that you do one of them.

A few tips:

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 you’re 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.

They key points 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.

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 team, 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 over think them, just ship them. If you can measure them, great. If not, its fine.

Typically this is easiest to do at the beginning of a quarter and as a part of your annual planning process.

Good luck out there,

Dan

P.S - Interested in scaling your revenue and fixing issues like this?

Click Here to Book a Call