Part 3 of our Product Operating Model Transformation Series

---

After our failed attempt at transforming the entire product organization simultaneously, our VP finally came around to a different approach. “Maybe we should start smaller,” he admitted during one of our many post-mortem meetings. The question then became: which team should be our guinea pig?

Our first instinct was to pick the team with the most problems. You know the logic—they’re already struggling, so they have the most to gain from a new approach. That turned out to be exactly the wrong thinking.

We also considered choosing the team working on our most visible product, figuring that success there would create the biggest impact. Another mistake.

It took us three failed pilot attempts before we finally understood that picking the right pilot team is less about the product they’re working on and more about the people and circumstances that set them up for transformation success.

The Pilot Team Paradox

Here’s the counterintuitive truth about pilot team selection: you want to pick teams that are already somewhat functional, not the ones that are completely broken. This feels backwards because transformation is supposed to fix problems, right?

But here’s the thing—transformation is hard enough when everything else is working well. If you start with a team that’s already struggling with basic collaboration, unclear requirements, or technical debt, you’re adding transformation challenges on top of existing dysfunction. That’s a recipe for failure.

Instead, you want teams that have enough stability to focus on learning new ways of working without being distracted by fundamental operational issues.

The Ideal Pilot Team Profile

After our eventual success (yes, we did finally get there), here’s what we learned makes for an ideal pilot team:

They Have Psychological Safety

This is non-negotiable. Transformation requires experimentation, and experimentation means some things will fail. If team members are afraid to try new approaches because failure might hurt their careers, the pilot will never get off the ground.

Look for teams where people regularly share different opinions, admit when they don’t know something, and can have constructive disagreements without it getting personal.

They’re Curious, Not Desperate

You want teams that are interested in learning new approaches, not teams that are so burned out they’ll try anything to escape their current situation. Curious teams approach transformation as an opportunity to grow. Desperate teams treat it as a last resort, which creates the wrong mindset.

They Have Stable Team Composition

Avoid teams that are about to lose key members or gain new ones. Transformation is hard enough without the added complexity of team formation dynamics. You want people who already know how to work together.

They Work on a Product with Real Users

This might sound obvious, but make sure the pilot team works on something that has actual users they can talk to. Internal tools, infrastructure projects, or products still in early development don’t provide the feedback loops necessary for learning customer-centric approaches.

Leadership Trusts Them

Pick teams that already have credibility with leadership. When (not if) the pilot team makes decisions that seem strange or risky to traditional thinking, leadership needs to trust that the team knows what they’re doing. Starting with a team that already has that trust bank built up makes everything easier.

Red Flags: Teams to Avoid

Just as important as knowing what to look for is knowing what to avoid:

The Problem Child Team

Don’t pick the team that’s already struggling with delivery, team dynamics, or stakeholder relationships. Transformation won’t fix those underlying issues—it will just add another layer of complexity.

The Superstar Team

Surprisingly, your highest-performing team might not be the best choice either. They’re often high-performing because they’ve optimized the current system. They might resist changing what’s already working for them.

The New Team

Avoid teams that just formed or are about to undergo major composition changes. They need to figure out how to work together before they can learn new ways of working together.

The High-Visibility, High-Pressure Team

That team working on the CEO’s pet project? Probably not the best pilot choice. The pressure to deliver predictable results will constantly pull them back to familiar approaches.

The Infrastructure Team

Teams working on internal platforms, APIs, or other infrastructure often don’t have direct user contact. Without that customer feedback loop, it’s hard to practice customer-centric discovery and validation.

Our Selection Process (The Third Time’s the Charm Version)

Here’s how we finally got pilot team selection right:

Step 1: Map All Product Teams

We created a simple matrix of all our product teams, rating them on key criteria:

• Team stability (composition, working relationships)
• Psychological safety (based on team surveys and observation)
• User access (how easy is it to talk to real users)
• Stakeholder complexity (how many cooks in the kitchen)
• Current performance (not struggling, not optimized)

Step 2: Interview Team Members

For the top candidates, we had informal conversations with team members (not just managers) about their interest in transformation. We were looking for genuine curiosity, not just compliance.

Step 3: Assess Leadership Support

We made sure the team’s direct leadership was genuinely supportive, not just going along with the initiative. This meant having honest conversations about what support would look like when things got difficult.

Step 4: Validate User Access

We confirmed that the team could easily access real users for interviews, surveys, and feedback. If setting up a user interview required three weeks and five approvals, that wasn’t going to work.

Step 5: Check the Product Fit

We made sure the product had enough complexity to benefit from discovery practices but wasn’t so complex that cause-and-effect relationships would be impossible to establish.

The Team We Finally Chose

Our successful pilot team worked on a customer-facing dashboard product. Here’s why they were perfect:

• Stable team: Same five people had been working together for eight months
• Psychological safety: They regularly debated technical approaches without drama
• Curious: Multiple team members had asked about user research training
• Trusted: Leadership consistently backed their technical decisions
• User access: They already had a list of friendly customers willing to give feedback
• Right complexity: Clear user workflows with measurable outcomes

They weren’t our highest-performing team or our most visible product. They were just the team with the best conditions for learning.

Setting Expectations with Your Pilot Team

Once you’ve selected your pilot team, you need to set clear expectations:

This Is Real Work, Not a Side Project

Make it clear that learning the product operating model is now part of their primary responsibilities, not something they do in addition to everything else.

They’re Learning, Not Proving

The goal isn’t to demonstrate that the product operating model works perfectly from day one. The goal is to learn what works in your specific context and what needs to be adapted.

They Have Permission to Be Different

Give them explicit permission to work differently from other teams. They might have different meeting structures, different deliverables, different success metrics. That’s the point.

Failure Is Expected and Valuable

Set the expectation that some experiments will fail, some hypotheses will be wrong, and some approaches won’t work. That’s valuable learning, not failure of the transformation.

Common Selection Mistakes We Made

Before we got it right, here are the mistakes we made (so you don’t have to):

Picking Based on Product Importance: We thought success on our most important product would create the biggest impact. Instead, the pressure to deliver predictable results constantly pulled the team back to familiar approaches.

Choosing the Volunteers: We asked for volunteers and picked the most enthusiastic team. Turns out enthusiasm doesn’t equal capability—they were eager but lacked the stable foundation needed for successful transformation.

Avoiding “Good Enough” Teams: We kept looking for the perfect team instead of recognizing that pretty good teams with the right conditions would be perfect pilots.

What Success Looks Like

You’ll know you’ve chosen the right pilot team when:

• They’re excited about the opportunity (not just going along with it)
• They start asking different questions about their users and metrics
• They request resources for discovery activities
• They’re comfortable sharing learnings, including what isn’t working
• Leadership starts using them as an example of new ways of working

What’s Next

In our next post, we’ll dive into how to build the skills pilot teams need to succeed. Because picking the right team is just the first step—you then need to invest in developing their capabilities for this new way of working.

Until then, take a look at your own product teams. Which ones have the right conditions for transformation success? Remember, you’re not looking for perfect teams—you’re looking for teams with the right foundation to learn and grow.

---

This is part 3 of our Product Operating Model Transformation Series. Coming up next: “Building the Skills Pilot Teams Need to Succeed”

What criteria have you used for selecting pilot teams? What worked and what didn’t? Share your experiences in the comments below.