The Product Team Playbook: How To Build and Scale High-Performing Product Teams

Introduction

Over the past 15 years, I’ve had the privilege of building and scaling product teams three times across three different companies. These experiences provided an incredible learning journey, allowing me to delve into even the most nuanced aspects of team creation and scaling.

In my most recent role, I spent eight years at Toptal as the SVP of Product, where I built and scaled a world-class product team comprising over 30 talented product managers and UX researchers. I’m proud to say this team stood on par with those of the world’s leading tech companies, not only in the exceptional caliber of its people but also in the strength of its product practices, processes, and product culture.

With so much experience and countless lessons learned, I decided it was time to reflect and consolidate these insights into a comprehensive playbook. My goal is to help founders, product leaders, and product managers build and scale high-performing teams that drive meaningful impact. One of the most important lessons I learned during my tenure at Toptal, and something that many highly successful leaders do, is to systematically process their experiences and convert them into principles and playbooks. This approach not only allows for repeatable success but also ensures continuous improvement. The key is to revisit and refine the playbook every time it is applied, incorporating new insights and lessons. By doing so, each new implementation builds on the foundation of previous successes, driving constant growth and evolution.

While I aspire to eventually turn this playbook into a comprehensive book, my initial plan is to write a series of articles covering its key components in depth. This first article serves as a sneak preview, providing an overview of the playbook and outlining the essential considerations for building a product team. Given the depth and breadth of these topics, this article will remain high-level, offering an initial understanding of what needs to be done. In future articles, we’ll dive deeper into implementation details, sharing actionable insights and practical guidance to help bring these concepts to life.

What this playbook is about

This playbook is designed for Founders looking to build their product function and Product Leaders aiming to scale their teams. It delves into the key ingredients that make up a successful product team and provides practical advice on how to approach each of them.

My playbook consists of two fundamental parts.

The first part, Assessment involves conducting an in-depth analysis of the company. This step is crucial to understanding the organization’s capabilities and determining the best role for the product team. Unlike other disciplines that are often standardized, product teams vary significantly. Over the years, I’ve learned that these variations are shaped by the organization’s structure, strategy, and the capabilities of its people.The outcome of this analytical phase is to make key decisions about what the product team needs to achieve, what its role should be, and how it fits into the overall organization.

Once this foundational exercise is complete, we move on to the second part: implementation. This phase focuses on building or scaling the team and encompasses the classic pillars of people, processes, and tools.

How this playbook is different

While many books and articles cover aspects of product management — such as strategy, great product management practices, or building successful products — very few focus exclusively on the challenges of building and scaling a product team from scratch. This playbook fills that gap.

What makes it different? First, it takes a holistic approach, bringing together all the essential elements of building and scaling a product team in one place. Second, it goes beyond theory, sharing real-world lessons from my 15 years of experience — what worked, what didn’t, and how to apply these insights in practice.

Unlike rigid frameworks or blueprints, this playbook acknowledges that while the foundational building blocks of a product team are standard, their implementation varies widely depending on the organization. Instead of offering a one-size-fits-all approach, it helps Product Leaders understand the key components, their purpose, and how to adapt them to their unique environment.

Ultimately, this is a practical guide — designed for Founders and Product Leaders who are ready to take action, not just consume theory. Without a well-structured and effectively scaled product team, even the best ideas, strategies, or PMs won’t reach their full potential. This playbook ensures you don’t overlook the most critical part of building great products — the team behind them.

Part 1: Assessment

Update: You can read the entire chapter here

Before building or scaling a product team, it’s essential to step back and define its role within the organization. This involves four key areas:

1. Purpose of the team — Aligning with the CEO and key executives to understand their expectations. Without this alignment, you risk building a team that doesn’t serve the company’s needs.
2. Organizational structure — Determining where the product team fits within the broader company structure and how it interacts with other functions.
3. Product collaborators — Identifying the key stakeholders and teams (engineering, design, marketing, sales, etc.) that the product team will work with and depend on.
4. Principles & values — Understanding the company’s product philosophy, decision-making culture, and constraints within which the team will operate.

By defining these elements upfront, you can ensure that the product team is well-positioned to integrate seamlessly into the organization and deliver meaningful impact.

Product Team’s Role

The first step in the assessment phase is defining the product team’s role within the organization. This decision is critical, shaping the team’s structure, the type of product managers you need to hire, and influencing nearly every aspect of this playbook.

To begin, you must determine who truly drives the business and strategy. In some companies, the product function takes the lead, with the Head of Product owning the product strategy and even shaping the company’s broader strategic direction. In others, strategy is driven by sales, marketing, or operations, with those leaders not only setting the business strategy but also dictating the product strategy and roadmap.

Equally important is understanding the Founder, CEO, or key executives’ level of involvement in product decisions. Many Founders remain hands-on with product strategy even after hiring a Head of Product, while other key executives may also exert significant influence, shaping the product team’s role.

While the concept of an “empowered product team” where PMs act as the “CEO of the product” is widely promoted, in reality, this approach often clashes with how Founders and Business Leaders operate. As a product leader, aligning with the company’s expectations for the product function is essential. Broadly, product teams fall into three categories:

• Strategy Driver: The product leader plays a pivotal role in shaping the company’s strategy, defining key business opportunities and how they translate into product priorities.
• Problem Solver: The business identifies the key problems and opportunities, but the product team has full autonomy to determine and implement the best solutions.
• Builder: The business not only defines the product strategy but also prescribes specific solutions, with the product team focused primarily on execution.

Each model requires a different team structure and skill set, influenced by factors such as the Founder or CEO’s leadership style, company’ maturity, and organizational dynamics. Thoughtfully assessing these factors ensures that the product team’s role aligns with the company’s needs, enabling effective collaboration and maximum impact.

Organization’s Structure and Evolution

Understanding the current structure of the organization is a crucial step in building or scaling a product team. Even in organizations where a product team doesn’t exist or is very small, the responsibilities of product management are still being fulfilled — often by individuals in other roles. It’s important to view product management not merely as a title but as a set of responsibilities that can be distributed across various people.

As part of your assessment, you need to map out these responsibilities and identify who is currently carrying them out. Assess how well they are performing, what skills and weaknesses they have, and what problems exist. These responsibilities typically include:

• Defining strategy
• Creating business cases
• Writing specifications or creating designs
• Project management
• Collaborating with engineering
• Conducting UX research
• Performing business analysis
• Monitoring impact
• Ensuring communication and alignment

Another critical aspect is understanding the history of the organization and how it evolved into its current state. While the present structure might look similar across different companies, the path that led there can make a significant difference. For instance, a company that has had a product manager since Day 1, resulting in a five-person product team, is very different from one that hired its first five PMs in the last six months.

To get a clear picture, you need to trace the evolution of product management responsibilities over time. Understand how these responsibilities were distributed in the past, what challenges the organization faced, and what led to the current setup. This insight not only provides a sense of the product team’s maturity but also reveals the dynamics and readiness of other functions to collaborate effectively with the product function.

Key Product Collaborators

Another critical step in assessing the organization is evaluating its capabilities for collaborating with the product team. The two main categories of collaborators are Stakeholders and Builders.

• Stakeholders include senior leaders from other functions and the CEO. They work with product managers to align on problems that need solving or to propose solutions.
• Builders include engineers, designers, business analysts, project managers, and UX researchers. These teams work with product managers to implement the agreed-upon solutions.

Understanding how these teams are structured and their capabilities is essential, as they directly influence the role of product managers and the skills they need to succeed. For instance, if engineering managers are product-minded and capable of writing technical specifications or making key decisions, product managers can operate at a higher strategic level. However, if engineering managers focus primarily on people management, the organization may require a different structure or type of product manager to ensure high-quality specifications are delivered.

Similarly, the presence and strength of business analysts (BAs) vary widely across organizations. In companies with strong BA teams, product managers can rely on them for tasks like querying databases and analyzing data. However, in most organizations, strong BA teams are not the norm. This often means that product managers need to be self-sufficient, capable of performing these tasks themselves to ensure decisions are informed by accurate data.

When it comes to stakeholders, their level of product maturity is another key consideration. Product-minded stakeholders often engage with product teams at the problem level, providing clear success criteria and leaving room for product managers to innovate. Conversely, less mature stakeholders may operate primarily in the solution space, dictating specific actions and treating product managers as backlog administrators.

Other factors, such as the number of stakeholders and the size of the organization, also play a significant role. Larger organizations with numerous stakeholders require product managers who excel in communication and project management to navigate complex dynamics and ensure alignment across teams.

Company’s Product Principles

It may seem like a cliché, but understanding the values, principles, and vision of the company is foundational when building a product team. Beyond this, however, it’s equally critical to understand the specific values related to product management. What does the Founder, CEO, or other key executives prioritize when it comes to product development? These principles significantly shape the role of the product team, the types of individuals you hire, and the processes you establish.

While there are countless factors to consider, I’ll outline a few key examples:

1. MVP vs. Perfection: Founders often have differing preferences regarding product delivery. Some want to move fast, iterate, and release MVPs (Minimum Viable Products) to test and learn quickly. Others prioritize shipping only when the product is polished or meets exceptionally high standards.
2. Data-Driven vs. Intuition-Led Decision Making: Some founders rely heavily on data to make decisions, while others trust their intuition. A misalignment here can lead to conflict. For instance, a product team that emphasizes data-driven decision-making may gravitate toward A/B testing or in-depth analysis, while a more intuition-led founder might push for decisions based on personal judgment or vision. This dichotomy has implications for the PMs you hire, the expectations you set, and whether you need to invest in building a robust UX research or business analysis function to support decision-making.
3. Short-Term vs. Long-Term Focus: Some founders prioritize taking small, iterative steps, responding directly to user feedback, and focusing on immediate needs. Others think big, preferring to invest heavily in building scalable infrastructure before addressing more immediate concerns.
4. Autonomy vs. Control: Founders also differ in how they manage their teams. Some give their teams significant autonomy, focusing on outcomes and trusting their expertise. Others prefer to be deeply involved in execution, which may require PMs who are comfortable working as POs (Product Owners) and who excel at communication and collaboration.

These are just a few examples, but the list is extensive. It’s essential to use a structured framework to thoroughly map the product values and principles of the Founder, CEO, and organization. This understanding will guide you in hiring the right people, setting the appropriate expectations, and designing processes that align with the company’s unique culture and strategic direction.

Part 2: Implementation

After completing your assessment and gaining a comprehensive understanding of the organization, you’ll be equipped to determine the optimal structure, processes, and people for your product team, as well as how it should integrate into the overall organization. With this clarity, you are ready to move into the execution phase, which involves creating or scaling the team. To do so effectively, you need to focus in three areas: people, processes and tools with people being the largest one.

People

Alignment with the CEO & Executives

One of the most crucial steps before building or scaling a product team is achieving alignment with the Founder, CEO, and other key executives. This involves understanding and agreeing on their expectations for the product team, the operating model, and how the team will integrate and collaborate with the rest of the organization.

This alignment should be seen as a “contract” between you and the CEO — not just in terms of goals (e.g., OKRs), but also in how the product team will operate and interact within the organization. A common mistake many Heads of Product make is focusing solely on aligning goals, usually in the form of OKRs. While this approach clarifies what you need to achieve, it often neglects how the product team will function and collaborate across the company.

Since the product team doesn’t operate in a vacuum, clarity on the operating model is critical. It directly impacts how the team collaborates with other functions and even shapes the OKR process. For example, if the CEO expects the product team to operate in a “builder” mode — executing top-down solutions from other teams — while the product team anticipates working in a “strategy driver” or “problem solver” mode, this misalignment can lead to friction, frustration, misalignment, and ultimately poor outcomes. Ensuring early alignment on the product team’s role and decision-making authority is crucial for fostering collaboration, maintaining motivation, and driving meaningful impact.

Another example of misalignment is when the product team expects to launch new features and evaluate them based on A/B testing or usability testing, while the CEO insists on personally reviewing and approving everything before it goes live, imposing their own feedback. This creates a fundamental mismatch in expectations — one approach prioritizes building what users want based on data, while the other centers around executing the CEO’s vision and preferences. Without early alignment on decision-making processes, this can lead to delays, frustration, and ineffective product development.

This will save everyone from tremendous frustration and friction and, ultimately, help prevent poor outcomes — such as significant delays, endless iterations, and reworking features multiple times — that arise when expectations and ways of working are not clearly defined from the start.

Defining Product Team Values

While the company as a whole has its own set of values, it’s essential to translate these into specific values for the product team — or even introduce additional values tailored to the team’s unique responsibilities. Company values are designed to apply broadly across diverse disciplines and functions, so they tend to be higher-level. At the product team level, however, you can and should be more specific.

These values should be clearly articulated, written down, and deeply ingrained in the team’s culture. It’s not enough to simply define and publish them on an internal website. You must deliberately and consistently communicate these values until they become second nature — something the team understands, lives by, and actively embraces. It’s the Product Leader’s responsibility to exemplify these values every day, alongside their leadership team.

For example, in one of my previous roles, being data-driven was a core product team value, ensuring that every decision was backed by rigorous analysis. To reinforce this, the leadership team and I led by example — Directors of Product, and even I as the team leader, frequently worked alongside PMs to write database queries and analyze data. This hands-on approach not only demonstrated our commitment to data-driven decision-making but also deeply ingrained it into the team’s culture and daily practices.

Building Product Team Culture

Team culture consists of two key components: team bonding, which focuses on fostering relationships and creating a sense of belonging, and embracing team values, ensuring that team members internalize and actively live by the team’s core principles. Both require deliberate effort — simply relying on organic interactions won’t maximize their impact. As a leader, you should proactively design bonding activities that align with both the personalities of your team members and the overall company culture. While some bonding will naturally occur, adding structure and intentionality enhances the experience. This becomes even more important in remote teams, where organic interactions like water cooler conversations are limited, and thoughtfully planned activities help create stronger connections despite the physical distance. Similarly, reinforcing team values requires intentional cultural initiatives. If, for example, one of your values is for team members to stay up to date with the latest technologies, you might introduce structured knowledge exchange meetups or book discussions on industry trends. By designing activities that reinforce both bonding and values, you create a strong, cohesive team culture that drives engagement and alignment.

Structuring the Product Team

The design of your product team’s structure is one of the most critical steps in the process and can make a significant difference in the team’s effectiveness. While there are many factors to consider — topics that will be explored in future articles — the key takeaway is this: your structure must align with both the goals you’ve been tasked to achieve and the operating model agreed upon with the CEO and Executive Team.

Here are some considerations for structuring your team:

1. Mission-Based Teams: These teams are assigned a broad, complex problem and are empowered to solve it, often crossing multiple domains. This approach fosters ownership, innovation, and end-to-end accountability.
2. Domain-Specific Teams: These teams own specific parts of the product, such as signup or activation. This structure allows for deep expertise and focus within a particular area, making it easier to optimize and maintain.
3. Initiative/Feature-Based Teams: These teams are formed to work on a specific initiative or feature. Once the initiative is complete, the team is dissolved or restructured. This approach provides flexibility and agility but can lead to a lack of continuity or ownership.

Each approach has its pros and cons, and many organizations adopt a hybrid model tailored to their unique needs. Your decision should be based on the outcomes of your assessment and the specific requirements of your organization.

As your product team grows, you’ll also need to group teams into larger structures. This grouping is critical, as it can unintentionally create silos within the product organization.

Another important consideration is how the product team’s structure aligns with other functions. For example, the product team’s organization often depends on the structure of the engineering team or how business functions are arranged. A misalignment here can lead to inefficiencies or unnecessary friction.

Finally, remember that your team’s structure is not static. It must evolve over time as the company grows, its priorities shift, and its needs change. Designing with flexibility in mind will ensure the team remains adaptable and effective as the organization scales.

Defining Product Team Roles & Responsibilities

After defining your structure, you also need to consider the roles required within your product team. Depending on the organization’s setup, a product team may include a variety of roles. Here are some of the most common:

• Product Managers:
• Analysts: This could include data analysts, product analysts, or business analysts. Clearly define expectations for these roles to ensure alignment with team goals.
• Designers: Essential for creating intuitive and visually appealing products.
• UX Researchers: The need for this role depends on the diagnosis phase and the CEO’s expectations for the product team.
• Product Operations: A relatively new but increasingly popular role in product management, worth considering for improving efficiency and operational alignment.
• Program/Project Managers: Useful for managing timelines, resources, and cross-functional coordination.

For each role, as discussed further in the Competencies chapter, it’s helpful to define a set of competencies required to perform effectively and map these competencies to different seniority levels. This approach ensures clarity in titles and responsibilities and provides a structured framework for hiring, evaluation, and development.

For example, when defining roles for product managers, it’s important to establish clear role descriptions for each level. A typical progression includes Associate PM, PM, Senior PM, and Principal or Staff PM for individual contributors. On the leadership track, titles range from Associate Director of Product to Director, Senior Director, and VP of Product. It’s crucial to avoid title inflation and ensure each level has distinct responsibilities and expectations.

Once roles and responsibilities are defined, determine how to staff your team and how many people are needed for each role. It’s also advisable to create a timeline for staffing to understand how the team’s composition will evolve over time, enabling you to plan effectively and align with organizational growth.

Establishing a Competency Framework

As I mentioned in the previous section, for each role in your team, you need to define a set of competencies that individuals must possess to perform effectively. These competencies outline the responsibilities of the role and provide a clear definition of what good performance looks like.

A straightforward way to approach this is by starting with broader competency categories. For Product Managers, for example, you might use categories like Product Execution, Product Strategy, User Insights, and Influencing People. Each category can then be broken down into specific attributes / competencies.

Next, define the levels of the role, such as Associate PM, PM, Senior PM, and Principal PM. Then create a matrix with competencies as rows and levels as columns, and describe in each cell what is expected for each competency at each level.

This approach has several benefits:

• Team Staffing: It helps you determine how to staff your team and how many people you need for each role.
• Career Progression and Development: It provides a framework for career progression and professional development discussions.
• Performance Management: It sets clear expectations for everyone, defining what is considered good or poor performance.
• Recruiting: It serves as an input for your recruiting process, guiding how you evaluate candidates.

The exact categories, competencies, and their mapping to levels will depend on the outcomes of the assessment phase and the specific expectations from the product team. This tailored approach ensures that your framework aligns with the unique needs of your organization.

Recruiting and Hiring the Right Talent

Hiring the right people is the cornerstone of your product team’s success. Based on your organizational assessment, you should map out the specific skills and traits your product managers (PMs) need to have, and then design an interview process to evaluate these effectively. A robust interview process includes clear evaluation rubrics for each assessed area, ensuring objectivity and scalability.

While hard skills such as problem-solving, discovery, specification writing, and UX are important, evaluating soft skills, character, and personal traits is equally — if not more — crucial. Many interview processes focus heavily on technical skills but often overlook cultural fit. In my experience, cultural alignment is a significant predictor of success, especially in startups where traits like resilience, adaptability, and a growth mindset are critical for a PM to thrive. Even brilliant PMs can fail to meet their potential if they are not a good fit for the organization’s culture.

Once you’ve developed the interview process — including scripts, instructions, exercises, and assessments — you need to identify and train your interviewers. After interviews begin, establish a feedback process to calibrate their ratings and ensure consistency. Regularly compare hired candidates’ real-world performance with expectations, and adjust the interview process accordingly. For example, if you notice PMs excelling in some areas but underperforming in others, refine your process to better identify the right balance of skills and traits. Constant measurement and iteration are key to improving your hiring outcomes.

Some additional considerations include

1. Set Proper Expectations: One unique aspect of recruiting for product management is the variability of the role across organizations. Train your interviewers to clearly and truthfully communicate what it means to work in your organization. This helps set proper expectations for candidates, ensuring not only that they meet your criteria but also that they’ll be happy working in your environment.
2. Sourcing: When sourcing candidates, define precise criteria for the ideal hire, determine when to initiate outreach, and develop a strategy for engaging with potential candidates.
3. Selling the Role: In today’s competitive talent market, it’s essential to sell the opportunity. Train your interviewers to pitch the role and inspire candidates to join, emphasizing the unique aspects of your organization and team.
4. Diversity: Beyond legal requirements, strive to build a diverse product team in terms of skills, perspectives, and working styles. A team composed entirely of one type — such as highly analytical “right-brain” thinkers — may struggle with creative initiatives. Aim for complementary team dynamics to address a broader range of challenges effectively.
5. Plan for the Future: Recruiting should address not only current needs but also the future growth of your organization. Consider whether the candidates you hire today will be able to scale with your company and meet its evolving needs.

Recruiting is a vital process that must be approached systematically and scientifically. While there’s much more to explore, these principles provide a strong foundation. Future articles will dive deeper into the nuances of product management hiring to help you build a world-class team.

Associate Product Manager Program

As part of your recruiting strategy, consider developing an Associate Product Manager (APM) program to train high-potential individuals who are not yet PMs. Product management is unique in that it isn’t typically studied as a formal discipline like engineering or computer science — most PMs transition from adjacent fields and learn on the job.

An APM program can serve as a structured talent pipeline, allowing you to develop future product leaders while ensuring alignment with your company’s values and processes. This approach expands your hiring pool, fosters a self-grown team, and reduces reliance on external hires. By investing in early-career talent, you accelerate the development of strong product managers and build a team with deep organizational knowledge from the ground up.

Onboarding Product Managers

As your organization grows, designing and implementing an effective onboarding process for product managers becomes increasingly critical. A well-structured onboarding plan ensures that new hires get up to speed quickly, with minimal effort required from existing team members. This efficiency becomes even more important as your team scales.

Here are some key considerations for creating a comprehensive onboarding plan:

• Pre-joining preparation: Provide resources that new hires can review before their start date to familiarize themselves with the company, product, and team.
• Company culture and expectations: Introduce the company’s culture, values, and expectations, helping new hires understand the organizational dynamics and what it takes to thrive in the role.
• Tools: Offer training or documentation on the tools the team uses, such as project management software, communication platforms, and analytics tools.
• Processes: Clearly outline the team’s processes, from roadmap planning to sprint cycles, so new hires can quickly integrate into the workflow.
• Key people: Identify the people the new hire will be working with regularly and those they should meet during onboarding. Provide guidance on what they should aim to learn from these interactions.
• Role expectations and evaluation: Set clear expectations about the role, including responsibilities, priorities, and how performance will be evaluated.
• Product demos: Provide demonstrations of the product, detailing how it works and its current state, so new hires can quickly gain context and start contributing.

By designing an onboarding process that covers these areas, you’ll help new hires become effective members of your team while minimizing disruption to existing workflows.

Developing & Growing the Team

No matter how great the people you hire are, there will always be a need for continuous development. This is critical for several reasons:

• Your organization is unique, and new hires may lack specific knowledge or skills.
• As your organization evolves, even top performers need to grow to keep pace.
• Learning and growth are essential for retaining high-performing team members.
• A structured approach to assessing performance ensures your team remains effective and impactful.

Continuous development goes beyond traditional performance management; it includes professional development and coaching. Here are a few key components to consider:

• Competency framework: Define the core competencies required for PMs and create an evaluation rubric to measure them.
• Evaluation process: Managers should conduct regular evaluations to track progress and identify areas for improvement.
• Feedback process: Implement a systematic way for PMs to receive constructive feedback on their work.
• Professional development: Focus on actionable steps to help team members improve through coaching, mentoring, and tailored development plans.
• Talent roadmap: Similar to a product roadmap, map where your team is today, where it needs to be, and how you’ll get there. This can include current and future competency gaps to guide hiring and development efforts.
• Learning and training: Offer targeted training programs, workshops, mentorships, and Q&A sessions to address specific skill gaps and foster growth.

This is a vast and critical topic that I’ll explore in greater depth in future articles. For now, these high-level ideas offer a foundation for building a culture of continuous development within your product team.

Collaborating with Founders / CEOs

The relationship between the Head of Product and the CEO is critical to the success of the product team and the company as a whole. In my experience, this relationship is one of the most challenging compared to other executive roles for two key reasons:

1. Product is central to the business. In tech startups, the product is often the business itself (e.g., SaaS companies) or the primary enabler of the business model (e.g., marketplaces). This makes product decisions highly strategic and business-critical.
2. CEOs are naturally involved in product. Unlike other business functions where CEOs might defer to their leadership team, many startup CEOs have a strong product sense — either because they come from a product background or because product decisions are inherently tied to business outcomes. As a result, they tend to be more hands-on with product than with other functions.

Throughout my career as a Product Leader, I’ve worked with four different Founders/CEOs and also founded my own company, which has given me insight into this relationship from both perspectives. Based on these experiences, I’ve developed a set of principles and a structured approach to help both CEOs and Product Leaders build a productive relationship that drives business success.

In fact, I believe that establishing strong alignment between the Head of Product and the CEO is even more important than implementing the other components of this playbook. Without alignment, friction and inefficiencies will arise, making it nearly impossible to build a high-performing product team. However, when trust is established, the Product Leader gains the CEO’s confidence, which is essential for empowering the team, driving strategic decisions, and fostering long-term success.

My advice: Both CEOs and Product Leaders should invest significant time upfront in aligning expectations, defining their working relationship, and agreeing on decision-making processes before attempting to build or scale the team. A well-structured, trust-based collaboration will enable the product function to operate at its full potential and create meaningful impact for the business.I plan to delve deeper into this topic in future articles, where I will share my framework and key principles for building a strong CEO-Product Leader relationship.

Handling People Challenges

Over the years, I’ve encountered a wide range of people-related challenges and worked to aggregate these experiences into a playbook for addressing them. I plan to share these learnings in greater detail in future articles. Some of the issues this playbook covers include career progression challenges such as performance issues, mismatches between someone’s career expectations and what the company can offer, the “Senior PM trap,” and lack of motivation. It also addresses sensitive topics like raises, terminations, and layoffs, as well as broader organizational challenges such as restructuring, employee retention, and maintaining a high-performing team.

Processes

In this section we will dive into the processes you need to implement in order to run a high performing team

Product Development Process

A well-structured Product Development Process (PDP) is crucial for guiding how new products or features move from idea to execution and launch. At a high level, an effective PDP consists of four key steps:

1. Opportunity Assessment — Defines the initiative’s purpose, identifies the problem to be solved, and establishes success criteria.
2. Product Definition — Outlines what needs to be built by gathering product requirements and creating detailed specifications and designs.
3. Product Development — Builds the product based on the defined requirements and specifications.
4. Impact Assessment — Evaluates the results against the initial success criteria to measure impact and extract key learnings.

The opportunity assessment phase is often overlooked, with PMs and stakeholders rushing directly into the solution space and writing specifications. However, this phase is vital as it acts as a contract among all parties, clarifying why the product is being built, the problem it aims to solve, and the expected impact. Similarly, the impact assessment phase is frequently neglected. Organizations should establish a culture of consistently measuring the impact of what they build and tying it back to the assumptions made during the opportunity assessment. This phase is also where learnings are gathered to inform future initiatives.

A successful PDP must be supported by effective communication and regular updates to all relevant parties. Following the process itself is not enough — keeping stakeholders informed ensures alignment and smooth execution.

I want to emphasize that a crucial part of the PDP is incorporating work output review and approval steps throughout every phase of the process. For example, during the product definition, designs and specifications must be reviewed and approved to ensure alignment with objectives. Similarly, in the product development phase, user acceptance testing (UAT) should be conducted before anything goes live to verify that the product meets expectations.

It’s important to note that a PDP should align with the company’s culture and operating model. There is no one-size-fits-all solution. Implementing a PDP isn’t as simple as downloading a template from the internet; it requires careful tailoring based on insights collected during the assessment phase. Additionally, elements of the PDP often involve how other functions interact with the product team, making it crucial to secure buy-in from executives and other stakeholders.

In conclusion, the PDP must be designed to fit seamlessly with the organization’s broader processes and goals. A well-implemented PDP is not only a tool for delivering products effectively but also a critical enabler for aligning teams and driving meaningful impact.

Product Discovery Process

While the Product Development Process (PDP) typically begins with an idea and focuses on Opportunity Assessment, it is equally important to establish a Product Discovery Process for idea generation — the foundation of impactful product development. A well-structured Product Discovery Process ensures a continuous pipeline of validated, high-impact ideas feeding into the PDP.

1. Problem discovery: Gathering potential issues through user interviews, data analysis, and other exploratory methods.
2. Problem identification: Conducting rigorous research to validate the identified issues and uncover their root causes.
3. Solution identification: Brainstorming and creatively devising potential solutions to address the problems.
4. Solution validation: Testing proposed solutions to ensure they effectively solve the identified problems.

When implementing a Product Discovery Process, consider the following key factors:

• Balancing qualitative and quantitative methods: PMs and researchers often gravitate toward quantitative methods for speed and scalability. However, qualitative methods like user interviews, while more time-intensive, often uncover deeper insights that would otherwise be missed.
• Prioritizing research efforts: Research and analysis come with costs and resource constraints. It’s essential to carefully prioritize where research efforts should focus to maximize value.
• Documenting findings: The outcomes of discovery should be thoroughly documented to build an insights database that can be referenced later. This repository becomes an invaluable resource for future problem-solving and decision-making.
• Journey inspections: A powerful source of discovery lies in conducting end-to-end journey inspections. While teams often focus on isolated problems, observing users throughout their entire journey can reveal overlooked opportunities and inspire fresh ideas.

By integrating a robust Product Discovery Process, organizations ensure that the Product Development Process (PDP) is continuously fueled with validated, high-impact ideas, reducing wasted effort and setting the stage for meaningful product development.

Planning and Roadmapping Process

Every product team should have a clear process for creating both short- and long-term roadmaps, as well as for overall planning. While there are countless articles, books, and methodologies on roadmapping and planning, this playbook will focus on key considerations that Product Leaders need to address when designing their planning process. I am sharing a high-level view of a few of them to give you an idea of what I am talking about:

1. Overhead of the Planning Cycle: There is always a trade-off between the frequency of planning and its associated overhead. Every planning session takes time away from building. While more frequent planning provides greater control and flexibility, it also increases the cost in terms of effort and resources. Finding the right balance is crucial.
2. Communication: Effective communication of the roadmap and keeping stakeholders updated is paramount. Striking the right balance is challenging: sharing too much information can overwhelm executives, leading them to ignore updates, while sharing too little may leave stakeholders feeling out of the loop.
3. Providing Accurate Estimates: Accurate estimates require teams to invest time in writing detailed specifications and analyzing the work, which can detract from actual execution. This challenge is compounded by the difficulty many engineering teams face in estimating velocity. Balancing estimation effort with productivity is essential.
4. Stakeholder Approval Process: Ensuring that roadmaps are approved by the right stakeholders and that they fully understand what they are signing off on is vital. A robust approval process minimizes misunderstandings and builds alignment.
5. Stakeholder Input: Product Leaders must gather input from a diverse group of stakeholders during planning. It’s critical to incorporate business-led, product-led, and engineering-led initiatives into the roadmap. Striking this balance ensures the roadmap reflects the organization’s broader priorities.
6. Maintenance Work: Many roadmaps fail because they allocate all capacity to new work, neglecting maintenance. A good planning process anticipates and accounts for ongoing needs, such as product maintenance, technical upgrades, and support, using data to allocate capacity realistically.
7. Impact Assessments: Most planning processes prioritize work based on impact versus effort. However, it’s essential to establish a feedback loop to compare actual impact against projected outcomes. This learning can be used to refine impact estimations for future initiatives.
8. Impact-Based Prioritization: While impact-based prioritization is ideal in theory, in practice, many organizations face conflicts between high-impact initiatives and top-down strategic directives. A framework for balancing these competing priorities is essential to avoid misalignment.
9. Managing Mid-Cycle Changes: It is unrealistic to expect a roadmap to remain static, especially in long-term planning cycles. The team must be prepared to adjust plans mid-cycle as new priorities arise or unforeseen challenges emerge.
10. Problem-Based Roadmaps: Traditional planning often commits teams to delivering specific solutions, creating friction when stakeholders expect problems to be solved, not just solutions to be delivered. A problem-based roadmap focuses on identifying problems to be addressed within a cycle, along with success criteria. However, implementing this approach requires a higher level of organizational maturity and alignment.

