Sign in Subscribe
Organizational Change

The Product Operating Model Explained: From Pilot Teams to Full Transformation

The Product Operating Model Explained: From Pilot Teams to Full Transformation

Audio Version ($)

The product operating model is everywhere these days. 

Since Marty Cagan and the Silicon Valley Product Group released TRANSFORMED: Moving to the Product Operating Model in 2024, it’s become nearly impossible to attend a product conference, scroll through LinkedIn, or walk to the office water cooler without someone mentioning the product model.

More a collection of principles than a detailed playbook, the product operating model overlaps with many of the concepts we cover regularly on Product Talk, such as continuous discovery, defining your work by outcomes, and working in a cross-functional product trio. 

In this article, we’ll define what the product operating model is, share how to roll it out at your organization, and examine what types of challenges or roadblocks you’re likely to encounter along the way and how to overcome them.

Let’s get into it! You can read this article from beginning to end or you can use the links below to jump to whichever question(s) you’re most curious about.

Getting to Know the Product Operating Model

How Do Organizational Roles & Responsibilities Change with the Product Operating Model?

Start Your Product Operating Model Transformation with Pilot Teams

What Are the Necessary Mindset & Skills in the Product Operating Model?

Getting to Know the Product Operating Model

Let’s start with some basic concepts about the product operating model—what is it, why is it worth working this way, and where does it work (and not work)?

What is the product operating model?

A quote card from Marty Cagan that says: “The product operating model applies to how products are built, how problems are solved, and deciding which problems to solve.” The image includes Marty Cagan’s name and photo, with the Product Talk logo at the bottom.

Marty Cagan introduced the product operating model concept in a blog post on the Silicon Valley Product Group blog and in the book he co-wrote with several Silicon Valley Product Group partners, TRANSFORMED: Moving to the Product Operating Model. 

Marty writes: 

The product operating model, also referred to as the product model, is a conceptual model based on a set of first principles that leading product companies believe to be true about creating products.  

The product operating model is about consistently creating technology-powered solutions that deliver value to customers and that also drive results for the business. It’s about achieving outcomes versus merely producing output.

According to Marty, there are three dimensions of the product operating model. It can be applied to: 

  • how products are built 
  • how problems are solved
  • deciding which problems to solve 

Many of these concepts overlap with topics we regularly cover here at Product Talk, including defining your work according to desired outcomes, creating a habit of continuous discovery, learning to identify and test assumptions, and working in a cross-functional product trio to define opportunities that will benefit both your customers and your business. 

For a deeper dive into the product operating model, check out Marty’s article:

Why should you adopt the product operating model?

A quote card from Product Talk that reads: “The product operating model is designed to keep your customers happy while also driving results for your business.” The image features a blue header and the Product Talk logo at the bottom.

The primary reason for adopting the product operating model is that this framework is designed to keep your customers happy while also driving results for your business. 

This is important because there are plenty of well-loved products out there that don’t contribute to the business’s success, just as there are countless case studies of companies that focused too much on business success at the expense of keeping their customers happy (and often paid the price in terms of destroyed brand image, bankruptcy, or legal fees). 

The product operating model helps ensure that you’re not going too far in either direction and you’re keeping both your customers’ and business’s needs in mind as you develop new products and features. 

Because adopting the product operating model involves a significant transformation, companies usually need to have a compelling reason to start working this way. Marty Cagan writes that some common reasons companies choose to adopt the product operating model include:

  • They’re facing increased competition. Company leaders who feel threatened by competitors and realize that the old ways of working will not allow them to remain competitive tend to be open to adopting the product operating model.
  • They see the rewards of making this transformation. There are numerous companies that can demonstrate how the product operating model is allowing them to innovate and succeed as a business. These case studies (many of which Marty shares in his book, TRANSFORMED) can be compelling to other leaders who would like to enjoy similar results.
  • They’re frustrated with the status quo. When leaders see their company has been making a significant investment into technology without achieving the desired outcomes, they see the product operating model as a way to get a better return on investment.

Teresa and Hope Gurion recorded a conversation about what indicates an organization is ready for the product operating model. Hope highlights that the CEO needs to believe that the way your organization is working today will not lead you to be successful in the future and they need to feel the pain that’s caused by your current way of working, both similar criteria to the ones from Marty we’ve mentioned above.

