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: