What is Product Management

Hervé, Sun Jul 25 2021 • product management opinions

There can't be a blog from a Product Manager without its own definition of Product Management.

So here I'll give my own version, influenced by tons of stellar folks from the industry (M. Cagan, J. Patton, D. Reinertsen among others):

Product Management is about optimizing Return On Investment of your Product.

I like this definition as it is super short, and gives three clear parts to unpack:

Return
Investment
Optimization

Let's go unpack these!

1- Return

Return should generally be related to value.
Value for users of your product, translating into value for you as a business.

Return can sometimes be understood as realized revenue, made regardless of whether users and customers or your product got anything out of it.
I take for granted that people have come around to realize that revenue comes from creating enough value to your audience so that they'll happily pay a fair price for acquiring it.

So let's talk about value.

Value

Understanding what creates value is at the core of the Product Manager role. I find it easier to consider value as a prism with multiple facets, each facet being more or less relevant to a given product, in a given context.

In my view, value can be realized by...

...making someone successful.
...reducing the time taken by fulfilling a task.
...making something more enjoyable to do than the standard way to do it.
...making something less costly.
...extending the lifetime of something.
...generating more revenue.

To better define value, you needs to understand the context of your product, or the product you're imagining building. This context is basically made of:

users of the product (or audience),
problems or situations in which your product is meant to be used and deliver its value,
market of possible alternatives (including nothing at all).

Let's see how the context definition is crucial to understanding the value of a Product.

The importance of context

As in many other things in life, it's all about context. We do different things depending on the context we're in at a given point in time. If I'm in a hurry, under pressure, tired, I'll approach things differently than if I'm rested, calm, and with time in front of me.
Context goes far beyond the individual, and considers surroundings, dynamics that affect decisions and actions of individuals.

It's interesting to write down value proposition statements for a product in a given context, to picture what makes it special. You can then make some variations for different contexts to understand other aspects of your value proposition.

Let's take a made-up example:

Google search enables anyone with Internet access to find information about something in record time.

The statement above anchors value in the time taken to find information, inferring that alternatives to Google search aren't as fast. Using that, you could elaborate on how Google search indeed compares to alternatives in terms of speed, to position it against alternatives, etc. But it also describes users as "anyone with Internet access", which is arguably unspecific. This description will lead different people to imagine a different picture based on their own experience.
By using a more specific context, we can expose another facet of the value provided by a product.

Let's tweak our example:

Google search enables students commuting to university and trying to catch up with a lesson, to access to detailed and accurate academical information on the topic of their class.

Narrowing down the audience points to a different value proposition. In this new context, speed matters less than accuracy, commuting means that mobile usage will be key, so topics like resilience of the service will take more importance, etc.

Detailing the contexts in which your product needs to be relevant can greatly help understanding your Product value. This is why research is such an important part of the Product Management job, as this is how you will build up increasingly accurate information about these contexts and your value proposition.

Now that I've rambled enough about value, we need to unpack the "investment" part.

2- Investment

The second aspect to understand and estimate is the investment required to create or evolve the product so that it generates value.

For a given initiative (a feature, a product), this requires to grow a deep understanding of...

...the complexity involved in imagining and building the feature.
...the cost of operating and maintaining it in production.
...how to mitigate risks of breaching laws or creating liabilities.

Depending on your industry, growing this understanding will be done quite differently. To avoid being widely inaccurate, I'll talk about the industry I know best: Software Development.

In Software, estimating the investment is done by closely collaborating with...

...Product Designers to understand the realm of possible solutions that people will be able to use,
...the Engineering organization to get a sense of how complex building a given solution would be, getting a rough sense of time to build it, and the cost of operating it (server capacity, people on call, ...)
...the Sales organization to understand demand, pricing sensitivity
...the Marketing organization to understand how we could position, go to market with a feature, price it¹
...Legal counselers to ensure what we're planning to do won't break any law

¹ Pricing is a topic on its own and doesn't strictly belong to a single entity though.

These aren't exhaustive nor systematically necessary depending on the topic at hand. Some responsibilities may also be shared across departments, but that is roughly how I've seen the split over the course of my time as a PM or Product Leader.

Comparing investment across initiatives

Representing the investment with a number is tempting (hours, days, money...) yet can get very tricky or time-consuming to achieve while not always guaranteeing accuracy.
What you can do instead is defining good-enough proxies (e.g. T-Shirt sizes, Fibonacci serie...) conflating all aspects of what constitutes an investment (effort, operational cost, error margin or confidence level, ...). This defines a scale used to compare each initiative against one another. The trick though is to ensure your scale is well understood to put initiatives on comparable grounds.