For more about the product operating model and case studies of companies that are adopting it, check out these resources:

How is the product operating model different from a project-based model?

A Product Talk quote card that reads: “Projects have a clear beginning and end. Products are never done.” The image features a blue header and the Product Talk logo at the bottom.

The product operating model is often compared to a project model. In the project model, budgets and teams are defined in terms of projects. 

Projects have clear beginnings and ends. The problem with this approach is that our work in product is never complete. If we treat our products as projects, we lose out on opportunities to learn from our customers and continue to refine our products over time. We don’t have an easy way to measure whether we built the right thing (and in the cases where we didn’t, to learn from those mistakes). And when companies make the majority of their decisions based purely on financial benefits, they risk alienating customers or even doing things that are harmful to them. 

In contrast, when companies follow the product model, leaders in product management, technology, and design are responsible for deciding which customer problems to solve. This doesn’t mean they get to do whatever they want—product leaders still need to consult with other stakeholders in order to understand the broader business context. But in this model, it looks less like taking orders from stakeholders and more like an ongoing conversation about the business’s top priorities and how to best address them.

To take a closer look at the difference between the product and project models, check out this article:

Can a hybrid project-and-product operating model work?

A Product Talk quote card that reads: “It’s not a good idea to transform every team at once.” The image features a teal header and the Product Talk logo at the bottom.

Yes, you can have a hybrid project-and-product operating model, especially when your company is new to this transformation. 

Generally, it’s not a good idea to transform every team to the product operating model at once. This creates chaos and can prevent you from making any progress at all. This is why the pilot team approach—where you select one team (or a small number of teams) who will adopt the product model while the majority of your company continues to operate on the project model—can be so effective. See “What are pilot teams?” to learn more about this concept.

But once you’ve figured out the right pilot teams, they’ve begun to see some success, and you’ve learned what works and what doesn’t work in your organization, you can start to roll out the product operating model more broadly.

Keep in mind that there are also some cases where it’s better to stick to the project model, such as when you’re working on compliance issues like GDPR or one-off projects.

You can learn more about pilot teams and the product vs. project models here:

How does continuous discovery relate to the product operating model?

A Product Talk quote card that reads: “Continuous discovery is how teams decide which problems to solve and how to solve those problems.” The image features a teal header and the Product Talk logo at the bottom.

There is a lot of overlap between continuous discovery and the product operating model. As a quick refresher, Teresa defines continuous discovery as: 

Weekly touch points with customers,
By the team building the product,
Where they conduct small research activities,
In pursuit of a desired product outcome

In order to engage in continuous discovery, Teresa encourages product teams to develop habits like defining their outcomes, interviewing customers, mapping opportunities on an opportunity solution tree, and identifying and testing their assumptions.

These continuous discovery habits map most closely to two of the three dimensions of the product operating model based on Marty Cagan’s definition: how problems are solved and deciding which problems to solve.

To explore the concept of continuous discovery in more depth, check out this article:

How long does a product operating model transformation typically take?

A Product Talk quote card that reads: “Organizational transformations often take years.” The image features a teal header and the Product Talk logo at the bottom.

Every company is different and there are a number of factors that can contribute to how long transformation takes, including the company’s size, maturity level, and people’s willingness to change.

Transformation tends to take much longer than most companies think—years rather than months.

Remember that a successful transformation involves changing core aspects of how your company works, including the funding model, how leaders make decisions, and how teams operate, so try to manage your expectations accordingly.

How do you know your organization is ready to adopt the product operating model?

In this video, Teresa and Hope discuss what needs to be in place before a company adopts the product operating model. They call out two key criteria:

  • Your company’s CEO has to have a belief that what you’re doing today isn’t going to drive success in the future.
  • Your CEO also needs to feel pain in the status quo, which could be caused by things like losing market share or failure to achieve financial results.

The reason why it’s important for the CEO to meet both criteria is because transformation to the product operating model can be hard. There will be many times when people might want to give up. And if the need to change isn’t coming from the CEO, this increases the chances that people will give up and fail to have a successful transformation. The CEO’s support and belief in the need to make the change increases the likelihood that you’ll actually follow through with it.

For more on assessing your organization’s readiness, see:

What are signs that your product operating model transformation is working?