Roadmapping and planning are foundational to a product team’s success. While every organization’s approach will vary based on its culture and maturity, addressing these considerations thoughtfully can lead to more effective planning processes, better stakeholder alignment, and greater overall impact.

Product Strategy

Product strategy is one of the most misunderstood and misused terms in product management. While everyone seems to talk about strategy, definitions vary widely, leading to confusion and misalignment. It’s critical for any product team to first align on what they mean by strategy.

From my perspective, strategy is the prioritized set of problems and opportunities an organization chooses to tackle in the next cycle, aligned with its long-term vision and goals. Unfortunately, many leaders confuse strategy with initiatives or projects, resulting in roadmaps that are mistakenly equated with strategy.

Once the team agrees on what strategy means, the next step is to establish a strategy creation process. This process, in my view, mirrors the steps outlined in the Product Discovery Process section: problem discovery, problem identification, solution identification, and solution validation.

One common issue I’ve observed is misalignment and friction between product teams and stakeholders regarding roadmaps and prioritization. Many companies try to address this by involving stakeholders more deeply in the planning process, often leading to micromanagement of PMs. However, in my experience, the root cause is often a lack of alignment on strategy. When the leadership team agrees on the strategy — the set of problems the company should focus on solving — misalignment tends to diminish.

Misalignment rarely stems from disagreements on how a problem was solved; it’s far more common for friction to arise when the product team prioritizes a problem the stakeholder didn’t consider important. This highlights the importance of aligning on the strategy itself rather than focusing solely on execution.

The absence of a well-defined strategy — or a shared understanding of what strategy means — also impacts how stakeholders interact with the product team. Broadly, there are three ways stakeholders can interact:

1. Goal-based: Stakeholders give the team a goal (e.g., increase customer retention by X%) and let the team determine which problems to tackle and how to solve them.
2. Problem-based: Stakeholders provide a specific problem to solve, leaving the team to decide on the best solution.
3. Solution-based: Stakeholders provide a specific solution for the team to implement.

Unfortunately, many companies operate in the solution-based model (3), which limits creativity and ownership within product teams. To achieve greater effectiveness and trust, organizations should aim to move to the problem-based model (2) and, eventually, the goal-based model (1). However, this progression requires not only a higher level of organizational maturity but also significant trust between stakeholders and the product team.

Performance Management

First of all, I think the term “performance management” is a bit outdated and limiting. It should take a more holistic approach that includes professional development. I see this process as a continuous loop, built around a set of defined competencies that outline what is expected for each level or role. The process involves regular, iterative steps:

1. The product leader evaluates, and the direct report self-evaluates, their performance against each competency.
2. They align on areas of improvement.
3. Together, they construct a development plan to address these areas — for example, identifying steps to meet the requirements for progression to the next level.
4. They meet regularly to discuss progress and adjust the plan as needed.

This process should be repeated regularly to ensure the team is continuously improving.

Additionally, I find it very useful to map the entire team against these competencies to understand how the team as a whole scores and identify areas for improvement. This provides insights into where to invest in team development. Over time, you can monitor how the team evolves and project where it is headed, enabling better planning for future hiring and growth.

Metrics

I am a strong believer in data-driven product management and believe that every product leader should leverage a robust set of tools and reports to gather the necessary information for informed decision-making. I categorize these into the following areas:

1. Goals and Outcomes: Teams should have clear reports to track their goals, such as OKRs, and monitor their performance against them. This ensures alignment with the organization’s objectives and provides clarity on progress.
2. Output Metrics: These are health metrics related to product performance, often overlapping with or extending beyond goals. Examples include funnel conversions, revenue, retention rates, and other key performance indicators (KPIs) that reflect the product’s overall success.
3. Input Metrics: Often overlooked, input metrics are leading indicators that reflect the drivers behind business performance. While output metrics like signup-to-activation conversion provide results, input metrics can help explain those results. For instance, tracking the distribution of channels users signup from can shed light on conversion changes. If the percentage of signups from a channel with naturally lower conversion rates increases, it can explain a drop in overall conversion rates. Distinguishing and tracking both input and output metrics is critical for proactive decision-making.

Another useful approach is to create a hierarchical or tree structure of metrics. Different roles and seniority levels require different views of the data. For example, a Head of Product might focus on overall end-to-end conversion metrics, while the PM responsible for activation may need to track step-by-step conversion rates within the activation funnel. A connected and hierarchical set of dashboards allows for high-level monitoring while enabling deeper dives into specific areas when needed.

