What is Product Management?

Product Management Guide

Product Management is about making sure that we build the right product for the market.  We start with a mission from business to build something for the benefit of customers that will achieve business goals. We work to understand the customer and their needs, to ensure product-market fit.  Understanding ‘why’ we’re building something allows us to determine ‘what’ to build for our team. In this way, Product Management is strategic – the Business strategy and our part in that has already been determined, but understanding the market and how we serve it with our product, is very much the domain of Product.  

In Practice

According to the 3 Pillars of Product, there are three main aspects to the role of Product Management: the first is Opportunity Discovery which is rooted in market research and understanding the ‘why’ behind what features we create. 

After identifying opportunities that we may want to address with our product, the next step is Product Planning.  In planning, we’ll coalesce the best opportunities and align them to our strategic goals. We’ll sequence activities out on a roadmap, to provide internal guidance on how we’ll align resources and when we hope to achieve desired outcomes.  Finally, when that is in place, we can begin working on the development of those features with our team. Product’s role here, is to clearly articulate the need, criteria of an acceptable solution and to work with the team to create the solution (not dictate it to them).  Once a feature is designed and developed, we verify if it satisfies the need and test it with customers and through performance data, to ensure it is successful – leading the team through iterations and pivots as needed, to ensure each new feature is a success. 

What is a Product?

It is difficult to really say much more about Product Management without first defining what a product is – we’re managing something after all, but what is that thing, and where do we draw the line between a product versus a service or an operational program?  

Simply put, a Product is a generalized solution to a common need or desire, that can be taken to market and sold.   A product brings economies of scale to bare for its customers, making this generalized solution, much more affordable than a custom solution or service would have been.   Implicit in that definition is the need to take something to market. We’re solving a problem at scale for thousands or perhaps millions of people. How do we know we’re building the right solution for most of them?  Or, that they value our solution more than a competitor?

Product Market Fit

Product Management is not principally responsible for delivery – we are responsible for ensuring that the product we deliver is successful.  We measure success in terms of business KPIs, not delivery dates.   That’s not to say we shouldn’t care about timely delivery since this can also affect the outcome – but it is important to put it into perspective of what we’re really trying to achieve. From this perspective, the single most impactful thing we can do, is to understand our market and ensure we’re building the right product for them.  This is referred to as “product-Market Fit”, which means, ensuring that our product fits the needs of the market.  To achieve market fit, we really need to be thinking about how our product is positioned, how it is experienced/perceived, and the key features that differentiate from our competition.   To this end, our attention should really per focused on how the product meets the market, not how it is produced or how the internal workings operate.  

History of Product Management

To really understand the role of Product Management, it is important to consider its history and origin.   Most people in tech product development know the Scrum Product Owner role, but that is just one aspect of the role.

Product Management began in the consumer packaged goods (CPG) space, at Proctor & Gamble in the 1930s.  The “product men” were an extension of the Brand Marketing team and each one owned a single product deeply and from end-to-end.  The Product Manager would own every aspect of their product, from working with the manufacturer to create the product and the design agency to create the packaging – all the way into the field-level research that informed decisions they’d bring back to the manufacturer and design agency to inform refinements.  That field research the lifeblood that allowed the original Product Managers to understand the market and represent informed decisions back to their partners. Put another way, their core responsibility was Product-Market fit.  

That was Product Management in a nutshell, until the 1990s when the early Agile frameworks such as Scrum and XP in the Silicon Valley began to emerge. It was in this context that Scrum introduced a role called the Product Owner who would work with the Scrum development team on the development of their software.  The Product Owner was the Engineering team’s perspective on Product Management, and what they needed from the Product organization – detailed requirements, acceptance criteria, and user acceptance testing. It is inherently product development focused however and does not describe all of the research and planning that is part of the broader and historical Product Manager role.   As Agile has grown in popularity, the Product Owner role has become more ubiquitous and become a de facto definition of Product Management for a lot of junior Product Managers and their technical teams who are concerned primarily with development activities. That’s not the whole story, however. 

In the 2000s, another major shift brought Product Management into the current era with Lean methodology.  Whereas Agile is about iterative development in order to get product out more quickly, Lean is about doing product discovery in a similar iterative way, ensuring that we’re constantly learning and factoring those learnings back into what we’re developing.  Lean borrows principals from Toyota’s Just In Time (JIT) manufacturing and brings those concepts into the modern era. In practice, this means talking with customers and reviewing analytics data constantly to learn what we can and making iterative improvements along the way.  This holds true with the original mission of Product – to ensure the success of the product. 

Product Management has come a long way since the 1930s but the fundamental principles are still the same – our goal is to understand customers and our market, in order to ensure we build the right product so that we achieve business goals, by creating maximum value for our customers.  All of the complexities about how we write requirements and represent those back to our product development teams are just the means to this end.

Product Management Activities

Since Product Management is ultimately responsible for the success of the product, we often end up acting as the gap-filler for the team and filling in where there is a gap on the team.  This combined with nuances about the nature of the business, size of the team, and seniority within that team can cause a given Product Management role to be very different from others, almost like a snowflake.  It is important to realize the reasons for this, however, and to clarify what the core intentions and responsibilities of Product Manager are – which should hold true across all companies and roles.

The Product Management Competencies framework from Neal Cabage lists skills commonly associated with Product – strategic activities are at the top and more tactical skills toward the bottom.  On the left are external market-facing skills and on the right are internal business analysis types of skills. All of these are important, but depending on your seniority within the team, you may bias up or down on this list, and depending on the nature of your product (or your focus area on the product), you may bias more to the left or the right.

Product Management NOT Project Management

Equally important is to be clear on what Product Management is not.  Although we may need to fill in where gaps exist, we’re fundamentally not UI designers, Marketers, QA, or analysts.  And perhaps most problematic (and common), we are not Project Managers.     

Project Management is one of those activities that often is overlooked in Agile development because there isn’t a clear role for a Project Manager to play – and too often Product Management will absorb those responsibilities.  As important as these activities can be at times, the day-to-day urgent details can overtake the important in terms of day-to-day priorities if we’re not careful, and rather than thinking about customer/market strategy, the Product Manager can get sucked into day-to-day coordination instead, neglecting their important longer-term strategic responsibilities.   A year later, people begin to ask why Product Management is not more effective in ensuring the success of the product. As important as it is to fill gaps to keep things moving forward, the Product Manager must keep the big picture in mind and ruthlessly prioritize their own activities, just like they would the team backlog.

Conclusion

In closing, Product Management is a strategic role that assists business in achieving their goals, by serving the needs and desires of customers.  Product Management creates value through generalized solutions to common problems – by understanding the needs of those customers and the competitive market landscape, Product Managers can better determine the right product to build.  The Product Manager works both in a strategic space to answer the “what & why” but also in a tactical space, working directly with product development teams to create feature solutions and iterate those solutions to ensure success. It is important to keep the greater perspective and to ensure the strategic Product work is not replaced with the urgent day-to-day needs on the ground – keeping that balance is key to successful Product Management.