As your company begins to adopt the product operating model, you will start to notice some changes in the way teams work and approach problems. A few of the milestones to look out for include:

  • During annual planning, executives fund outcomes or teams, not projects.
  • Outcomes take precedence over outputs in day-to-day work.
  • Product teams are empowered to solve customer problems (not asked or required to build features).
  • Stakeholders give input on solutions but don’t dictate which solutions should be built.
  • You can see an improvement in the outcomes you’ve defined over time.

Can the product operating model work in regulated industries?

A Product Talk quote card that reads: “Regulated industries introduce additional constraints, but they too can benefit from the product operating model.” The image features a teal header and the Product Talk logo at the bottom.

To put it briefly, yes, the product operating model can work in regulated industries. While regulated industries may have additional constraints in which they need to operate, their products are also evergreen, always evolving, and never done.

If you’re interested in learning more about how real-life teams in regulated industries are adopting the product model, check out these stories: 

  • In Continuous Discovery Habits and on the Product Talk blog we included the story of Carl Horne, the VP of Digital Products & Services at Farm Credit Services of America. Carl’s team had the goal of engaging with customers digitally and ran several tests to determine how to best balance the needs of their customers and their business.
  • On the Product Talk blog, we published a Product in Practice article on insurance company Simply Business, whose product team conducted regular customer interviews along with other continuous discovery best practices to overcome their tendency to overthink and remind themselves that they needed just enough evidence for many of their decisions.
  • For insight into how the product operating model can work when dealing with a regulated industry like airlines, check out this Product in Practice article featuring Gary Clift, a Senior Director of Product, APIs, whose company allowed travel agencies to search and book travel content like flights, hotels, and cars. You’ll learn how Gary applied product operating model concepts to the task of rolling out a new API.

How does the product operating model work in small startups vs. large enterprises?

A Product Talk graphic comparing small startups and big companies.

It’s true that startups and large enterprises are different environments and each comes with its own set of constraints. Let’s take a closer look at each situation.

The product operating model in startups: Start with a directional goal

Early-stage startups may not even have a product yet, and they might believe this means they can’t set an outcome. But Teresa writes that early-stage, pre-product companies can start with a directional outcome and evolve their way to a more measurable outcome over time. Having a directional goal is all you need to start interviewing people who match your target customer profile and start mapping the opportunity space.

Teresa also calls out that many startups don’t work this way. In the startup world, many founders start with an idea, which sets discovery up for asking, “Is this idea good or not?”—and this type of “whether or not” question can lead to flawed decision-making. 

But even if you’re working with a “whether or not” question as your starting point, you can still adopt some ways of working that are aligned with the product operating model, including interviewing customers, mapping the opportunity space, story mapping solutions, and generating assumptions.

The product operating model in large enterprises: Managing more stakeholders and showing your work

In large companies, you already have a well-defined product and customer base. The challenges you face when adopting the product model will likely be related to coordination and scale—it’s hard to get everyone working this way (see “What is the biggest mistake companies make when trying to adopt the product operating model?”), there are more stakeholders and gatekeepers to manage, you have to be more diligent about showing your work, and it’s more challenging for leaders to hold their teams accountable. 

Let’s take a closer look at those last three points.

Larger organizations mean more stakeholders and gatekeepers to manage

In large companies, product teams will need to work with more stakeholders outside their discipline, such as go-to-market teams like sales or marketing. 

There can sometimes be tension between go-to-market teams and product teams because go-to-market teams need to know what’s coming through the product pipeline so that they can coordinate their efforts. As a result, they will often ask for or expect to receive a product roadmap that tells them what features will be released and when.

But Teresa has written that date-based roadmaps are “exercises in futility” and set the wrong expectations. So what should you do if your sales and marketing colleagues are demanding roadmaps? Teresa says it’s not a good idea to wage an ideological battle about roadmaps. Instead, she recommends giving your stakeholders what they ask for, but starting to introduce opportunities and outcomes to this artifact.

You may also find that in larger organizations, sales, marketing, and account management teams want to “own” the customer relationship and they might be reluctant to let product teams engage directly with customers. 

If your sales or marketing team is currently acting as a gatekeeper and preventing you from talking to customers, Teresa writes in this article that you can handle sales and marketing gatekeepers by removing the unknown from the situation and starting with small steps to help overcome their objections.

Large organizations require product teams to be intentional about showing their work

As an organization grows larger, it becomes more difficult for teams to keep stakeholders informed about what they’re doing and what they’ve learned. And many product teams err on the side of sharing everything with their stakeholders—every customer interview or every version of their opportunity solution tree. 

But Teresa writes that overloading stakeholders with too much information is rarely effective: “Very few stakeholders want (or have time) to see every iteration we’ve churned through. Instead, they want to see the thinking that has led to where we are now.” So product teams will need to learn not just how to show their work, but how to show the level of detail that will be most relevant and useful to their stakeholders.

Large organizations make it harder for leaders to hold their teams accountable

Finally, as a company grows, it’s harder for leaders to measure their team’s performance. Teresa and Hope recorded a video about the changes needed to hold empowered teams accountable. Teresa said, “I can see in the old world where I managed my product teams by a fixed roadmap with features and release dates, I could evaluate their effectiveness by just asking: ‘Did they build what we asked them to?’ And then: ‘Did they deliver it on time?’”

In the product operating model, Hope suggests creating regular rituals like discovery demos where teams share what they’ve learned lately that’s helping them advance toward their outcome. Depending on your organization, you might invite leaders to participate, or you may gain more value from inviting other members of the product/design/engineering organization to coach and offer suggestions.

For more how the product operating model evolves as your company grows, see:

What does failure look like in a product operating model transformation—and how can you recover?

One of the clear signs of failure when it comes to product operating model transformation is that your company is focusing only on product managers or product teams but not considering the other ways your organization needs to change.

Remember: The product operating model impacts your company in several significant ways, including your funding model, stakeholder involvement, and how teams are managed (by outcomes instead of outputs). 

If you see that your company is only focusing its transformation efforts on the product team and not accounting for the other changes that need to be made, you’ll need to check in with your CEO and other leaders to remind them why you’re making this change and what’s required for it to be successful.

What is the biggest mistake companies make when trying to adopt the product operating model?

A Product Talk quote card that reads: “Don’t train all of your teams at once.” The image features a teal header and the Product Talk logo at the bottom.

The biggest mistake companies make when trying to adopt the product operating model is trying to roll it out to everyone at once by training all teams in these new habits at the same time.

Why is this a mistake? Because it rarely works. Usually, there’s going to be quite a bit of resistance. When you do broad training and try to implement change universally, not everybody is going to be able to put it into practice immediately.

Trying to force change universally when not everyone is ready for it can create a lot of confusion that turns into resistance.

You can learn more about this mistake and how to avoid it in this video:

How does remote or distributed work affect the product operating model?

Like any work that involves close collaboration, adopting the product operating model can be more challenging when you have remote or distributed teams. However, it's still possible for remote teams to work this way. 

You will likely need to define core working hours when everyone is expected to be online and create regular opportunities for team members to get to know each other and build trust in addition to having regular rituals that allow teams to share their work and collaborate in real-time. 

Committing to certain habits like agreeing on working norms, setting rules for different communication channels, and knowing when to switch from asynchronous to synchronous communication can also help. 

You can learn more about best practices for working with remote or distributed teams in this article:

How Do Organizational Roles & Responsibilities Change with the Product Operating Model?

Everyone has a part to play in the product operating model, from the CEO to product leaders to the product teams themselves. This section considers how organizational roles and responsibilities differ in the product operating model vs. in a traditional project model. 

What does the CEO need to do in order for you to adopt the product operating model?

A Product Talk quote card about what the CEOs need to do. The image features a teal header and the Product Talk logo at the bottom.

The CEO plays a critical role in a company’s adoption of the product operating model, as we discussed in “How do you know your organization is ready to adopt the product operating model?”

In their conversation on determining whether your organization is ready for the product operating model, Teresa and Hope Gurion explained that there are generally two conditions that need to be true in order for the CEO to get to the point where they want to embark on a product operating model transformation: 

  1. They need to believe that the way your company is operating today won’t lead to success in the future. 
  2. They need to be experiencing the pain of the status quo.

If you’re not a CEO and you’re wondering how you can help your CEO to meet this criteria, start by sharing resources like Marty Cagan’s book TRANSFORMED or Teresa’s book Continuous Discovery Habits—both of which feature case studies of companies that have adopted the product operating model and the results they’ve achieved. 

For a deeper dive into getting your CEO ready to adopt the product operating model, check out this video:

What role does product leadership play in the product operating model?

A quote card from Marty Cagan that reads: “It is the single most important responsibility of every people manager to develop the skills of their people.” The image includes Marty Cagan’s name and photo, with a teal header and the Product Talk logo at the bottom.

Marty Cagan argues that coaching is the most often overlooked element to strong management. He writes, “It is the single most important responsibility of every people manager to develop the skills of their people.” 

From Marty’s perspective, coaching involves assessing and understanding your team members’ strengths and weaknesses, creating a coaching plan, and spending the time to help them improve. 

Product leaders—or anyone who has product teams directly reporting to them—play an important role in supporting the product operating model. If they’ve worked in other organizations that adopted the product operating model, they can serve as coaches to the teams that are trying to undergo this transformation, helping them learn how to manage by outcomes and develop other critical skills. 

If they haven’t yet gone through this transformation themselves, they may need to make some changes to their own mindset and behavior. For example, in the product operating model, leaders need to take less of a directive role and give teams more freedom to make their own decisions. This involves learning how to provide the appropriate business context to teams without dictating specific outputs or features they want to see built. It might also involve being more intentional about documenting and sharing strategic context so it’s more easily accessible to everyone on the team. 

For more on coaching and the required mindset and skills for product leaders, see:

How do product team members’ roles and responsibilities change in a product operating model?

An image showing the produc trio.

Adopting the product operating model involves changing the way teams work together and the way that leaders and other stakeholders work with product teams.

The product trio is the building block of the product operating model. This is a cross-functional team that is often made up of a product manager, a designer, and an engineer. 

While Teresa often uses the term “product trio,” she’s learned that it’s important to clarify that a trio may not always have three members. Depending on your business and company composition, you may add other members to the trio, such as data analysts or product marketing managers. 

The guiding principle to keep in mind when defining a trio is to create the smallest possible cross-functional unit that will allow you to make informed decisions. Remember: The larger your group, the slower and more inefficient your decision-making will become.

Product trios work closely together to conduct various discovery activities such as interviewing customers, mapping opportunities, and identifying and testing assumptions. Every member of the trio should share their expertise with each decision they make. For example, engineers should not only be expected to weigh in on technical feasibility issues. 

Product trios also need to work closely with their leaders and other stakeholders to define a desired outcome for their work. This dynamic represents a change from typical project models where leaders tell their product teams exactly what to build.

To learn more about product trios, check out these resources: 

How do empowered teams fit into the product operating model?

In the product operating model, empowered product teams are responsible for identifying the right customer problems to solve and solving them. But remember: This doesn’t mean they can do whatever they want. Product teams still need to work with their stakeholders to ensure they’re solving a problem that will serve both their customers and their business.

The big difference is that in the project team model, teams are told exactly what to build and have little say in defining the customer problems they’re trying to address.

For more about empowered product teams, see:

Start Your Product Operating Model Transformation with Pilot Teams

When you are ready to get started with a product operating model transformation at your organization, one of the most important steps you can take is to select pilot teams and support them during this phase. In this section, we’ll examine what pilot teams are and what they need to be successful.

What are pilot teams?

A Product Talk quote card that reads: “The goal of pilot teams is to show that the product operating model can work in your organization.” The image features a teal header and the Product Talk logo at the bottom.

Pilot teams are a small number of teams that have been specially selected to adopt the product operating model and its related habits first. By selecting pilot teams, you’re basically saying: Instead of doing this for everybody across the board, we’re going to pick a handful of teams that we think have the best potential to become a bright spot. The reason for taking this approach is to show that the product operating model can work at your organization and to make the transition more manageable. 

Why is it a good idea to have pilot teams during your product operating model transformation? What are the benefits of having pilot teams?

A Product Talk quote card that reads: “Pilot teams surface resistance and obstacles that must be overcome.” The image features a teal header and the Product Talk logo at the bottom.

First and foremost, pilot teams are the proof point of what this new, outcome-oriented way of working looks like in practice. They show everyone else in your organization that it’s possible to adopt the product operating model. They also expose what you need to address internally in order for this way of working to succeed.

One of the other benefits of pilot teams is that they will surface resistance and obstacles on a much smaller scale, so you can start to manage these challenges before rolling the change out to everybody. Another way of saying this is: Pilot teams help you control the chaos of transformation. 

