Clarifying the Role of Product Management

Have you ever noticed that Product Management is different at every company? To the point that it can look like a completely different role with non-transferrable skills. At Company A it is about figuring out what to build and crafting long strategy documents. At Company B, there are no documents at all but a strong emphasis on delivery. I feel like this lack of a clear anchor is a weakness for the role, and so I’d like to take a pass at defining what I think the role should be and why.

What is product Management?

When thinking about Product Management as a role, it is helpful to begin with a definition of the object which we are managing – the product.  I define a Product as a solution offered to a market, to enable or make efficient a specific customer need or desire. Implicit in this definition, Product Managers identify an under-served market segment, understand their needs and how to solve them, figure out how to differentiate the solution in the marketplace, and then take that solution to market at scale, such that we’re creating a valuable solution at a relatively low cost that will resonate with a broad audience.

This definition is intentionally rooted in a Marketing perspective, which is the origin of Product Management. In fact, if you go back to the 1930s, Product Management began in the Brand Marketing department of Procter & Gamble, as a way to vertically scale the Brand Marketing department, allowing individual “brand men” as they were called, to go deep and truly own every aspect of a product, from understanding their market, to production, and taking that product to market.  Inherently then, Product Management is looking at the Product from the perspective of the Marketing Mix 4P’s.  

 

 

The mission of the Product Manager in this context, was to understand everything about their market and then ensure the correct product was built.  Product would speak with customers, go deep on customer and competitive research, and spend time in the field to understand why customers behaved as they do.   And thus, the value proposition of the Product Manager to the organization was to ensure the success of the product, principally through ensuring product-market fit, and reducing the risk of investing significant resources into building something that no one would buy.  The Product Manager would then shepherd the product through development and taking the product to market, ensuring the end-to-end loop was successful, and adapting or correcting course where needed.

 

History of Product Management

The above description was the role of the Product Manager for the majority of the 1900s and you’d primarily only find Product Managers at CPG companies such as P&G until consumer software products began rising to prominence in the late early 2000s in the Silicon Valley – and that’s when everything really changed. 

In 2001 the Agile Manifesto pulled together a number of similar concepts and methods into a common mission, in juxtaposition to traditional Waterfall methodologies, to move toward small-batch incremental development. Software is inherently different from physical products insofar as it is much easier and less expensive to make small incremental changes and deliver those to the market, which means software products were able to shift to a model of providing a constant stream of incremental improvements rather than having to wait for large batches.

Scrum is the popular Agile Project Management framework that emerged around this time as well, and with it, a definition of two important roles within a product development team – the Product Owner and the ScrumMaster.  Because this was a project management framework for incremental and continuous development, that means Product Management would no longer develop large Product Requirement Documents (PRDs) and throw them ‘over the wall’ to Engineering to implement in a different department.  Instead, the Product Owner began co-locating as part of the team and developing requirements iteratively as well. 

This new approach has its pros and cons but one notable change is that this shifted the person playing the product role from being a strategic Product Manager primarily looking at product-market fit, to a more tactical role that defines, supports, and clarifies requirements on a real-time basis.  And because this is in the context of software development, there is never a shortage of clarification needed for nuanced details for various use cases.   

 

Finally, in the 2010s, an awakening began in the software industry, when two seminal books (Four Steps to the Epiphany and Lean Startup) introduced Lean Methodology, as a way to incrementally address product-market fit (PMF) in a way that meshed with Engineering’s new Agile development principles.  Interestingly, many of these techniques for iterative product discovery were pioneered much earlier by Toyota in the 1960s, but with re-discovery, new life was given to the role of Product Management, as the value and compatibility of the role in the new Agile paradigm, became clear to the rapidly growing software industry. The number of people holding the title rapidly increased and Product Management, often referred to as a mini CEO of the product, was soon the most popular career path for recent MBA graduates.

 

Product Management Activities

With the history of Product as a backdrop, I think of Product Management as having three main functions: (i) Opportunity Discovery in which we understand customer needs and market dynamics, (ii) Product Planning in which we assess the opportunities, define a rational prioritization framework, and create a roadmap, and (iii) Product Development, in which we work with our technical and design partners to realize the product we will eventually take to market.

   

Note – I provide a much more comprehensive breakdown of Product management activities in the Product Competencies framework.  

 

Definition of Success

Because Product Management is a strategic role, meaning that success should be measured in terms of outcome, not output. A product is successful if it achieves an adoption or engagement goal, not because x number of features were delivered. 

