Defining Product Management
I think of Product Management and Product Marketing as two sides of a coin. They are not the same, by any means, but both are customer- and market-centric roles that must really be rooted in a very strong understanding of the critical business issues your organization is solving for your customers. From there, they each use that insight to achieve different things: Product Management uses it to decide what to build, and Product Marketing uses it to decide what to say about the product that’s been built. Let’s drill into the first a bit, and focus on the second another time.
When I frame out the pillars of Product Management, I see four major categories of work — Opportunity, Solution, Operationalization, Go-to-Market. As I’ve said before, this is a blog post, not a textbook, and I grant there are plenty of other ways to slice this up, but I think this is a useful way of segmenting the work.
Opportunity
The first job of Product Management is to identify the best opportunities for the business to pursue. Most companies already have a mission, market, and target customer, but may be seeking additional problems to solve. Very early companies may be looking for problems to solve and people to solve them for. More likely, they have some technology and have a sense of what it can do, but may not have a sense of who the best buyers are or what problems they might want to solve with the technology.
The PM staff should be responsible for digging into different market segments, and talking with prospective customers to figure out what their critical business issues are, why they are important, and how broadly these problems impact the organization. With enough conversations patterns and trends will emerge, pointing at potential addressable problems. The PM staff should be able to identify from these conversations what factors make a prospective customer likely to have these problems, and they then need to use this insight in conducting industry research to figure out how many companies might have the identified problems, to gauge what the overall market size might look like for each problem. Research into alternatives and competitors should also be part of the market research, and can be a crucial source for insights about specific problems and how existing solutions are being received in the market. These insights can make all the difference between making well-informed product strategy decisions and simply making educated guesses.
For companies with existing products, there’s a more tactical version of this kind of work, too — doing much the same with an existing customer base. From those engagements, the PM can identify unmet and adjacent needs, and also dig into why a product is or isn’t solving a specific set of needs. By spending time engaged with the customers and the broader market, the PM staff builds market expertise that lends tremendous credibility to their voice when it comes time to make business and product strategy decisions. Fail to do this work as a PM and you will fundamentally limit your value to the organization.
Solution
Once the PM staff has done the research to identify the best problems to go after, it’s time to focus on solving them. The first questions to ask are whether the organization has the ability to solve these problems, and whether it’s appropriate to try. Some problems are outside of our grasp, and others may be in our grasp but better solved by somebody else.
When it’s clear that a problem makes sense to solve, the PM staff should turn their attention to articulating the goals clearly, telling the story of what the customer is trying to achieve. Typically this is done in the form of an Epic, which is then broken down into Stories. At this point others start to pick up their parts in developing the solution, and it’s up to the PM staff to remain available to provide answers and guidance where appropriate. The main focus for PM should be to ensure that the folks charged with delivering a solution understand the mission and have sufficient guidance along their journey to deliver a solution that meets the spirit of the requirements.
Once the initial manifestation of the solution is available, Product Management plays a key role in bringing the product to market (more on this later), bringing the product to the broader organization (ditto), and then pivots rapidly to focus on requirements intake once again, taking stock of what customers do with what’s been delivered, and how well they think it meets their needs.
Operationalization
For very simple apps customers can usually figure out what to do and get successful with the software on their own — at least if the app is well designed. But for many types of software, it takes a lot more work to make a customer successful. When a typical enterprise solution is released, there are many teams that need to take action on customers’ behalf. DevOps teams need to put the software into production and operate it. Professional Services teams need to know how to implement it, how to do the discovery work with customers about how to use it, and then implement it on their behalf. Customer Support teams need to be able to field calls about the product when it doesn’t behave as intended or expected. Customer Success teams need to monitor customer usage and activity and help ensure the customer is getting the value expected so that they will renew their subscription when the time comes. Each product and organization will differ, but it’s likely groups like these will need engagement and enablement from the PM staff both before the product ships (getting ready), and after the product ships (as a source of expertise and conduit for escalation to Development).
It’s also very likely that some or all of these teams will need access to product data, dashboards, utilities, administrative workbenches, APIs and more in order to do their jobs effectively. Even the best-designed new products and features are likely to create needs for one or more of these teams, and it’s likely that at any given moment there is a backlog of needs from previous deliveries that still needs to be addressed.
The main thing to remember here is that PM is beholden not just to the customers but to the cross-functional organization as a whole. PM needs to remember this when making product investment decisions, and needs to advocate for the critical needs of the whole organization. You may as well not offer new capabilities at all if you can’t also make customers successful with them.
Go-to-Market
Commercialization is really what building products is all about, and PM often takes center stage in charting the Go-to-Market strategy for their products, particularly in smaller companies. As companies grow, though, Product Marketing tends to emerge as a distinct discipline, and GTM strategy can be split between these teams or end up in the Product Marketing camp altogether. In that sense, the fourth Product Management pillar can also be the first Product Marketing pillar. And since this post is getting a little long, I’m going to cap this here, and pick up the next time with a definition of Product Marketing, which will go deeper into the GTM planning role.
As always, thanks for reading.
John
