As a career product leader, I love to geek out with other product people about how we build and re-build our teams. Organizational planning is important! For a long time, i’ve meant to write about the stages of organizational growth in product management, and for me, maturity models are a perfect fit for this kind of analysis.
I’ve had plenty of success in the past using a stage-based maturity model for describing data maturity, for design team evolution, and for infrastructure planning – so I applied that same strategy to the experience of my own companies and those of my peers in product management, and came up with a framework to help you understand where your team is at today, where you’re headed, and what kinds of challenges you must solve at each stage of growth.
I’ve shared this model around with other product leaders, and the consensus is that, at least for tech companies, product teams pretty much all follow this evolution:
- Stage 0: Early-stage product teams, often led by founders, and how they manage product development, plus that all-important hiring of the first product manager.
- Stage 1: The transition to sales-led feature development, the need for additional product managers, and the expanding role of product management in customer interactions.
- Stage 2: The introduction of a VP of Product to formalize processes, create structured roadmaps, introduce a market-driven vision, and manage growing teams.
- Stage 3: The differentiation of roles with Principal Product Managers focusing on market segments and efficient development strategies.
- Stage 4: The emergence of the Chief Product Officer (CPO) who sets strategic direction and balances internal and external priorities while developing an organization that can operate at scale.
- Stage 5: The adoption of a matrix structure for managing multiple product lines and routes to market, ensuring clear prioritization and efficient development across an increasingly-complex organization.
These stages will tell you when it’s time to hire that VP of Product, or if you are outgrowing the one you have and need a CPO, or why your founding product manager isn’t excited about running a team herself and is in danger of jumping ship. If you’ve read this far, I bet you’re already wondering where this model places your team. So let’s dig in!
Stage 0 – Zero or one product manager
Stage 0 organizations are exclusively early-stage, with a basic engineering organization (that may not yet even be split into teams). Feature development is engineering-led, and your core product (and customer understanding) is still being sketched out.
At Stage 0, your product leader is typically a founder, often the CTO or CEO, who possesses a clear vision for the product. This vision is usually well-articulated because of all the pitching practice gained during fundraising. Although they have a deep understanding of the opportunity space, their grasp of the current market landscape may not be particularly mature.
As the initial product offering of a Stage 0 organization is developed, the detail-oriented work of story development, spec reviews, and sprint planning can quickly overwhelm the limited bandwidth available to a founder. Time pressure will overcome the desire to stay engaged with the engineering team.
During this stage, it is common to hire your first product manager. This individual should have either previous experience as a product manager or extensive domain expertise in your industry. (Bonus points if that individual has both, but don’t hold out for it.)
At Stage 0, your product leader is typically a founder, often the CTO or CEO, who possesses a clear vision for the product.
It’s not uncommon for you to bring in a highly engaged early customer who has provided significant feedback. This person will have a strong understanding of your product and some market insight, and can usually overcome their lack of formal product experience by partnering closely with engineering to develop a compelling feature set.
At this stage, the primary relationship for product management is with engineering, with secondary interactions with presales and post-sale support. The main function of product management is to organize and prioritize work, and thus the main operational tool of product management is the backlog. User stories and functional specifications provide the primary means of communication with engineering.
Stage 1 – Two to four product managers
Stage 1 organizations are those that have hit on a successful combination of capabilities that meet the needs of a set of customers (but not necessarily a cohesive market). These organizations have an active sales motion, are refining and growing the core product to meet the needs of new customers, and are growing their engineering capacity to keep up. A shift from engineering-led to sales-led feature development is a hallmark of this stage.
At this stage, there is a clear need for more product management capacity to capture customer requirements, prioritize work, and partner with an engineering organization that is dividing into specialized teams. Additional product managers are brought in to handle the workload, and the Stage 0 PM tends to develop a ‘lead PM’ persona, whether formalized or de-facto.
Most Stage 1 organizations are still operating under a founder-leader, and are flat, with individual contributors reporting directly to the founder. PMs in this stage are often ‘free-range’ – with limited personal bandwidth, a founder can’t provide a lot of coaching, and does not have the formal PM background required to train new hires. It’s not uncommon to send product managers in this stage to training companies like Pragmatic Marketing when founders cannot provide strong product mentorship themselves.
In Stage 1, product management’s web of relationships is expanding, with sales teams and revenue marketing making inroads to get help on customer calls and on positioning. Engineering still consumes the majority of time, but product managers are taking more “feedback” calls and routinely engaging with post-sales support teams.
It’s not uncommon to send product managers in this stage to training companies like Pragmatic Marketing when founders cannot provide strong product mentorship themselves.
You find your organization has matured into Stage 1 sooner rather than later if product management is already spending meaningful time with your go to market organization, not just with sales. Product managers who are getting onto sales calls, supporting solution engineers, or operating as shadow product marketing will have less bandwidth, forcing growth earlier.
Product development continues to be planned through backlogs rather than formal roadmaps, with requirement summaries serving as containers for user stories, UX designs, and functional requirements, lacking business case and use case information. PRDs aren’t likely to show up in Stage 1, as they have no obvious consumers.
Stage 2 – VP Product, five to eight product managers
Stage 2 organizations are typified by a developed sales motion, a rapidly-solidifying customer base with some stand-out success stories, and a product that has a mature core of capability that is expanding in several directions at once. They are also typified by increasing chaos at the intersection of development and go-to-market – there is just too much going on, and change management is a real problem for the organization.
An easy telltale that your Stage 1 organization is ripe for Stage 2 is when your customers tell your account managers about great new features that were recently added to your product. (This is more common than most people would like to admit!)
Adoption of a Stage 2 approach is forced by the limitations of the flat structure of Stage 1. Remember, in Stage 1, our free-range product managers have product direction but little oversight or support. Roadmaps, often just extensions of the backlog or CTO’s architectural plans, appear disorganized or unintuitive to stakeholders outside of engineering. The CEO can no longer dedicate time to managing individual product managers, and obviously needs to insert a new manager to take over the group. The recruitment of a VP of Product to lead the product vision and develop it with the team is a strategic priority.
A VP of Product in a Stage 2 organization formalizes the product management organization, implementing both organizational and process concepts. This stage involves creating real roadmaps, an articulated product vision, and a comprehensive release process. The VP will define clear boundaries between engineering, product, and other teams, and will forge a new SLA with customer success, with support, and with sales.
This stage involves creating real roadmaps, an articulated product vision, and a comprehensive release process.
Stage two can also lead to interesting tensions because it’s the first time the founder is pushed to release ownership of the product vision, but isn’t forced to do so by an exec-staff peer. Stage two organizations often retain heavy involvement from the founder in product vision and thought leadership, while the VP product takes over all of the day-to-day product functions and execution and owns research and discovery as the company becomes increasingly market-driven.
You’re going to be tempted to put this person on your executive staff – and that might be a good fit if they’re a more experienced organizational leader – but I would recommend separating the decision about exec staff membership from the selection of your product leader.
Another all-too-common mistake at Stage 2 is to promote your Stage 0 product manager to VP of Product. It’s tempting (and that person may wage an all-out campaign for the job!) but due to their lack of people management and organizational design experience, it’s rarely the right choice. Instead, hire someone with public company front-line manager experience or a director of product from a late-stage startup.
You don’t need the world’s best manager at this stage, but you can’t afford a novice manager learning on the job either, because the VP of Product transforms product management resources into a cohesive team, establishes standards, and prepares the organization for growth. At this stage, expect formalized career ladders, implementation of the product capabilities of your JIRA/Confluence stack, monthly roadmap reviews with other teams, and a predictable feature launch process.
Also in Stage 2, product managers will begin writing formal requirement summaries with business justifications, user goals, platform and testing requirements, and dependencies. Not every feature will get the full treatment, but the majority of work will go through formal reviews.
Roadmaps will become the stock-in-trade for product managers to communicate with both internal teams and with customers about the future, and a standard roadmap deck, updated quarterly, becomes a regular part of the sales cycle.
If you’re in a Stage 2 organization, you may be prioritizing individual features and customers over a coherent market thesis. However, be forewarned: staying sales-led for too long can easily lead to ‘bag of doorknobs’ product phases where a lot of capabilities are being built but they’re hard to describe without a lot of domain expertise, and the repeatable sales of strong product/market fit will be elusive even while individual customers are extremely positive about the product.
The medicine for this issue is to push your product managers to serve markets via roadmaps, and individual customers as exceptions. Still, a large degree of flexibility is warranted – you’re sales-led at this stage because you need the revenue – so don’t fight it too hard.
Stage 3 – VP Product, eight to twelve product managers
In Stage 3, the VP’s role shifts towards organizational leadership as the product team grows and specializes. Stage 3 organizations have 40+ engineers and product management is well-integrated into the day-to-day development process – but the distinction between stage 2 and stage 3 isn’t primarily one of size, it is one of strategy.
The focus bifurcates into “core platform” development and “new use case” development, driven by multiple customer use cases. What are these new use cases? They’re actually verticalization into adjacent problems. Ideally, they are adjacencies to the original use of the product – either the same problems need solving in a new domain, or closely related problems need solving in the same domain.
Stage 3 product management organizations support the healthy verticalization of the product by introducing a new role type: the principal product manager.
(As an aside, deciding how to divide and describe these adjacencies so that they are recognizable to people outside the company – and to the revenue marketing team inside the company! – is what a good VP of Product should be prioritizing over all else.)
Stage 3 product management organizations support the healthy verticalization of the product by introducing a new role type: the principal product manager. A principal product manager is responsible for a market segment – a use case, user persona, industry or vertical – and unlike other product managers, isn’t assigned to a specific engineering squad (this will change later, in even larger organizations)
Notably, this is where the PRD emerges as a useful artifact in the product process – up until this stage, PRDs (if used at all) are a thin wrapper around a set of requirement summaries. But at this stage, the PRD is the primary tool of a principal product manager when making the business case for an investment, and is often leveraged by marketing organizations to develop their messaging and GTM strategy.
The VP of Product in a Stage 3 organization is responsible for bifurcating the team into two groups – platform product managers directly partnered with engineering squads and responsible for functional requirement management; and principal product managers, who own use cases and work with multiple platform product managers to get their use case requirements incorporated into the product. (The majority of the team is on the platform side – if you have more than two or three principal product managers, you’re either slicing too fine or you’re over-ambitious about how many markets you can serve at once.)
This strategy has several benefits. First, it encourages efficient development, because use case requirements get routed through platform teams, who can consolidate requests and manage to an architectural plan, as well as push back on requirements that are too far afield from the product’s core technical competencies.
Second, it introduces the idea of managing a roadmap through the lens of addressable markets and business priority – a critical maturity that is hard to enforce when product is operating exclusively at the granularity of individual feature requests. And since part of the product organization is dedicated to the platform, there are clear lanes for technology investments that aren’t tied to specific business cases, which helps when the organization hasn’t fully developed its resource allocation strategies.
Third, it sets the stage for dual-track career ladders (which will be critical in future stages) by creating roles for highly skilled ICs as well as for people managers.
The VP of Product is responsible for making this new organizational structure work smoothly, and is also responsible for formalizing the relationships with other organizations in the company – with marketing, customer success, sales and operations, so that those principal product managers and their use cases are surfaced by the go-to-market organization, and that the use cases as prioritized by the product marketing organization are being developed efficiently by the core platform team.
Successful Stage 3 organizations exhibit balanced development and stable roadmaps. Stage 3 organizations that are still struggling often exhibit symptoms including roadmaps that change significantly from quarter to quarter, half-developed use cases that never get to viability, technical solutions being used to invent customer problems, and internecine battles between senior engineers and product managers over the direction of product development.
Stage 3 organizations can handle a maximum of 9 product managers on the core team, and 3 principle product managers – the scale is limited by the personal bandwidth of the VP of Product, and managing twelve skilled directs is pushing the limit of any people manager. As the development team continues to scale up, we’ll see the arrival of the CPO as we move into Stage 4.
Stage 4 – Chief Product Officer, twelve to N product managers
Stage 4 is marked by sophisticated organizational growth and the formalization of the product management voice in the executive staff. The Chief Product Officer (CPO) role emerges, distinct from the VP of Product. The CPO leads an organization of leaders, sets priorities, and manages through staff command rather than operational execution.
The natural growth into stage 4 can be marked by size. But it’s important to recognize that the exit from stage 3 isn’t just “I hired a bunch of product managers, therefore i’m now stage 4” – it’s that the VP has established the organizational maturity to have principal product managers driving verticals or use cases, and core platform product managers organizing, prioritizing, and facilitating the requirements coming in from the principal product managers along with all other investments in the core platform.
Organizationally, Stage 4 involves increasing the number of core platform product managers and principal product managers, and adding management scaffolding as needed to handle scale. The CPO maintains a manageable number of direct reports as operational staff, ensuring effective decision-making and supporting healthy organizational growth.
Among the core platform product managers you’ll have the immediate need for a VP of Product as well as group managers, and over time multiple directors, to manage a burgeoning team of PMs that are increasingly specialized as engineering squads propagate and reorganize. Some product managers will want to reach for that people-management brass ring (and you’ll hire in some experienced middle managers as well) while others will excel as individual contributors and aspire to a principal role.
Over time, your use cases will become sophisticated enough that a single principal product manager doesn’t have the bandwidth to handle it alone, and will turn into small teams of vertical-specific product managers. (Avoid the impulse to build deep hierarchies on this side of the team, however – principal teams shouldn’t need multiple layers of management).
The CPO focuses on strategic direction, balancing the needs of the market, and providing external thought leadership and product evangelism.
CPOs are not directly involved in data gathering, market research and requirements development – those functions are exclusively the domain of your product management staff, primarily your principal product managers and organizational middle managers. The CPO isn’t going to come up with the new features for the roadmap – they set the direction for the product, and apply their experience and perspective to what’s being proposed by the team. Your CPO is the arbiter of new proposals and approver of strategic plans, and is the executive accountable to the CEO for the success of the product itself.
For the leadership team, a CPO is a big shift as well. Up until now, product has been a function of engineering or of marketing, but we’re going to make it a distinct entity now in the C-suite. The CPO ensures a healthy balance between the CMO, CTO, and product management.
The CPO as a member of the executive staff is a counterbalance to your CMO, ensuring that the message doesn’t run too far ahead of – or too far off from – the product. And a counterbalance to the CTO or VP Engineering, representing the voice of the market against the priorities of the engineering team. This healthy tripartite tension between CMO, CPO and CTO is essential for effective product development, and at this scale requires a dedicated C-level voice for product.
A CPO leads an organization of leaders, provides resources and sets priorities for that organization
Importantly, a CPO plays a critical role that up to this point was likely filled by your founders, or to some extent your VP of Product – external thought leadership in your market and evangelism of your product vision. A CPO tells the product story, the company story, and the market story to audiences that may never see one of your product managers.
In Stage 4 organizations, the PRD becomes a sophisticated business case tool as well as a robust narrative about the product vision and target user personas. Principal product managers vie for resources and funding using their PRDs, and both customer data and market projections are important elements of prioritization exercises.
Theoretically, Stage 4 could be the last stop in development – it can be scaled indefinitely without structural problems. But at some point, the company is going to end up with multiple products or product lines and disparate routes to market, which leads us to yet another design: Product line matrix management.
Stage 5 – The Matrix
Organizations that, if you step back and squint, really build one thing (no matter how complex) are perfect candidates to stay in Stage 4 indefinitely – the product organization just grows and fans out, in lockstep with the rest of the company. But verticalization and adjacencies (as well as acquisitions) often spawn new solutions that are truly standalone, and benefit from dedicated resource pools and prioritization (and parallel GTM organizations).
This fragmentation leads to product portfolios, which often benefit from solution product leadership (a higher-level grouping that can have a one-to-many relationship between solution segment and product segments), replicating the principal-product-manager-to-core-product-managers relationship, where a principal solution manager advocates for requirements across a set of principal product managers, forming a matrix.
Stage 5 is for organizations with multiple products or product lines. Product portfolios benefit from solution product leadership, creating a matrix structure. This structure supports vertical-specific product managers and core platform product managers, ensuring efficient development and clear prioritization.
The CPO’s organization often includes multiple layers of leadership, with each layer focusing on different aspects of product development and market requirements.
And segmentation of customers into verticals or size segments with discrete routes to market often have unique segment needs. Consider, as an example, the suite of products in Adobe’s Creative Cloud.
Enterprise customers have some requirements that SMBs simply don’t – identity management, on-premise clouds, external procurement organizations, etc. And while SMBs are much easier to support via self-service, a Fortune 500 will expect personalized treatment at all stages of a sale or renewal.
Adobe could try to ensure that the product management team for Photoshop understands the requirements of both of these segments – and shares that understanding of how to solve for them with the organizationally-distinct Premiere Pro team. (Not a small effort, when each product represents a small company’s worth of resources!)
Alternatively, they could create a product management team that develops enterprise-specific requirements and drives those requirements into both Photoshop and Premiere Pro. And they may build a mirror team for SMB customers, and put both to work driving distinct route-to-market requirements with each Adobe product organization (N.B. I once managed exactly these two product management teams at Adobe). This strategy is matrix management as applied to product portfolios.
Stage 5 organizations must handle matrix structures while facilitating career progression. The CPO’s organization often includes multiple layers of leadership, with each layer focusing on different aspects of product development and market requirements.
In Stage 5 organizations It is not uncommon to see multiple VP of Product roles under a CPO, or even multiple CPO roles aligned to business units in an enterprise organization. And matrices afford opportunities to co-mingle traditional product roles with product marketing and business analyst responsibilities, leading to areas of the product organization focused more on GTM strategy than product development.
A key note here, and the way this model becomes recursive : Stage 5 organizations routinely incubate (or acquire) Stage 0 organizations. These ‘startup-in-an-enterprise’ organizations progress through this model on their own until they are either absorbed back into the parent, or in some cases, outcompete and replace the parent, becoming Stage 4 or 5 organizations themselves.
To review, our organizational model describes six distinct stages of product management team development:
Stage 0: Early-stage organizations are typically led by a founder with a clear vision but limited market understanding. The initial product manager, often a domain expert or an engaged customer, collaborates closely with engineering, focusing on organizing and prioritizing work through backlogs and user stories.
Stage 1: As organizations grow, they refine their core product and sales-led feature development. Additional product managers are hired to handle increased workloads. The founder remains involved, but formal product management training is often outsourced. Product managers start interacting more with sales and marketing, while continuing to use backlogs and requirement summaries for planning.
Stage 2: In this stage, a VP of Product is introduced to manage product vision and formalize the product management structure. This role includes creating roadmaps, defining team boundaries, and establishing processes for product releases. The VP focuses on transforming product management into a cohesive team, setting standards, and preparing for further growth.
Stage 3: The VP’s role evolves to include organizational leadership, focusing on core platform development and new use cases. Principal Product Managers are introduced to oversee market segments. PRDs become essential for making business cases. The VP bifurcates the team into platform and principal product managers, balancing efficient development with market-driven priorities.
Stage 4: The Chief Product Officer (CPO) role emerges, leading an organization of leaders and setting strategic direction. The CPO focuses on external thought leadership and product evangelism, balancing the needs of the market and ensuring effective product development. The organizational structure expands, with a clear distinction between platform and principal product managers.
Stage 5: Organizations with multiple products or product lines adopt a matrix structure, benefiting from solution product leadership. This structure supports vertical-specific and core platform product managers, ensuring efficient development and prioritization. Multiple VP of Product roles and potential CPO roles align with business units, integrating traditional product roles with product marketing and business analyst responsibilities.
This model provides a roadmap for companies to scale their product management functions effectively. By understanding and implementing these stages of organizational design, companies can effectively scale their product management functions and achieve sustained growth and market success.
Does this match your experience? I’d love to hear how your organization is different, leave a comment below!
Reality-Based Product Management 