This is a paradigm shift from other roles such as Program or Project Management and so it is important to call out.  In fact, even the Agile Product Owner is sometimes positioned to be more outcome/delivery driven, which is a scrum team role often played by IC Product team members, which further engrains the confusion.   So, keep this important difference in mind – it is foundational to driving impact.

Where Does Product Strategy Fit?

If we agree that Product Management is about driving outcomes which makes it a fundamentally strategic role, then where does the product strategy fit within an organization that already has a business strategy?

The simple answer is that strategy cascades within an organization from Corporate strategy to Business and down to the Functions of the business (eg Marketing, Finance, etc). The Product strategy is one of those functional strategies.  It inherits key inputs from the cascaded Business strategy such as goals and responds with a plan to achieve those goals, by addressing customer needs. This is then passed further down to the operational/action plan, which describes what will be delivered and when. 

Having put these layers into perspective, Product Management is not working in a vaccuum, nor are we defining the business strategy. Rather, Product is working to deliver on the Product Strategy that supports the Business Strategy – with a mandate from Business to build a product in some general direction, it is Product’s role to figure out what that right product is to build, in order to achieve the goals of the Business strategy.

This structure is a good point of reference for how Product is ideally situated within a larger organization but naturally, this isn’t always the case.  For example, in a startup , there is not nearly so much structure as this and Business strategy vs product strategy are often blurred together (the Business Model Canvas, for example, is a popular tool of startup product Managers).  And still at other companies, for reasons I explain here, Product might not even be its own standalone, often rolling up to either technology or another functional group.    

 

Variability of the Role

The last point I want to touch on while defining the role of Product Management, is why the role varies so much from company to company. Because of my role in founding and leading PMA.LA for several years, I had the opportunity to interact with hundreds of Product Managers and I’ve observed a few patterns that affect how Product Management is practiced:

• Type of Product – The nature of what you’re building varies dramatically from B2C to B2B to internal. B2C, for example, will place much greater weight on a sleek user experience, whereas an internal tool or platform may place little to no value in doing so.  Discovery is also very different – with B2C you must discover what they want.  With B2B or internal, your key users are more than happy to tell you what they want, and delicately saying no becomes a critical skill. 
• Seniority Level – Many junior Product Managers have great hopes of driving strategy and being CEO of their product but in truth that responsibility often lies with someone more senior in the Product organization. The role of a junior Product Manager is often more ‘heads down’, focused on feature definition and development.
• Product-First Organizations – Organizations who are known for their products rather than their service or arbitrage (buy/sell) activities, naturally place Product Management at the tip of the proverbial strategic spear. As such Product Management has much greater political weight to drive the strategy for the company.  At service and trade organizations, Product is often supporting a strategy that is defined by another Business function, and this positions the role to be more tactical than strategic.
• Orthogonal Roles – Because Product Management is charged with the success of their team, that often means Product will act as the ‘glue’ and fill in various orthogonal roles where help may be needed but isn’t a core function of Product. Project Management, UX, Analytics are, and Product Ops are common areas where Product Management may fill in.  The risk is that one of these orthogonal roles can take over a disproportionate amount of time and take away from core Product responsibilities. This is especially the case when a dedicated ScrumMaster or Program Manager are not available to support the team.
• Product Lifecycle – The role of Product at a startup is almost entirely focused on product market fit of the ‘MVP’ product. More mature products trade the need to find market fit, with the need to instead satisfy the many stakeholders that have grown up around the successful product and each has their own feature requests to support their efforts.  This can shift the role from being very outward and strategically focused, to being more focused on internal diplomacy.
• Reporting Hierarchy – If Product is positioned to report directly to Business rather than being positioned under another business group, that positions Product to lead a functional strategy, rather than supporting one. Similarly, placing Product under a business function vs under Tech/Engineering means the role (while supporting in either of these cases) could be much more Business or Technically oriented.

 

Conclusion

In summary, Product Management is fundamentally about understanding the needs and desires of the customer segment you’re serving, figuring out the right product to build to optimally address those needs, and working with a cross-functional team to continually build and refine that product, to ensure it is maximally successful in the market.  The role of Product Management can vary significantly, depending on how the Product function is positioned within the organization, the maturity of the product, and the type of product being developed.  Fundamentally, however, Product Management is best positioned to create value, when the focus is placed upon driving an outcome, rather than merely delivering an output.