For more on the benefits of pilot teams, see:

How many pilot teams should you select for your product operating model transformation?

The answer to this question depends on the size of your organization. For a small organization with three product teams, you might start with one pilot team. Mid-size organizations might choose between two and four pilot teams. And large organizations might choose as many as five pilot teams. 

To learn more about how many pilot teams are right for your organization, see this video:

How do you choose the pilot teams for your product operating model transformation?

A Product Talk quote card that lists five factors to consider when choosing pilot teams.

Choosing the right pilot teams is critical to your product operating model transformation. In this video, Teresa and Hope Gurion outline five key considerations when choosing a pilot team:

  1. The relationships among the team members: Pilot team members should know each other and be able to work together well.
  2. Their willingness to learn: Pilot team members need to have a growth mindset and the desire to shift to an outcome-oriented way of working.
  3. The team members’ existing skills: Your pilot team should have a complete set of skills, including product management, product design, and engineering.
  4. Their access to customers: Pilot teams will need to be able to regularly speak with customers to perform story-based interviews that will fuel their discovery.
  5. The lifecycle stage of their product: There are different terms people use for product lifecycle stages, but pilot teams should be at early stages like “explore” or “invest” to maximize their learning and success.

For a deeper dive on this topic, watch the full video here:

How can you set your pilot team up for success during a product operating model transformation?

A Product Talk quote card that outlines how to set pilot teams up for success.

If you’re making the choice to roll out pilot teams, there are a few things you can do to set them up for success. Teresa and Hope shared five tips for pilot team success in this video. Here’s what they outline:

  • A clear understanding of the business context: Make sure the pilot team is driven by an outcome and they understand how their work contributes to the business’s success.
  • Regular conversations with customers to find the most important problems to solve: Pilot teams need to learn how to uncover what problems to solve for their customers, and they need to learn how to evaluate if their proposed solutions actually solve those problems. Teresa says, “Here at Product Talk, we talk about this in the context of customer interviews and opportunity mapping: We’re going to go talk to our customers to learn about their unmet needs, their unmet pain points, their desires. And then we’re going to use opportunity mapping to synthesize all that and figure out what’s the most important problem to solve.” 
  • The ability to evaluate if they are building the right solutions: “Most teams are good at building solutions, but they may not be good at evaluating if they built the right thing,” says Teresa. “How do you then run quick and dirty assumption tests that can still support decision-making?” 
  • Unlocking faster delivery cycles: “Teams are going to need to learn how to rightsize what they are doing to expedite their learning,” explains Hope. “That typically means we need to enable them with qualitative discovery skills and quantitative discovery skills.”
  • The ability to collaborate cross-functionally: Pilot teams are learning all types of new ways of working, and somewhere along the line, Teresa explains they’re going to storm—in other words, they’re going to get frustrated with how things are progressing (or not) and they may become critical of others on the team or even the team’s mission and goals. When this happens, good collaboration skills can come to the rescue. Hope explains this can involve things like showing your work, externalizing your thinking, and recognizing that different members of your group have different expertise.

To learn more about the keys to successful pilot teams, see: 

What are some ways that leaders can best support pilot teams?

A Product Talk quote card that lists ways to support pilot teams.

Pilot teams don’t work in a vacuum and they won’t be successful without the support of their managers and other leaders. In their in-depth discussion of this topic, Teresa and Hope shared three specific things leaders can do to support pilot teams. Here’s a quick overview:

  • Being aligned with the outcomes the pilot team is working toward: The people directly managing the individuals on the pilot teams have to agree that the outcome that the team is working towards is meaningful. And, in the cases where there are other stakeholders who expect to share their point of view with the pilot team, those stakeholders need to be involved in defining—or at least providing input on—the outcome that team is working towards.
  • Understanding what it means to be outcome-focused: Managing by outcomes is very different from managing by outputs, so we can’t assume that leaders and stakeholders who’ve never worked this way will immediately know what to do. Hope suggests that if you’re a product leader who’s finding yourself in this position, know that you may need coaching from the person who’s leading the transformation within your company or from people outside your company who can help you develop this skill.
  • Encouraging pilot teams to be transparent and collaborative in their decision-making: When it comes to teams’ decision-making process, both the leaders and teams themselves will need to adapt to a more collaborative and open approach. Instead of the leaders just telling their teams what to do or which features to build, leaders should expect teams to share information with them and jointly discuss decisions and how to move forward.

