Product Management Can't Make Engineering Go Faster
Read on my website / Read time: 9 minutes
β
Thank you to our sponsors who keep this newsletter free for the reader:
Track the Latest in AI and How it Impacts You
Relevant. Interesting. Viral. Join 450K+ professionals from Google, EA, PWC, and more staying ahead of the curve with The Neuron.
|
Get Inside the Mind of Your Founder
Learn about founder psychology and how they think about strategy, product, and decision-making from Jason Cohen, 4x entrepreneur with 2 unicorns, and WP Engine's founder & Chief Innovation Officer.
|
β
I once turned down a $500k Chief Product Officer job opportunity.
"What's your biggest challenge?" I asked the CEO & Founder.
"We need to go faster," was his response. "We're just not getting as much engineering velocity as we should."
I knew immediately this was a bad job.
I probed the CEO/founder on how his business was doing on delivering customer value and its product economics.
His response was, "Well, we're very responsive to our customers, they love our product and our features, so we're definitely delivering value. And our financials are strong."
"What we need," he continued, "is to just get those features to our customers faster, so I can recognize the revenue quicker."
I agreed that this was a legit goal.
And politely told him that he wasn't looking for a product leader and didn't have a product management problem.
He didn't like my answer. I'll probably never hear from him again! π
But that's ok. Because had I accepted the job, I would have been in for a world of hurt.
Product Management can't make engineering go faster. That's the responsibility of the CTO or VP of Engineering.
And even then, there's a ceiling to how much faster code can be written and tested before quality suffers.
What we, in product management, can do is:
- Help maximize the customer and business value being delivered from existing R&D resources.
- Help deliver healthy economics for the product.
Some businesses are doing just fine on these. That's super great. Godspeed!
But if not, that's when product management is needed.
Unfortunately, many product managers (and product leaders) are stuck in a cycle of pursuing velocity.
Margin Velocity, not sprint velocity, is our product management focus.
βLast week, I talked about our #1 KPI in product management:
Our #1 KPI in product management is
Return on Invested Capital (ROI).
ROI in terms of product is about figuring out how quickly can we make a return on the money invested in developing and delivering our product.
ROI is made up of two parts:
- Net Revenue Growth - a measure of how fast revenue is growing
- Margin Velocity - aa measure of how quickly we can earn a profit from the money we've invested in the product.
Recall, these are aligned with what is top of mind for our CEO too.
Last week, I dived into the revenue side. Today, I'll discuss the margin side and how we as product managers have a material ability and responsibility to influence this important result.
Margin Velocity
Velocity here means the speed at which that revenue and margin can be realized.
Margin is an indicator of the gross profit a product will make after producing and delivering the product to the customer, not including sales, general operating expenses, interest, and taxes.
It's basically revenue minus the cost of goods sold or the cost of providing the service.
Velocity here means the speed at which that margin can be realized by the business.
This is a key driver behind wanting to get product features out the door fast.
The faster and cheaper we can develop them and get them into customers' hands, without sacrificing quality, the more profitable the product.
Now, if your organization runs agile development, you may be thinking about sprint velocity here.
Hold on to that. I'll address it in a moment.
From a product management perspective, there are two aspects to margin velocity:
- Product Development - the investment ($$s) needed to build the product.
- Product Delivery - the investment ($$s) needed to deliver the product to the customer.
In this issue, I want to focus on the product development side. I'll talk about the product delivery side next week.
On the product development side, we're concerned about:
- The cost of the human resources needed to develop the product.
- The time needed to develop the product and get it released.
- Fees paid to any 3rd parties to support the product development.
Note that for a hardware / physical product, there may be costs related to materials, supplies, and testing.
Note: Tools, like Jira, aren't usually included here, because they typically aren't an opportunity cost - they're an operational expense spread across all teams and features. The exception would be if a tool was used exclusively to develop and support a specific feature.
Let's say we have a team of 1 product manager, 4 engineers and 1 designer. Using just average salaries from ZipRecruiter, that's a $1 million team, fully loaded (annual). That's an expensive team. If you're running 2-week sprints, each sprint costs $42,000 in human capital.
So, if a thing takes 4 weeks to code, test, and release, that's a $42k investment. But if it takes 4 months, that's a $362.5k investment. And these are just the costs incurred after the requirements are written!
Once we understand this, it instantly illuminates three critical questions:
- Given the same cost, what should this team work on that gives us the biggest return?
- Is there a way to accelerate getting a thing available to the market? Can we delay certain functionality (i.e., cut scope) or add resources to get it out faster?
- Can we get the same return with fewer resources without sacrificing quality?
These are important strategic questions that product management should be asking.
Understanding product development time and costs materially influences:
- Product pricing.
- Calculating the NPV (net present value) of a product investment.
- How quickly we can start earning revenue from the product.
- How quickly we can get to profitability.
- Resource allocation.
- Even funding.
We can see now why CXOs and product executives are always pushing to get things out faster and can often question adding more resources!
This gives us several strategic product planning levers.
Assuming no compromises on quality, the levers we have are:
- Scope.
- Timing.
- Human resources.
- Target customers.
Let's go through a couple of examples.
β
New Product.
Say we're developing a new product to take to market. To be fully competitive, we've identified 20 features the product must have.
Do we build all 20 into our first release?
Working with Engineering (and using the sprint team numbers from above), we find it will take 7 months = $632k to do all that.
That's a considerable expense and a long time to wait.
So, it's worth asking:
- What is doable in 3 months?
- Is there a customer or set of customers - early adopters, if you will - who would be willing to use an early version that's missing certain features?
- Could we incentivize them to do so?
- If so, what would be the most critical set of features to prioritize to satisfy this?
Why would this be worth doing?
Delivering something in 3 months would cost 2.3 times less, get our product into customer's hands, even if on a limited basis, and allow us to get invaluable customer feedback that we can use to improve our product.
If things go well, each subsequent iteration of the product could have higher economic value as we parlay feedback from the previous iteration into the next one.
Now, maybe this isn't possible. Maybe we have to build all 20 features, else no customer will buy the product. If so, that's fine.
But it's worth asking the question.
The execs will definitely be asking it.
β
New or Upgraded Feature.
Similar exercise.
Let's say we need to improve the login feature:
- Cleaner UI.
- More user-friendly error messaging.
- Improved Forgot Password flow.
- Add missing Remember Me function.
- Add two-factor authentication.
- Add security image.
- Support for single-sign on (SSO).
- Direct linking to the relevant page post-login from an email notification.
Doing all of this will take 6 weeks.
Do we need to do all of them on one go?
Maybe we do the first 4 and then add the others incrementally.
Maybe we do SSO first, because it will help keep a major customer happy. Then deploy it to other customers.
β
Ok, I promised to talk about sprint velocity. So let's do that now.
Sprint velocity is an engineering metric.
Our VP of Engineering is understandably focused on sprint velocity. The theory is that the greater the velocity, the greater the productivity of the team, which means we should be getting more bang for the buck from the same set of human resources.
Consider our product backlog. For simplicity, let's say the average economic value of each incremental backlog item is $5,000.
Increasing sprint velocity from 6 backlog items to 7 has a 17% increase in the productivity of the team.
In other words, we've improved the team's ability to generate more economic value within the same capacity by 17%. Nice!
Engineering leadership loves this because it demonstrates how productive it is - See? We're getting more done with the same set of resources! Yay!
Here's the rub.
Many product managers - and, sadly, product leaders - blindly adopt this engineering metric as a product management one.
And then leave it at that.
And so, as product managers, we find we're running on a hamster wheel trying desperately to get the machine to move as fast as possible.
And soon we find we haven't gotten anywhere and are exhausted.
The reason is simple. There's something pretty fundamental being missed.
There are two problems with an exclusive focus on sprint velocity:
- It assumes all features are created equal.
- Sprint velocity will ultimately max out for every development team unless more people are added. And even that has a diminishing returns cap.
Product Management looks beyond sprint velocity.
Let's say two features can be completed within a sprint. Using our sprint cost from above, it means both features cost $42k.
Let's say Feature A has an economic value of $550k and Feature B has an economic value of $250k.
Same development effort and cost. Different ROI. Which should we prioritize?
That's what product management needs to focus on.
In this example, at first glance, it seems obvious: Feature A. But let's make this a bit more complicated.
Let's say the $550k feature takes 5 sprints to deliver. That's a cost of $210k and 10 weeks before we get a return.
Let's say the $250k feature takes 3 sprints to complete. That's a $126k cost and 6 weeks to get a return.
Which should we prioritize?
A purely cost-based and time-to-market perspective could lead us to say the $250k feature. Some companies with a "revenue now" focus may make that decision.
A purely revenue based perspective could lead us to prioritize the $550k feature. A fair decision in a company primarily focused on maximizing revenue growth.
However, let's look at it from an economic return perspective:
Feature A costs more and takes longer, but provides a higher economic return!
So maybe we should consider prioritizing feature A?
Let's make this even more interesting!
Let's say Feature B can be completed in two sprints instead of three. Here's the ROI:
Hmm! Well, well, well...
Feature A - more time, more cost, more revenue.
Feature B - less revenue, but better return sooner.
We could make a legit argument to prioritize Feature B!
To be clear, I'm not saying this is the only way to prioritize. There are often other factors too, such as alignment with strategic goals, competitive factors, a loud customer, or others.
The point is, as product management, this is the unique perspective we can bring that balances both revenue maximization and margin velocity!
So, remember:
Sprint velocity is a fine productivity metric...
But it's not an impact metric.
Sprint velocity is a measure of operational optimization...
Not of return maximization.
How we can talk about this in performance reviews and job interviews:
Old way #1 (boring):
"My job at WonderTech was to manage the backlog and prioritize what we worked on in each sprint. I spent time understanding our users' needs, and then used the Cool Prioritization Method to prioritize our backlog items for each sprint. So, I made sure that in every sprint we were always working on the most important items for our users."
Old way #2 (also boring):
"When I joined WonderTech, the team had a backlog of 94 items on average and a velocity of 4 items per sprint. I worked with the engineering team and was able to bring the backlog down to less than 50 items and increase sprint velocity to 7 items per sprint."
New way (wow!):
"When I joined WonderTech, I wanted to understand the return we were getting from our dev efforts. I found that while sprint velocity was fairly good, our economic output from those efforts could be better. We were getting about a $53% economic return from each of our sprints. I did A, B, and C, and by year's end, we were generating a 66% economic return from the same velocity."
I don't know about you, but I'm hiring the third product manager!
Takeaways
- Product Management can't make Engineering go faster.
- Product Management can work on maximizing the potential return from product development efforts.
- Sprint velocity is an engineering metric focused on optimizing productivity. Product Management can support it, but needs to look beyond it to maximizing net revenue growth and margin velocity.
- Use this to talk about your own impact in economic terms, not operational, procedural, or technical terms.
That's all for today. Next week, I'll talk about product delivery.
β