Recently, I was speaking with an aspiring product manager who was looking for a foundation of knowledge in product management. She wanted to get a sense of the breadth of the responsibilities and practices that went along with the role. As I have done in the past, I directed her to the Pragmatic Framework from Pragmatic Institute.
Shortly after that, I was doing a mini project of my own, to try to pull together and organize all the product management related resources I have collected over the years. Resources include presentations, scholarly papers, collateral, blog posts, videos, and links to similar online resources. Once again, I thought I would leverage the Pragmatic Framework as a taxonomy to help me organize these resources in a logical way.
This post briefly describes my review of existing frameworks and then presents a new, basic reference framework I ended up creating so that I can organize and share product management resources.
(Don’t want the background info? Skip to the The Product Management Reference Framework)
Assessing Existing Frameworks
Since I first encountered the Pragmatic Framework many years ago, I have often leveraged it in coaching other product managers and assessing organizational effectiveness. One of the great things I have always liked about it is that, unlike a lot of discussions of the product manager role by many thought leaders today, it provides a more complete scope of what product organizations have to take care of. Under which title or role, particular responsibilities fall is secondary.
Here are just a few examples of activity areas that often fall outside of many product manager responsibilities but must be considered broadly as part of product management, which I believe the Pragmatic Framework effectively contemplates.
Pricing – Pricing frequently is taken out of the hands of individual product managers and managed by a CPO, Marketing or Sales. Pricing is tied to the value of problems solved, how it relates to licensing and features to enforce usage privileges, an understanding of the market buying patterns, and expectations set through positioning and more. These are tightly interconnected concepts and should be defined with intention. When pricing is not viewed as a feature of the product there is a missed opportunity to optimize business results.
Product Profitability – Profitability is driven by a combination of price and cost of goods sold. Profit margin is a very important metric for many businesses to understand how well a particular product is performing toward high-level business goals. Yet, most product managers do not know how profitable their product is. That is because the cost of goods sold in software companies is mostly attributable to employee compensation, which is reasonably sensitive. However, somebody must understand the profitability of each product within a company’s portfolio if they want to make effective business planning decisions.
Market Definition – At some point, every business focuses on a specific market to identify problems worth solving for. Often this is just part of the company origin story but it could have been arrived at through focused strategic business planning. How the market is defined is critical to identifying customer segments and learning about their problems and desires, so that solutions can be created and effectively marketed to them. If there is no clear market definition, sales will go after the wrong prospects and product teams can’t effectively prioritize.
Buy, Build, or Partner – Companies should be coordinated and intentional around buy, build, or partner decisions so they are aligned with what is important and core to the business objectives. There is a tendency today to “buy” as much as possible through acquiring open source components that must be considered relative to where the company intends to differentiate it value to customers. On the other hand, companies need to be careful not to build capabilities that are not core to their target market or are otherwise viewed as commodities. These decisions impact perceived value, cost of goods sold, licensing terms, and so much else that must be considered as a part of the whole product.
It was with some chagrin then, that upon taking a critical look at the Pragmatic Framework I found it unusable for my purposes. It still does a good job of capturing an expansive view of what product management is. However, it does not provide the most effective organizational structure to make it actionable.
Therefore, I set out to consider other frameworks and similar resources to leverage, including:
- Roman’s Product Management Framework by Roman Pichler. Excellent scope and somewhat uniquely highlights Vision and Leadership within core knowledge areas, which is fundamental to driving success for product managers through influence.
- 280 Group’s Optimal Product Process. Divides strategic and execution activities with an emphasis on artifacts and product lifecycle. This is great because too many product organizations do a terrible job at managing mature products and those being sunset, instead focus too much on developing new and growth products.
- Tolpagorni Product Management Framework / ISPMA SPM Framework does an effective job of describing the breadth of product management as core activities, participation, and orchestration. Provides a slightly different perspective to mentally organize activities than Pragmatic Framework.
- The Secret Product Management Framework by Nils Davis. Simplifies the essence of product management enabling flexible adaptation to new practices over time.
- Blackblot Product Managers Toolkit (PMTK) on the surface provides an awesomely simple model of Problem Space v. Solution Space. The next level of detail, however, becomes too prescriptive and contains many strong viewpoints that are debated by other PM experts.
- AIPMM’s Product Management and Marketing Body of Knowledge (ProdBOK) and PDMA Body of Knowledge (PDMA BOK) are both comprehensive encyclopedias of product management but they don’t provide a simple reference framework. They also appear to contain a lot of outdated practices for modern technology companies.
AIPMM’s Product Management and Marketing Body of Knowledge (ProdBOK) and PDMA Body of Knowledge (PDMA BOK) are both comprehensive encyclopedias of product management but they don’t provide a simple reference framework. They also appear to contain a lot of outdated practices for modern technology companies.
I get value out of all of these different product management frameworks as all are based on deep experience and unearth valid perspectives. Before I did an intentional review of these additional frameworks I started to draft my own model based on my own experience. Amazingly it lines up rather closely at a high level with The Secret Product Management Framework. After reaching out to Nils on this topic, he also pointed me to a recent comparison video he did between his framework and others that you can find here.
Upon reviewing his excellent video, it occurred to me that while we had similar high-level framework results we may have been solving for slightly different initial problems. Nils’ written intro is that he wanted to explain what product management is. Elsewhere in his framework comparison video, he explains that his framework helps explain the ‘Why?’ behind activities… To solve problems and get those solutions to market.
For me, I wanted to develop a simple reference framework to organize practices that can be considered at any point in product lifecycle management across a variety of product management roles. In a sense, I am seeking the reference value provided in the Pragmatic Framework or Tolpagorni Product Management Frameworks but wrap it into a simpler high-level view that Nils’ Secret Product Management Framework provides.
The remainder of this article introduces a high-level view of my second framework iteration based on some feedback from Nils and other product managers.
Product Management Reference Framework
There are three core practice areas in every product organization, even if not clearly articulated. These are:
- Insight Discovery
- Product Development
- Go-to-Market
The logical initial flow of work is Insight Discovery followed by Product Development. As the solution takes shape, Go-to-Market activities follow. Over time, these three practice areas are continuous and constantly informing each other. The applicable practices will vary based on the nature of the product and at different points throughout the product lifecycle.
Core Practice Areas
Insight Discovery
Before developing new solutions it is critical to understand the current context. There are many dimensions to this which include an understanding of market needs, competitive alternatives, available technology, organizational feasibility, and business strategy. It is important to not just learn the facts but critically analyze these to arrive at meaningful insights for decision-making.
For existing products, there is an additional baseline understanding of current product capabilities, customers, partners, and ideas stakeholders have for addressing their needs.
The most critical insights are the identification of problems worthy of solving. The additional context gained through additional analysis is critical to selecting which problems to prioritize solving and later provide the critical input to effectively bring products to market.
Example practices include: market opportunity analysis, customer journey mapping, competitive analysis, customer discovery
Product Development
The practice area that gets the greatest attention within most organizations is Product Development. The specific focus is historically is on how to develop a product most efficiently, with a lot more attention in recent years to ensuring the right product is being built as well.
In my framework, I expand the definition of the product being developed beyond code or physical artifacts to include the full scope of what potential customers might contemplate when deciding to acquire or use your solution. Anything being provided to, hopefully, improve the customer journey, while addressing their needs and desires is part of what the organization must also consider as part of the solution.
The best products involve multiple parts of an organization that are aligned and working in a coordinated way to deliver value to customers while addressing other business stakeholders’ needs.
Example practices include: product strategy, roadmaps, agile development, lean ux, minimal viable products, buy-build-partner decisions, beta release, hypothesis-driven design, design sprints, and user personas.
Go-to-Market
Regardless of how much effort goes into defining the perfect solution to significant market problems, value is not realized until customers acquire and use it. Sales and Marketing play a critical role in Go-to-Market efforts. However, many decisions are tightly coupled with the definition of the product and, therefore, cannot be made in a vacuum. Collaboration and alignment with the Product Development process is critical.
Examples requiring alignment include: choosing a SaaS versus On-Premises Deployment model for B2B software, geographic expansion requiring new languages and data display formats, authentication options for consumer applications, configurability when leveraging channel partners.
When aligned with low friction, customers become delighted to do business with you and actively seek out additional products and services you may offer. Unfortunately, Go-to-Market and Product Development are not always aligned creating sub-optimal customer value and unexpected consequences to other stakeholders.
Example practices include: positioning, pricing, licensing, channel strategies, sales enablement, content marketing, partner training, growth hacking, documentation, training, and user groups.
Business Context
Everything done within Product Management must fit within the context of corporate mission, business strategy, operations, and stakeholder demands. At its best, this context provides clear guardrails and enablers for product management success.
Essential business context:
- Mission
- Business Strategy
- Operations
- External Stakeholders
For example, without a business strategy, which markets should be evaluated for potential opportunities? How should scarce internal resources be allocated? What is the definition of success for the business?
Example practices include: business planning, brand marketing, portfolio management, OKRs, investor relations, M&A.
Product Management Enablers
Work is always getting done, but with the right organization, processes, and tools in place it can be done better. The best product companies don’t just hope a few knowledgeable, engaged leaders will drive the entire organization toward the best outcomes. The best organizations provide the right environment for success and continuously look for how to improve.
Key enablers are:
- Organizational Design
- Professional Development
- Product Tools & Processes
Organizational Design
Melvin Conway in 1967 stated that “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” (M Conway) In basic terms, software architectures will reflect the structure of teams designing and developing them. This is an important consideration as software organizations scale beyond a dozen employees to hundreds of developers, designers, and product managers. If you split yourself into multiple divisions but customers expect a single integrated solution across those divisions, you will be working against a natural phenomenon.
Very often, the organization design is a by-product of organic growth, opportunistic assignments, and the intentional application of development methodologies. However, as the Product Management Reference Framework illustrates, there are many responsibilities required to produce and deliver solutions to market beyond engineering teams. It is critical when defining and tuning organizational design to consider the broader implications.
Even the very popular current practice of cross-functional product teams is quite limited. Minimally, a product manager, designer, and engineer comprise a team. The product manager is expected to represent the customer and a lot of stakeholders in such a team, which may be sub-optimal at times and perfect at other times. Every company needs to continuously assess how to optimize the organizational design to achieve their primary objectives.
Professional Development
Certain roles and people within most organizations are more likely than others to seek out professional development opportunities. Best practices within product management are continually evolving and require curious individuals to seek out these advances. This self-development needs to be encouraged and promoted.
Research has repeatedly shown that the more senior the employee is, the less likely they are to seek out new educational opportunities. Either they are too focused on their day job or simply don’t feel that time spent in educational opportunities will be worth it. This is no longer acceptable for organizations that expect to remain competitive. Companies must assess the professional development needs of the organization and individuals then develop programs to support advancement.
Many opportunities exist today including Training Workshops, LinkedIn Learning, hosting Meetups, Lunch & Learns, and Coaching.
Product Tools & Processes
Product Management is experiencing a wave of investment in tools to support professional practices be more effective. Roadmaps can now be effectively linked to the work being developed back to original strategic intent. It is true that some tools have existed for years, even Excel and Powerpoint can be effective when used in the right way (although not always efficient). However, the new tools are easy to use and there is no reason companies should not be looking for better ways to reduce administrative burdens on teams so they can focus on what matters.
For companies developing SaaS or other digital products there are really incredible tools available now to help gain insights and use data-driven product practices to optimize and elevate your investment decisions.
How to use these tools and how they fit into the SDLC of your organization should not be missed. Processes can be both intentionally implemented and organically developed. While most organizations are now using some form of agile practices, specific methodologies vary and so do outcomes.
While Harvard Business Review may frequently tout new methodologies, not every change is right for every organization. When it is right, be aware that every methodology has both it strong supporters and those that claim it to be the worst thing ever invented. I am a believer that all methodologies have some value and they should be taken only as a starting point to be adapted as your usage matures.
Example product tools: Aha.io, prodpad.com, productboard.com, craft.io, roadmunk.com, heap.io, amplitude.com, and launchdarkly.com.
Example product processes: agile methodology, scrum, kanban, xp, dual track development, test driven development, Flow, SAFe, LeSS, and Nexus.
In Conclusion
This recent exploration of frameworks has been very interesting. All the examples reviewed provide a lot of value and insight for practicing product management professionals. Nils Davis’ framework is most closely aligned with my take but I feel like it is not functional enough for my purposes.
Since drafting my framework, I have already been using it with much benefit and, yet, have already discovered areas for improvement. These come from attempting to classify specific practices and sub-discipline activities into this framework. As I edit and revise, I’d love to hear feedback from the community. Feel free to use the comment here, Twitter, or LinkedIn to track me down.