Part 5 of our Product Operating Model Transformation Series

---

Three months into our pilot team’s transformation journey, I watched our VP of Product completely undermine weeks of progress with a single question in a stakeholder meeting.

Our pilot team had just presented their latest discovery findings—compelling evidence that a major feature request from sales wasn’t actually what customers needed. They’d done the research, formed hypotheses, ran experiments, and had data to back up their recommendations.

“That’s interesting,” our VP said, “but Sales really needs this feature for the Johnson deal. How quickly can we get it built?”

In that moment, I watched our pilot team’s confidence deflate. All the skills they’d been developing, all the new practices they’d been learning, all the evidence-based decision making—none of it mattered when push came to shove.

That’s when I realized we’d been focusing on the wrong problem. It wasn’t enough to select the right team and build their skills. If the organizational context didn’t support their new way of working, all that effort was wasted.

The Leadership Paradox

Here’s the uncomfortable truth about transformation: leaders often become the biggest obstacle to the change they’ve asked for.

It’s not intentional. Most leaders genuinely want transformation to succeed. But when faced with familiar pressures—aggressive sales targets, demanding customers, competitive threats—they default to familiar behaviors. They override team decisions, impose solution constraints, and fall back on the command-and-control approaches that got them where they are.

Our VP wasn’t trying to sabotage the transformation. He was trying to close a deal. But in that moment, he sent a clear message: when it really matters, we don’t actually trust this new way of working.

The Support Framework That Actually Works

After watching several more instances of well-intentioned leadership sabotage, we finally figured out what genuine support looks like. It’s not cheerleading from the sidelines—it’s actively changing your own behavior to enable the team’s success.

1. Change Your Questions

The fastest way leaders can support transformation is by changing what they ask about. Instead of:

• “When will this feature be ready?”
• “Why is this taking so long?”
• “Can’t we just build what the customer asked for?”

Start asking:

• “What have you learned about the customer problem?”
• “What’s your hypothesis, and how are you testing it?”
• “What would need to be true for this approach to work?”

Our breakthrough came when our VP started asking about learning rather than delivery timelines. Suddenly, our pilot team felt permission to share uncertainties, failed experiments, and evolving hypotheses.

2. Defend the Process, Not Just the Team

Supporting pilot teams means defending their right to work differently, even when it makes stakeholders uncomfortable. This includes:

Protecting Discovery Time: When stakeholders pressure teams to “skip the research and just build it,” leaders need to explain why discovery work is essential, not optional.

Defending Experimentation: When experiments fail or results are inconclusive, leaders need to frame this as valuable learning, not wasted time.

Supporting Different Deliverables: When teams produce customer insights instead of feature specifications, leaders need to help stakeholders understand the value of these new outputs.

3. Model Uncertainty Comfort

One of the biggest shifts leaders need to make is getting comfortable with uncertainty—and modeling that comfort for others. This means:

• Saying “I don’t know, let’s find out” instead of making assumptions
• Admitting when your initial instincts were wrong
• Celebrating when data contradicts your opinions
• Asking teams what they need to reduce uncertainty rather than demanding certainty

4. Translate Between Old and New

Pilot teams are learning a new language—hypotheses, outcomes, experiments, discovery. But the rest of the organization still speaks the old language—features, deadlines, requirements. Leaders need to become translators.

When the pilot team says: “We need two more weeks to validate our assumption about user workflow preferences.”

Leaders translate to stakeholders: “We’re making sure we build the right solution before we commit significant engineering resources. This small investment in validation will prevent much larger costs later.”

5. Create Air Cover for Decisions

Perhaps most importantly, leaders need to shield pilot teams from the pressure to revert to old ways when things get difficult. This means:

• Taking responsibility when pilot team decisions don’t immediately pay off
• Explaining transformation rationale to impatient stakeholders
• Providing buffer time for teams to practice new skills
• Backing team decisions even when you might have chosen differently

What Bad Leadership Support Looks Like

We learned as much from our failures as our successes. Here are the leadership behaviors that killed our early transformation attempts:

The Theoretical Supporter

“I completely support the new approach,” followed immediately by “but just this once, can’t we skip the research and build what Sales is asking for?”

The Impatient Optimizer

“This discovery work is taking too long. Can’t we parallelize it with development to move faster?”

The Hedge-Your-Bets Leader

Publicly supporting transformation while privately telling stakeholders “don’t worry, we’ll make sure you get what you need.”

The Micromanager

“I love that you’re doing customer research, but make sure you ask about the feature I think we should build.”

The Results-Only Supporter

Supporting the team when experiments succeed, but questioning the approach when experiments fail or provide inconclusive results.

The Stakeholder Education Challenge

Leaders can’t just support pilot teams internally—they need to manage stakeholder expectations and education. This was one of our biggest blindspots initially.

Sales Team Confusion

Our sales team was used to getting feature commitments months in advance. When our pilot team started saying “we’ll know more after we run some experiments,” sales panicked about how to handle customer conversations.