Another good practice that I’ve seen work very effectively is to have team or squad-level dashboards and metrics. Each team or squad should have a dedicated place to track their own metrics, which helps create a data-driven culture where all individuals, including non-PMs, build the habit of regularly checking their metrics. In other words, there is a “library” of metrics being tracked, and these metrics can be organized into different dashboards tailored to specific team members. If you want to build this data-driven culture, you need to make it easy for individuals to access and review the metrics.

An alert system is also essential to notify teams of abnormal changes in key metrics. I’ve seen situations where something breaks or a negative trend emerges, causing significant revenue impact — only for the team to discover it days or even weeks later. Alerts should be set up not just for output metrics but, more importantly, for input metrics, enabling teams to identify and address potential problems as early as possible.

By focusing on these areas — goals, input and output metrics, hierarchical dashboards, and alert systems — teams can build a robust foundation for data-driven product management, enabling proactive and informed decision-making.

Meetings / Communication

While this topic isn’t specific to product teams and applies to the entire organization, I want to lightly touch upon it. I believe companies and teams should have a structured process around communication and meetings. Without such a process, communication can become chaotic and significantly hurt productivity.

I would classify communication and meetings into three categories:

1. Team-Level Meetings

These meetings serve multiple purposes, such as building team culture, managing people, fostering professional development, and ensuring general alignment. Examples include:

• Product Team Meeting: A weekly meeting for the product team. For larger teams, this may occur at the squad level, with the entire team meeting less frequently, such as monthly or quarterly in an All-Hands format.
• 1:1s: Weekly one-on-one meetings between managers and their direct reports to discuss progress, challenges, and career development.
• Product Leadership Meeting: Regular meetings between the Head of Product and their direct reports to ensure alignment and strategic focus.
• Monthly Development Meeting: A dedicated monthly session between Product Leaders and their direct reports to focus on coaching and professional growth.

2. Stakeholder Meetings

These meetings aim to align with stakeholder groups on strategy, planning, and cross-functional collaboration. Examples include:

• Product Reviews: Meetings with the CEO or key executives to review progress and gather input on strategic direction.
• Product/Function Group Meetings: Regular sessions between product leads and specific function leads to review progress and coordinate efforts.
• Planning Meetings: Sessions focused on aligning goals and strategies across functions.

3. Initiative-Level Meetings

These meetings bring together everyone involved in a specific initiative or strategy. They are held regularly to provide updates, solve problems, and maintain alignment. Depending on the size of the team or organization, some of these categories may be merged. While I understand and agree that too many meetings can hinder productivity, a lack of alignment can be even more detrimental. It’s essential to create a meeting structure that fits the specific needs of the organization, balancing alignment with efficiency.

Tools

In this section, I will briefly discuss the essential tools a product team needs to operate effectively. I will keep it high-level, focusing on the key categories of tools that teams should have in place. Since there are already numerous articles online comparing and evaluating specific tools, I won’t provide an exhaustive list of options but will instead include 1–2 examples per category. Ultimately, the choice of tools varies significantly based on a team’s unique needs and circumstances. It should also be made in conjunction with the outcomes of the assessment phase, as well as decisions related to processes and people.

1. Product Management & Roadmapping

• Roadmapping & Prioritization: Plan product strategy and prioritize features E.g. Aha!, ProductBoard
• Backlog Management: Organize tasks and manage development workflows E.g. Jira
• Product Documentation: Centralize product requirements and decisions E.g. Confluence, Notion

2. Project and Task Management

Plan sprints, track progress, and manage execution E.g. Trello, Asana, Jira, Monday

3. Designing & Prototyping

• UI/UX Design: Create wireframes, mockups, and high-fidelity designs E.g. Figma
• Prototyping & User Flows: Build interactive prototypes and visualize workflows E.g. InVision, Balsamiq

4. Team Collaboration

• Async Communication: Messaging and discussions for distributed teams E.g. Slack, Microsoft Teams
• Sync Communication: Real-time meetings and video calls E.g. Zoom, Google Meet
• Documentation & Knowledge Management: Store and share internal knowledge E.g. Notion, Confluence
• Whiteboarding & Brainstorming: Visual collaboration for brainstorming and planning E.g. Miro

5. Analytics & Performance Monitoring

• Product Analytics: Understand user behavior and feature adoption E.g. Mixpanel, Amplitude
• Web Analytics: Measure website traffic, conversions, and performance E.g. Google Analytics
• Session Recording & UX Insights: Record user sessions and analyze interaction patterns E.g. LogRocket, FullStory

6. Reporting & Business Intelligence

Generate insights through dashboards and reports E.g. Looker, Tableau, Sisense

7. A/B Testing & Experimentation

Test new features and optimize user experiences E.g. Optimizely

8. Customer Feedback & User Research

• Surveys & Feedback Collection: Gather user insights and satisfaction scores E.g. Typeform, SurveyMonkey
• User Testing & Research — Validate usability and test prototypes with real users E.g. UserTesting
• Participant Recruitment — Find and recruit users for research studies E.g. UserInterviews.com

Closing Thoughts & What’s Next?

I hope this article provided you with a solid understanding of the fundamental building blocks involved in creating or scaling a product team. While there was a lot to cover in a single piece, and we only scratched the surface, my goal was to give you a comprehensive overview of all the necessary components and how they connect. Moving forward, I plan to publish dedicated articles for each component, where we will dive deeper into what they entail. More importantly, I will share real-life experiences from implementing them. Ultimately, my vision is to consolidate everything into a comprehensive book — an essential resource for Founders and Product Leaders looking to build and scale high-performing product teams.