Does winning your next customer feel harder, when R&D ought to be making it easier?  If you’re like many startups, the root cause is your sales-led product development.

Being sales-led is a necessary step in the evolution of your business. You’ve burned through seed capital, proven the core technology works, and gained happy customers paying real money for value – but every win seems to come at the cost of “just a few little feature commitments…”

During early stages of growth, it’s common and even advisable to prioritize immediate customer needs over long-term product strategy. The focus is necessarily on landing the next logo, even if that means deferring your strategic vision – and let’s be honest, you aren’t totally clear yet about what your market actually looks like.

Plus, you need the feedback (not to mention the revenue!) – and without the crucible of actual customer implementations, that strategic roadmap is just a theory.

However, when this sales-driven mindset persists for too long, product/market fit gets further away, not closer. Building out your capabilities and compatibilities in the order your prospects arrived won’t help you be a better fit for the broader market – and when sales-driven feature work represents the majority of your engineering effort, your product risks becoming blurry and incoherent.

For example, imagine you’ve built a product that queries relational databases. You can reach a lot of the market just by supporting postgres and MySQL, and most of the rest of it by supporting SQL server. A massive enterprise wants to become a customer, but they’re running Qbole. You’ll support Qbole for them, right? How hard can it be?

Suddenly, you’ve backed into supporting Hive, but your only test environment is this one customer – so your coverage is spotty, your documentation is full of exceptions, and you’re constantly worrying that your customer will upgrade and break your fragile integration. Oh, and now your account execs tell prospects “Of course we support Qbole!” and your sales engineers keep making that face, you know the one.

A little later, your query product is getting further into the business side and a prospect asks if you can do more than query data – can you write changes back to the database? That would be really convenient for this one operational use case they’ve got, where sales can correct deal forecasts in-situ. Sure, this breaks a core tenet of analytics systems (modifying data outside the transactional system) but it would open up a new use case – do you want to go there? Will you have to, in order to land this client? How much support are you going to put into this new product direction?

The examples are endless. If you’ve been in product for any length of time, you have your own story you’re thinking of right now. In aggregate, here’s what typically happens:

1. Inconsistent Feature Maturity: Some features are highly robust, capable of handling a variety of scenarios, while others remain shallow, lacking the depth of support expected by users.

2. Limited Use Case Portability: Features built for specific customers don’t work reliably in other scenarios, or aren’t relevant to the majority of new prospects, making qualification harder and cases studies less impactful.

3. Pre-Sales Challenges: Your pre-sales engineers struggle to show the product can support the needs of new prospects, or constantly hack around shortcomings in POCs. The features you developed in response to customer requests add to the complexity of your product but provide little competitive value or differentiation.

4. Technical Debt and Architectural Weaknesses: Least-cost feature implementations often lead to negative architectural tradeoffs, resulting in inter-module dependencies and technical debt. Over time, this slows down development velocity and blocks innovation.

5. Market Confusion: As your product becomes a patchwork of features with no clear overarching vision, your go-to-market teams will find it increasingly difficult to articulate who should use your product, what problems it solves, or what use cases it excels at.

6. Sales Bottlenecks: Your sales velocity is constrained by your engineering team’s capacity to develop new features. You will find yourself unable to close more deals simply because you lack the resources to meet the feature demands of new prospects.

7. Diminishing Return on Equity: As too much of your R&D budget is spent on serving the narrow needs of a few customers, your business begins to resemble a professional services shop rather than an independent software vendor. This erodes return on equity and stunts growth.

The Cure: Transitioning to Market-Driven Thinking

To avoid these pitfalls, a shift towards market-driven thinking is essential. Here’s how to do it:

Focus on Market Segmentation: For each new feature or capability, consider what other customers you could land with the same implementation. Assess whether this segment is addressable by your current technology and go-to-market team before proceeding.

Develop a Differentiation Thesis: Create a clear thesis on why a prospect should choose your product over building a solution themselves or opting for a competitor. Identify your core competencies and competitive differentiators, and build features that leverage and enhance these strengths.

Demand a Business Case for New Investments: Insist on a thorough business case from your product managers for each new product investment. Determine who will buy it, how you will market it, and whether it will attract new customers or expand existing ones. Incorporate both go-to-market (GTM) and technical reviews in your evaluation process.

Practice Saying ‘No’ to Feature Requests: Feature requests tied to specific deals should be the exception, not the rule. This is crucial whether you’re selling to SMBs, midmarket, or enterprise customers. If every deal requires new development work, it becomes impossible to maintain, let alone improve, your margins while scaling.

Allocate Limited Resources for Deal-Driven Work: Reserve no more than 10% of your development resources for customer-driven features, and assign a dedicated team to this category of work. This allows you to accommodate some customer-specific needs without derailing your overall product strategy. Ensure that the scope of these projects remains limited to prevent a single customer dominating this pipeline.

Separate Product Management from Engineering: In sales-driven companies, product management often reports to Eng leadership, and serves primarily as an intermediary between customers and developers. However, for market analysis and product vision to thrive, product management must be independent of engineering leadership, so that the natural tension between a market vision and a technical vision can lead to an efficient product.

Eliminate One-Off Features and Transition Oddball Customers: Where possible, shut down one-off features or use cases that were developed to secure early deals but have little appeal in the broader market. This may not be feasible for capabilities used by actively growing customers, but reducing unnecessary complexity will streamline your product. And wherever possible, help poor-fit or off-strategy customers transition to other solutions, as their revenue rarely makes up for the opportunity cost of servicing their needs.

Indicators of a Successful Transition

As you shift from sales-driven to market-driven thinking, several positive changes should become apparent:

Increased Customer Independence: A growing number of new customers successfully implement your solution with minimal need for new features or extensive technical support.

Organic Lead Generation: New business wins with prospects that came inbound, rather than in response to outbound sales activities.

Homogeneous Customer Profiles: Your prospects increasingly resemble each other, sharing similar architectures, platforms, technologies, and challenges.

Improved Roadmap Execution: You’ll deliver more of your strategic product roadmap on time, with fewer disruptions to your backlog.

Clearer Value Proposition: The problems your product solves become increasingly obvious and clear, making it easier to communicate your value proposition to potential customers.

Strategic Sales Conversations: Your sales team spends more time discussing the business impact of your solution with decision-makers, and less time delving into technical details with implementation teams. Sales engineers can service more accounts at a time, and focus primarily on big, high-value deals.

Timing is Everything

Timing your transition from a sales-driven to a market-driven approach is critical for the healthy growth of B2B products. Shift too early, and you risk building features without sufficient customer feedback. Wait too long, and your product will morph into a disjointed, incoherent platform. However, with the right timing, you can capitalize on early successes and propel your product toward a strong product-market fit, ensuring long-term success and scalability.

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!