Note: Paid subscribers can listen to this as a podcast or watch the video explainer. See below.

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, “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. He didn’t have a product management problem.

He didn’t like my answer. I’ve never heard from him again.

But that’s ok. Because had I accepted the job, I would have been in for a world of hurt.

(I’ve since learned he’s churned through multiple product executives.)

He thought PM’s job is to make Engineering go faster.

It’s not. And it can’t.

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 Product Management can do is:

Some businesses are doing just fine on these. Super. Godspeed!

But if not, that’s when formal Product Management is needed.

Unfortunately, many PMs and product leaders are under the delusion that they can make engineering go faster. And, thanks to Agile, they obsess over sprint velocity.

The VP of Engineering is focused on sprint velocity. The theory is that the greater the velocity of delivery, the greater the productivity of the team, the more bang for the buck from the same set of human resources.

Increasing sprint velocity from 6 backlog items to 7 has a 17% increase in team productivity. In other words, we've improved the team's ability to generate more value with 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!”

Many PMs and product leaders blindly adopt this engineering metric as a Product Management one. And leave it at that.

Then they hear from the execs: “We’re not hitting our revenue targets. We’re not retaining customers.”

And, so while Engineering gets a nice pat on the back, PM gets pressured to push out more features.

The result is PMs finding themselves running on a hamster wheel trying desperately to get the machine to move as fast as possible.

Soon they find they haven't gotten anywhere and are exhausted.

The reason is there are two problems with an exclusive focus on sprint velocity:

Optimizing dev process for efficiency is a useful endeavor. That’s not where PM creates value. PM creates value in business trade-off decisions.

It starts by understanding our product development costs and then comparing ROI across opportunities.

Here’s a primer on how:

If we have a team of 1 PM, 4 engineers, and 1 designer, that's a $1 million annual team, fully loaded. Running 2-week sprints costs $42,000 in human capital per sprint.

So, if a thing takes 4 weeks to code, test, and release, that's an $84k investment. But if it takes 4 months, that's a $365k investment.¹

Feature A has an economic value of $550K and takes 5 sprints to deliver. So, 10 weeks at a cost of $210K.

Feature B is worth $250K and takes 3 sprints to deliver. So, 6 weeks at a cost of $126K.

Which should we prioritize?

THIS is the question Product Management needs to answer.

A purely cost-based and time-to-market approach could lead us to say Feature B. That may make sense if the strategy is “revenue now” or “save money.”

A purely revenue-based perspective could lead us to prioritize the Feature A. That may make sense if the strategy is maximizing short-term revenue even at higher cost.

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 prioritize Feature A?

Let's make this even more interesting…

After speaking with Engineering, turns out Feature B can be completed in 2 sprints instead of 3. Now, the ROI looks like this:

Feature A: more time, more cost, more revenue.

Feature B: less time, less revenue, but higher return sooner.

In this case, the Product Manager could make a legitimate argument to prioritize Feature B. It gives us the best return in the soonest possible time on the use of our existing resources.

My point here is that this is the unique perspective Product Management can and should bring for ROI maximization. One that balances revenue maximization and margin velocity.

NOT sprint velocity.

Remember:

Sprint velocity is a productivity metric.

It’s not an impact metric.

Sprint velocity is a measure of operational optimization.

Not of return maximization.

Which is what Product Management needs to be focused on.

In an earlier issue, I talked about our #1 KPI in product management: ROI. That is, how quickly can we make a return on the money invested in developing and delivering our product.

ROI is made up of two parts: (1) Net Revenue Growth, and (2) Margin Velocity. In that essay, I dived into the revenue side. Today, I'll discuss Margin Velocity.

Margin velocity is the reason why you’re always getting pushed to get 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.

There are two aspects to Margin Velocity:

Today, I’ll focus on the product development side. I’ll discuss the product delivery side in a future essay.

On the product development side, we're concerned about:

Tools like Jira aren’t usually included here, because they’re typically not 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.

For a hardware / physical product, there may be costs related to materials, supplies, and testing.

Let’s go back to our $1M sprint team. If a thing takes 4 weeks to code, test, and release, that's an $84k investment. But if it takes 4 months, that's a $365K investment. (After requirements.)

Once we understand this, it instantly illuminates three critical questions:

THESE are important strategic questions that Product Management should be asking.

Understanding product development time and costs materially influence:

Now you can see why executives are always pushing to get things out faster and can often question adding more resources!

This gives us a number of strategic product planning levers:

Let’s go through a couple of examples.

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?

Engineering says it will take 7 months to all of it. Using the sprint team numbers from above, that’s $632K. A considerable expense and a long time to wait.

This is where as a Product Manager you need to ask questions like:

Why would we even engage in this type of thinking?

Now, maybe this isn’t possible. Maybe we do have to build all 20 features, else no one will buy the product. If so, that's fine.

But we need to ask these questions.

Because, believe me, your execs will definitely be asking it.

Let’s say we need to improve the login feature:

That’s 8 enhancements. Engineering says doing all of this will take 6 weeks.

So, we need to ask: Do we need to do all of them on one go?

Should we do the first 4 and then add the others incrementally?

Do we do SSO first, because it will help keep a major customer happy, and then deploy it to other customers?

Again, THIS is the kind of strategic business thinking you need to apply to your products.

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

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

Exciting:

“When I joined WonderTech, I found that while our sprint velocity was good, we were only getting a 53% economic return from each of our sprints. I did A, B, and C, and by year’s end, we were generating a 76% economic return from the same velocity."

Which Product Manager do you think gets hired?

That’s all for this week.

Have a joyful week, and, if you can, make it joyful for someone else too.

cheers,
shardul

Shardul Mehta
I ❤️ product managers.

​Follow me on LinkedIn
​​Book a Free 1:1 Call With Me