For more on the role of leaders in supporting pilot teams, including some specific actions leaders and stakeholders can take to embody these values, see: 

What are some rituals that help pilot teams share their progress?

A Product Talk quote card that reads: “Create opportunities for your teams to share what they are learning.” The image features a teal header and the Product Talk logo at the bottom.

Rituals that allow pilot teams to share their progress can be really beneficial because it’s one way of starting to bring others along on this journey.

Product Talk instructor Hope Gurion refers to these rituals as “discovery delivery demos,” but she says you can call them whatever you want. This ritual involves showing what you’ve learned, what you want to learn next, how you think you’re going to learn it, and whether there’s anything that’s slowing you down. 

During these rituals, you might also show your work, whether that’s interview snapshots, the opportunity space you’re focusing on, or your assumption test plans.

Learn more about discovery delivery demos and other ways of showing your work in these resources:

How do you scale from pilot teams to the entire organization?

A Product Talk quote card that reads: “Address recurring problem areas before rolling out to everyone else.” The image features a teal header and the Product Talk logo at the bottom.

Rolling out change with pilot teams gives you the opportunity to observe what went well and what didn’t go well. For example, here are a few things you might learn from running pilot teams:

  • The fact that teams and leaders need to develop new skills (and you’ll be able to identify what those skills are)
  • Who is on board with the change and who might still need convincing
  • How your funding or planning rituals might need to change
  • Where there are roadblocks in terms of teams getting access to customers

The benefit of working with a few pilot teams at a time is that it will help you see which problems are specific to each individual pilot team and which ones are consistent across all your pilot teams. 

Based on what you learn, your organization will need to address the recurring problem areas before rolling out the product operating model to the rest of the teams.

The Role of Leaders & Stakeholders When Rolling Out Pilot Teams

Pilot teams have little chance of being successful without buy-in and support from their leaders and stakeholders. In this section, we’ll look at what leaders and stakeholders can do to help pilot teams succeed.

How can leaders start managing product operating model pilot teams by outcomes?

A Product Talk quote card that lists how leaders can support pilot teams.

It’s not always easy for leaders to make the switch to managing by outcomes (see “What are some common forms of resistance leaders and stakeholders have to product operating model transformation?”), so it’s important for both leaders and pilot teams to be aware that there will often be a learning curve involved in this transition. Teresa and Hope share some ways that leaders can start managing by outcomes in this video. Here’s what they suggest:

  • Create regular rituals: One way to make this transition is to create regular rituals where pilot teams can share their work and get feedback from leaders. (For more about these rituals, see “What are some rituals that help pilot teams share their progress?”) 
  • Avoid expressing personal preferences: When the team presents an adequate solution—even if the leader would have preferred a different one—the leader needs to learn to accept it. 
  • Make it clear when you’re simply giving a suggestion: Hope explains this distinction is really important, especially when teams are used to being in a more directive environment. 
  • Tell your team exactly when you’d like them to give you updates: If you’re afraid of your team going too far down a path before realizing it’s not the right one, think about when you’d like them to check in with you. This could be when they’re defining the target customer, when they’re sizing and prioritizing opportunities, or when they’re coming up with solution ideas.

For more on how leaders can change their own behavior to better manage by outcomes, see:

How much should leaders and stakeholders be involved in product operating model pilot teams’ everyday work and decisions?

There’s no single right answer to this question—it will depend on the preferences of both the leader and the pilot team. But Teresa and Hope explain there will be a learning curve for both leaders and pilot teams.

The leader can share when they’d like to be involved with the pilot team’s work, with the understanding that this is likely to evolve over time. 

As the pilot team gains more experience (or the leader realizes how much time it takes to be involved in every step), they will likely be able to decide on a few of the key stages where it makes the most sense to check in.

For more on the role of leaders in pilot teams’ work, see:

Expect and Manage Resistance During Your Pilot

Every pilot team is likely to encounter challenges or problems as they adopt the product operating model. In this section, we’ll discuss some common problems and how to overcome them.

A Product Talk quote card that lists common forms of pilot team resistance.

What are some common forms of resistance pilot teams have to product operating model transformation? (And how can you overcome them?)

