The Secret Product Management Framework

One of the most challenging questions about product management has been – in my experience – “What is Product Management?”

In this post, I share a simple model or framework to answer this question. I talk about this model with lots of people, but I’ve never explicitly written it down in a post. I’ve found the model to be very powerful in my career, and I hope it’s helpful to you.

(And if you read all the way to the bottom, you’ll find a nice bonus!)

We’re called “product” managers

We’ll start with a box labeled “Product.” (It’s in our name, right?) This is the part of the job that’s most obvious. I suspect most of what you’ve learned about product management thus far has revolved around “the product.” By the end of this post you’ll have a much better context for thinking about “the product.”

“Product” involves things like:

• Requirements or user stories or features
• Design, both visual and technical
• Backlog
• Agile development methodologies
• Product manager =? Product Owner
• Releases
• And even roadmaps

And indeed, as a product manager “product” is where you spend a lot of your time, typically. But it’s not 80%. Maybe it’s 40%-50%, ideally. What do we do – or what should we do – with the rest of our time?

Our products solve problems for users

Here’s where things get interesting.

The most fundamental thing to remember is that successful products solve problems for customers.

Note: I’m using the term “problem.” Business applications and products literally solve problems. Products for consumers can solve a problem, or they can address a desire or need. A consumer product like the Swiffer solves a problem – dirty floors. A consumer product like the iPod addresses the deep human desire for music. 1,000s of different product categories have addressed this deep human desire over the millennia.

I’ll use the term “problem” in this post, but you can think “need and desire” if you’re working on a consumer product.

A big part of our job is finding these market problems, customer needs and desires.

Since what our product does is solve a problem I’m going to rename the “product” box. Let’s call it a “solution.”

Market research

There are lots of ways to find market problems or customer desires, and I have several earlier posts that cover some of these techniques. A few useful approaches are:

• Interviewing customers
• Anthropology/ aka watching what they do
• The Jobs To Be Done framework has a whole methodology for finding unmet needs of market segments

And note that this process needs to happen whether you’re talking about the product or an individual feature of a product. They all should solve problems.

Validation and feasibility

The other half of the “Problem” box is that we need to validate that the problems we found are worth solving. Will enough people pay for a solution that it’s worth our time to solve it? Indeed, can we solve it?

Finding and validating market problems is not a one-time thing. You need a continuous funnel of potential problems to solve with your product, or with a new product.

So you will constantly be out talking to “the market” to find and validate new problems. How much should you do this? Some product management experts say that product managers should talk to every one of their customers over the course of a year. And this is outside the context of a sales call!

Once you have this funnel of market problems coming in through this research, there’s a process of deciding which problems to attack. Which ones should you create solutions for. There are a lot of ways to prioritize, as I’ve described in previous posts.

The story so far

Summarizing, we find market problems that need solving, then we create solutions to the best of those problems.

But that’s not the end of it, by a long shot!

Go-to-market

There’s one other very important product management function.

• We need to find and acquire customers
• We need to get people to buy our solutions.

“Go to market” is the part of the product management process where we:

• Define who is a good prospect, so that Marketing can go out and find those people
• Make sure the sales people know what to say to those people when they find them

Go to Market Challenges

The challenges you’re addressing in the go to market phase are:

• How do our prospects find out we have a solution to their problem?
• Who are the right customer/prospects to target?
• How do we find them?
• What do we say to them when we find them?
• What’s the best way to communicate with them?
• Why should they buy our product instead of something else?

The Secret Product Management Framework

And that’s the Secret Product Manager Framework:

• We find market problems, create solutions, and get customers to buy our solutions

Why is it “secret?” I’ve never seen product management described like this, so if anyone has done it, it was secret to me. Many people do talk about these components separately, but not tied together in this way.

How to talk to your parents about what you do

One of the big strengths of this model is that you can use it to talk to non-technical people about what you do.

(Don’t say you’re the “CEO of the product” – they won’t know what you mean, and they’ll think you’re full of yourself)

Try this instead:

“I find market problems, create solutions to those problems, and take the solutions to market.”

Everyone understand problems, and solutions, and customers, whatever their background.

Three takeaways

How can you start using this information right away?

1. It should be your mantra. “I find market problems, guide the creation of solutions to those problems, and take the solutions to market.”
2. It’s a good way to describe what you do. It will differentiate you from a lot of product managers who cannot give you a concise description of what they do. And it will help your thinking and help you change your mindset.
3. Use it to help guide your activities. For example, the problem you’re solving imbues everything. Your work, at bottom, is not about the product, it’s about the customer and what the product does for them, how it solves their problem. Whether you’re talking to customers, prospects, or engineers try to put the feature or feature request in the context of a customer problem. One simple change is to say “you” instead of “we” when talking to customers about your product. I.e., “Our product has feature X” is wrong. Say “Your problem Y is addressed by our feature X.”

Bonus Video

For a longer explanation of the Secret Product Manager Framework check out the “What Is Product Management?” video, from my (still in production) Secret Product Manager Handbook series.

Keep in touch

Let me know in the comments what you think about the Secret Product Manager Framework.

And don’t forget to sign up for my email list!