What worked: Regular stakeholder briefings explaining how the new approach would actually help sales by ensuring we built things customers truly valued.

Customer Success Concerns

Customer success was worried that all this discovery work meant we’d be slower to address customer complaints and feature requests.

What worked: Involving customer success in discovery activities so they could see how research was uncovering root causes behind customer requests.

Engineering Leadership Skepticism

Our engineering director was concerned that uncertain requirements would make sprint planning impossible and reduce development velocity.

What worked: Showing how hypothesis-driven development actually improved engineering productivity by reducing rework and scope creep.

The Support Playbook We Eventually Developed

Here’s what genuine leadership support looked like once we figured it out:

Weekly Stakeholder Updates

Instead of asking for feature delivery timelines, our VP started sending weekly updates about what the pilot team was learning. This helped stakeholders understand the value of discovery work.

Monthly Stakeholder Education Sessions

We ran monthly sessions where the pilot team shared their discoveries and methodologies with other stakeholders. This built understanding and buy-in across the organization.

Leadership Behavior Modeling

Our VP started using product operating model language in all his communications—talking about hypotheses instead of assumptions, outcomes instead of outputs, experiments instead of features.

Resource Protection

When other urgent priorities emerged, leadership explicitly protected the pilot team’s time and focus rather than pulling them into firefighting mode.

Success Redefinition

We changed how we measured and communicated success, focusing on learning velocity and customer outcome improvements rather than feature delivery speed.

The Specific Support Actions That Made a Difference

For Customer Discovery

• Provided access: Leaders opened doors to customer conversations that teams couldn’t access on their own
• Joined sessions: VP and other leaders participated in customer interviews to understand discoveries firsthand
• Protected time: Blocked attempts to “skip research this time” when pressure mounted

For Experimentation

• Celebrated failures: Publicly praised experiments that provided clear learning, even when results weren’t what we hoped
• Provided resources: Made sure teams had access to analytics tools, A/B testing platforms, and measurement systems
• Defended timelines: Explained to stakeholders why experiments take time to provide reliable results

For Hypothesis-Driven Development

• Asked different questions: Focused on learning rather than delivery in all team interactions
• Modeled uncertainty: Openly shared their own hypotheses and admitted when they were wrong
• Supported pivots: Backed team decisions to change direction based on evidence

For Stakeholder Communication

• Translated outcomes: Helped teams communicate customer value in language stakeholders understood
• Managed expectations: Set realistic expectations about transformation timelines and methodology
• Provided context: Explained why teams were working differently and what benefits to expect

The Moment We Knew It Was Working

Six months into our transformation, something remarkable happened. Our pilot team came to a leadership meeting with a recommendation to cancel a feature that was already in development.

Their research showed that customers weren’t actually experiencing the problem we thought we were solving. The feature would be well-built and well-designed, but it wouldn’t create meaningful customer value.

Instead of pushing back or asking them to find a way to make it work, our VP asked: “What should we build instead?”

That’s when we knew leadership support had become genuine. The question wasn’t whether to trust the team’s discovery—it was how to act on their insights.

Warning Signs Your Support Isn’t Working

Watch for these indicators that leadership support is falling short:

• Pilot teams stop sharing failed experiments or inconclusive results
• Teams revert to building predetermined solutions without discovery
• Stakeholders bypass the pilot team to make feature requests directly to leadership
• Teams start apologizing for taking time to do research
• Discovery work happens only when there’s “extra time” available

What Good Support Actually Looks Like

When leadership support is working, you’ll see:

• Teams proactively sharing discoveries, including uncomfortable truths
• Stakeholders asking teams about customer insights, not just delivery dates
• Failed experiments treated as valuable learning rather than wasted effort
• Teams feeling confident to push back on solution-focused requests
• Discovery work prioritized as essential, not optional

The Ripple Effect

The most powerful aspect of genuine leadership support is how it spreads. When other teams see that leadership truly backs the pilot team’s new way of working—even when it’s inconvenient—they start paying attention.

We began getting requests from other product managers who wanted to learn discovery techniques. Engineering teams started asking about outcome-based metrics. Stakeholders began framing their requests as problems to solve rather than features to build.

Leadership support doesn’t just enable the pilot team—it signals to the entire organization that transformation is real and valuable.

What’s Next

In our next post, we’ll look at ways that resistance can come up within the pilot team itself. Because even with great leadership support, transformation isn’t always smooth sailing. Sometimes the biggest obstacles come from within the team that’s supposed to be leading the change.

Until then, take a hard look at how you’re supporting your transformation efforts. Are you asking different questions? Defending new processes? Modeling uncertainty comfort? Remember, pilot teams need more than permission to change—they need active protection and support while they’re learning to work differently.

---

This is part 5 of our Product Operating Model Transformation Series. Coming up next: “When Resistance Comes From Within: Managing Pilot Team Challenges”

How have you seen leadership either enable or undermine transformation efforts? What support actions made the biggest difference? Share your experiences in the comments below.