This is not as straightforward as it seems at first, and is another reason why Product Managers need quite a range of skills: analytical ones, but also the ability to communicate effectively with very different kinds of stakeholders in order to build a good mental model.

Once value and investment are well-understood, comes the time to optimize.

3- Optimization

Optimization is about figuring out a sequence of execution for your portfolio of initiatives, so that you can deliver the most value with a given investment.

It requires focusing on two main areas:

The Product coherence and storytelling
The cost of delay profile

Product coherence and storytelling

Imagine a product that provides you with a stellar and promising onboarding experience, but lands you on an empty dashboard, with a big "Work In Progress" sign. Not too appealing right?

No matter how good your Product is, if no one notices, especially amongst people who would benefit from it the most, that won't cut it. At all.
For people to notice, techniques to trick people into your Product won't go a long way. Instead, you need to articulate a clear and compelling message centered around the Product value, so that people can recognize if it is worth their time and/or money.

People do like stories, especially ones they can relate to. Being clear on how your Product solves a particular problem can set it apart from its competition, and will increase your chances to see the right audience show up at your Product's front door.
It doesn't mean to make something up: people are good at calling out bullshit when they see it. It is about being authentic, to the point, and articulate about your value proposition and present on what truly makes sense for your Product to be.

While this falls mostly into the Product Marketing discipline, I believe it to be essential to what Product Managers should understand and think about. You can't optimize ROI without ensuring that the Product will maximize its chances of success by meaningfully reaching its audience.

This has practical implications for Product Managers who need to mix this ingredient in when assessing their portfolio of initiatives: they need to have a satisfying answer to the quesion "What's the story like?".

We say that prioritization is both art and science in Product Management: storytelling is certainly falling on the "art" side of it.

Let's have a look at the science-oriented component now.

Cost of delay profile

In Software Development, investment largely comes down to the cost of people involved in defining, building and going to market with a feature. This means that using the number of people involved over a given period of time can be a good-enough proxy to understand the required investment, along with infrastructure spend.

I had the chance to learn about this concept during a training with Don Reinertsen, based on his book "The principles of Product Development FLOW".
Optimization is about organizing the execution flow to maximize value delivery over time. This requires understanding the profile of your initiatives and ensuring that you tackle early the ones with the highest cost of delay. This means to prioritize initiatives that, if they get delayed, lead to a larger amount of undelivered value over time.

I'd strongly advise a read to this book as it is quite enlightening, and much better explained. My point here is to recall how essential timing is – not just time! – in optimizing your execution flow.

I expand on this topic in a separate post if you want to dive deeper into it.

Our understanding evolves

Another crucial point to keep in mind is that estimating value and investment isn't a one-time thing. This is done progressively as your team uncovers new information, which refines the general understanding of the context, the problem, hence the overall estimated ROI of a feature. Said differently, our estimate of the ROI of a given initiative evolves along with the time spent working on it.

You probably heard about Product Discovery, which represent activities that a team performs to unveil this kind of information and refine their understanding of an initiative.
Discovery goes until there's enough proof and certainty that the initiative is worth pursuing, or abandoning.

One of the best resources talking about Product Discovery is the book called "Inspired" by Marty Cagan. I wholeheartedly recommend a read too.

Balancing

By having an estimate of value and investment in mind for your portfolio of intiatives, you have enough information to make smarter prioritization decision, increasing the certainty of delivering something of value to your audience on a regular basis. Hopefully enough for them to stay engaged and happy.

An important note: since your understanding as a team evolves over time, the point is NOT to plan out a year ahead, but to balance the various kinds of activities performed as a team (Discovery, Delivery) to reach this sweet spot, and update that as new learnings are made.
A great resource on the topic is what Jeff Patton talks about in this still very relevant article called "Dual Track Development is not Duel Track".
Jeff also gives great workshops if you want to learn more.

Conclusion

As a Product Manager, your role is to grow a deep understanding of the context that your product is targeting. By collaborating with most of the other functions of your company, you'll have to come up with a plan of what your team will bring to market that will maximze ROI, while keeping a coherent and compelling story to tell to your audience.

This is no simple task, but such an interesting one!

As a recap, feel free to check out resources that I referred to throughout this post:

"Inspired" by Marty Cagan.
"The principles of Product Development FLOW" by Donald G. Reinertsen.
"Dual Track Development is not Duel Track" by Jeff Patton.