3 Pillars of Product Management
As a practicing Product leader and the founder of Product Managers Association of Los Angeles (PMA.LA), I’ve had a chance to meet a lot of Product Managers and a chance to learn about how Product is setup at a lot of different organizations.
In this article, I’ll outline a few of the reasons I see contributing to that, as well as outline the role I believe Product Management really should be playing as a counterpoint. With that as a backdrop, I’ll introduce a simple framework called The 3 Pillars of Product, may be useful as a skeleton when thinking about the role.
Confusion about Product Management
Why is there so much confusion and disagreement about the role of Product Management? There are a few reasons that immediately come to mind:
Type of Product– The nature of the business / product can have a big impact on the role you play, as well as the significance of stakeholder influence vs customer engagement. A B2C product for example relies heavily on user research to figure out the right features to build and why. A B2B product relies much more on Sales and thus you often have a lot less mystery about what to build – your important customers and/or your sales team are often happy to tell you directly.
No Formal Training (knowledge) – The role of Product Management can be traced back to consumer packaged goods in the 1930s but was just a subset of Brand Management found primarily in the CPG space until Agile and Scrum swept through tech in the early 200s. With Scrum came the designated role of the Scrum Product Owner and it would seem many companies simply worked backwards from there, hiring armies of newly minted Product Managers to play that role. But why would they know any better? There is no formal education for Product Managers and the most common form of training is Scrum CSPO training, which further reinforces this framing.
Unempowered Teams (trust)– Agile has been a major force in tech for 20 years now but many organizations are still learning how to co-exist with it, rather than embracing it. The main issue here seems to be empowerment – traditional organizations are run top-down, and a Scrum team is thus positioned to execute a strategy rather than owning and defining it. This is a dynamic I like to call “I.T. Product” because Product Management is positioned more as a Program Management role, to efficiently manage and execute the output of the team rather than owning an outcome and defining what to build in order to achieve the outcome. And unfortunately the Scrumification of the role, which focuses almost entirely on product development, too easily enables this dynamic.
A Healthy Product Management Model
The fundamental value proposition of Product Management is determining the right product to build (product-market fit) and seeing it through, thus reducing risk and improving overall ROI. It should not be delivering a list of prescribed features a business leader or stakeholder commissioned.
To illustrate what this should look like, consider the history of Product Management. The story with Neil McElroy, a leader in Brand Management at Product & Gamble who advocated for vertical product alignment, with a single manager for every product in the portfolio – that Product Manager would own the product from beginning to the end, acting as a mini-CEO of their Product.
This person would own something like a bar of soap or a toothbrush. They would spend their time observing in grocery stores and conducting focus groups to figure out why someone might choose one bar of soap over another. Based on this research, they’d figure out how to achieve the desired business outcomes and take this back to the design agency to design packaging, and the manufacture to formulate and deliver the right product. Even though the ‘CEO of the Product’ analogy has taken hold, I liken tis more to being a startup founder who is responsible for making sure every detail of their product comes together.
Key to this original definition of Product Management is that the role was fundamentally built around autonomy and outcomes, not delivery times and output. This Product Manager’s primary job should be figuring out the right product to build and guiding the process to fruition.
As clear and effective as this role definition could be, it has become distorted in recent years as it has gained in popularity with the adoption of Agile/Scrum. Again, I believe this goes back to the many reasons for confusion but perhaps also reflects organizational misalignment in some cases (does every company truly want Product Managers, or are some trying to shoehorn a product development manager (eg Program Manager) into a Scrum structure, as they adopt Agile?
3 Pillars of Product
I’ve laid out the problems I see in Product Management as well as what the prodigal model for Product really should be – but what’s really needed is a simple model that teams can reference as well as socialize when discussing these challenges within the broader organization. Enter the “3 Pillars of Product”.
At a high-level, there are really 3 main areas of Product Management – Discovery, Planning, and Development:
I. Discovery – This is the heart & soul of Product Management in my view and our primary opportunity to generate maximum value. This is where the various modes of research sit and lead to us figuring out what product and features to build, in service of the customer. It is important to note that Product really should be focused on serving the customer here, NOT the business. In other words, stakeholders may have ideas and some of them may even be good! But our goal fundamentally to create value for customers, not as a services organization to deliver requests for the rest of “the business”.
II. Planning – Often overlooked but Product should be spending considerable time crafting a long-term vision and developing / maintaining a roadmap. Strategic planning is like an iceberg insofar as there is a whole lot more that goes into the vision and roadmap than is immediately evident (above the water line). Like a concerto, every note must be carefully considered and thoroughly composed to maximize the result.
III. Development – Lastly, development is where it all comes together into a tangible product. This is the execution step that that the Scrum Product Owner focuses on and is most visible to the Scrum team. It starts with requirements and acceptance criteria definition and culminates with a prioritized backlog and answering questions in support of the team as they create the product/features that have been envisioned. This process starts with UI design and progressing through post-launch A/B testing to really tune and optimize what has been created.
Hopefully this model is useful as a quick reference. It is my hope that models such as this can contribute to a better defined and aligned role for Product Management within every organization.
