The Science of Product Management

The process is a means to an end, not the end itself.

Over the past five years, I’ve trained over 5000 Product Managers who were new to the field. These have been at large companies, small companies, online, in person. The works.

While the work has been incredibly rewarding, it’s also left me conflicted.

Why?

Because year after year I get the same questions.

“How do I put this into JIRA?”

“What is a user story vs a task.”

“Why would I care about my user’s happiness when I’m building a product they have to use?”

A great Product Manager I trained at one of my clients the other day told me:

“My peers are using your training as a weapon against me. Everytime I try to move us forward they come back and condescendingly say, Well, have you actually written that in proper Jobs to Be Done format? I know what the problem is. We’ve researched it. I experimented. I have data. I validated it. Who fucking cares if I write this in proper Jobs to Be Done format?”

I assured her, I do not care. And they shouldn’t care. These motions, these frameworks, they were made to teach you to think. They were a means to an end, not the end goal itself. They are training wheels. How can they help you understand your work better, so you can DO your work better?

The point of Product Management is not to put things in JIRA in a specific format, use a specific framework for writing out goals, or make sure your developers have full backlogs. The point of Product Management is to create valuable products that customers love.

That’s where the real science of Product Management comes in.

The science is about understanding the patterns to building products that people love from a strategy perspective. These are things my team and I have been exploring as we work with growth stage companies. Some of the questions we ask ourselves on a daily basis are:

How do we price and package our product so customers will buy more, and we can increase our revenue?
How do we integrate a company we just acquired to multiply our value to customers?
What do we need to change about our products to expand geographically into another area?
How do I design these workflows and harness the analytics to make our customers’ lives easier?
How do we tailor our products to enter the enterprise market when we’ve been in SMB?
How do we retain users better?
How do we look at costs and revenue, align it back to our products, to determine what our Strategic Intents are and how we should do capacity planning?

These are the questions we need to be asking ourselves as Product Managers… every single day.

Of course, we can’t do that if we don’t have a semblance of a product organization set up so we can ask those questions. This is why I wrote Escaping the Build Trap, to help you understand what you need to do to block and tackle your product organization to make it well run. It’s the operational manual to Product Management and Product Organizations.

Once you get that down, you need to move on to solving the harder problems — how do we win? How do we grow? How do we delight users? Our operations should be so smooth, so solid, they fade into the background so we can concentrate on the science.

So, if you are scaling a product organization or transforming one, make sure your outcomes and success metrics for that work aligns to being able to do the meaningful part of Product Management: building valuable products people love.

You’ll know you are there when you can shift your time from talking about how we do things, to why we’re doing things.

If you’ve read Escaping the Build Trap, be on the lookout for more posts on how to do the things we talk about in the book, including building a great strategy and the sciencey bits of Product Management.

Also, please leave me a review on Amazon!