Even though participating in a pilot team can be exciting and rewarding, there are times when you may encounter resistance among pilot team participants. In their conversation on this topic, Teresa and Hope outlined the three main types of pilot team resistance you’re likely to encounter:

  • “We don’t have time for this.” Hope says this common complaint often means that the team is stuck in delivery mode and they may feel constrained by a tight timeline. Teresa says overcoming this can be like learning to handle sales objections. Just like salespeople learn to get to the root cause when they hear an objection, product leaders need to dig deeper to understand what people really mean when they say they have no time.
  • “I don’t want to be a beginner again.” A lot of pilot team members are used to knowing exactly what they are supposed to do in their jobs and feeling like experts. And now they feel like they’re being told to do something completely different, so it’s uncomfortable. Teresa says sometimes overcoming this is as simple as acknowledging what your team is going through: “A leader can play a big role and be like, ‘It is hard. It's supposed to be hard.’”
  • “That will never work here.” Pilot team members might say there’s no way their leaders or stakeholders are going to support this or that the product operating model simply will never work here. Teresa says one of the best ways to help overcome resistance is to show what isn’t working right now. What’s driving the need for this change? Reminding teams of what you’re trying to move away from is also a good way to think about removing some of these obstacles.

For more on digging into the “not enough time” complaint and other forms of pilot team resistance, check out these resources:

What are some common forms of resistance leaders and stakeholders have to product operating model transformation?

A Product Talk quote card that lists common forms of leadership resistance.

Even when leaders and stakeholders theoretically agree with the idea of teams working on outcomes, they may still struggle to accept the reality of working this way. In this video, Teresa and Hope discuss a few of the most common forms of leader/stakeholder resistance to pilot teams:

  • Still expecting specific solutions: Teresa explains the conflicted feelings that leaders might have: “I might in my head intellectually agree, I want this team to work on this outcome and that all makes sense to me. But somewhere emotionally in my gut, I'm still committed to my favorite solution.”
  • Not wanting to give up control: Moving to empowered teams means that leaders have to give up control and trust their teams to find the best way to work towards their outcome. But this doesn’t always happen. Because leaders are used to having a sense of control and certainty, many of them resist the uncertainty that arises from working this way.
  • Continuing to expect their teams to run everything past them: This might seem innocuous, but Hope explains that it ultimately creates a bottleneck and it can mask the larger problem of leaders keeping strategic context in their own heads rather than sharing it in a way that’s accessible.

To learn more about these forms of resistance and how to overcome them, see: 

What Are the Necessary Mindset & Skills in the Product Operating Model?

The product operating model involves changing both people’s behavior and the way they think about their work. In this section, we’ll look at both the mindset and skills that are necessary to successfully adopt the product operating model.

Why is being outcome focused important for product operating model transformation?

A Product Talk quote card that reads: “Outcomes are more important than outputs.”

Being outcome focused means teams don’t measure their success as shipping output but instead by when that output has the expected impact.

Product teams and leaders rarely have a shortage of ideas. So the risk of working without an outcome is that the team will constantly stay busy, but they will be much less likely to make a positive impact on the business—and they won’t have the ability to measure whether the work they are doing is successful. 

Being outcome focused helps ensure that teams aren’t simply building things in order to stay busy, but in order to have a genuine impact on their customers and their business’s success. This is one of the most fundamental aspects of the product operating model.

To learn more about outcomes and how they contrast with outputs, see:

Why is collaboration such an important skill for product operating model transformation?

Traditionally, product managers, designers, and software engineers have worked in silos following a waterfall process with multiple hand-offs. In this model, we’re leveraging each person’s unique talents, which in theory sounds like it should be efficient. But in practice, it leads to many rounds of looping back and iterating. When we work in silos, we do more work, we take longer to complete that work, and we often build sub-optimal solutions.

When product managers, designers, and software engineers work together from the very beginning, they make better decisions about what to build. They make decisions that work for the business, that are usable and desirable by the customer, and that are feasible to build in the designated time. 

This is why collaboration is a critical skill for product operating model transformation—it allows these cross-functional team members to work together in this powerful way. 

For more on collaboration and its role in the product operating model, see:

What other questions do you have about the product operating model?

We’d love to hear from you. Do you have any questions about the product operating model that we didn’t cover here?

Audio Version

The audio version is available to paid subscribers only.

Read next