Earning the Authority to Lead: Why Product Teams Lack Power

Product teams in established businesses lack authority because they were never designed to have it. The product function was bolted on to an organisation that already had its own way of making decisions, its own power structures, and its own definitions of success. Earning authority is not about proving your competence. It is about changing the structural conditions that prevent the product team from having power in the first place.

This is the single hardest problem in product transformation. Harder than fixing team structure. Harder than addressing tech debt. Harder than aligning incentives. Because without authority, none of those other changes stick. You can redesign your teams, adopt new frameworks, and implement OKRs — but if the product function does not have the authority to make decisions and the trust of the organisation to execute on them, you are rearranging furniture in a house with no foundation.

The Two Structural Barriers

In nearly every established business where product transformation stalls, two barriers explain the failure. They are structural, not personal. Understanding them is essential because the interventions for each are different.

Barrier 1: Broken Trust

Development teams historically failed to deliver. This is not an accusation — it is a pattern. In many established businesses, the technology function was under-invested for years, led by managers rather than leaders, and measured on output rather than outcomes. The result was predictable: projects ran over, quality was inconsistent, and the business lost confidence in the technology team's ability to execute.

That loss of confidence created a cycle that persists long after the original causes have been addressed. The cycle looks like this:

In the worst cases, this cycle becomes adversarial. Engineering VPs actively work to prove that the product function is incompetent — not out of malice, but because decades of experience have taught them that product leaders come, make big promises, disrupt established processes, and leave when the transformation stalls. The rational response, from their perspective, is to resist.

Barrier 2: Transformation Fatigue

The second barrier is equally structural and even harder to overcome. Most established businesses have already attempted at least one transformation. Many have attempted several. And the data on transformation success is brutal.

Transformation fatigue manifests in specific, observable ways. Stakeholders agree to changes in meetings but do not alter their behaviour. Teams adopt new terminology but continue working the same way. Leadership endorses the transformation publicly but does not enforce it when it conflicts with existing priorities. The transformation becomes performative — the motions of change without the substance of change.

Why the CEO Must Champion the Shift

This is the uncomfortable truth that many product leaders try to avoid: without CEO conviction, transformation fails. It is not sufficient for the CEO to approve the transformation. They must champion it. The distinction matters.

Product transformation is not a product team initiative. It is a whole-company transformation. It changes how decisions are made, who makes them, and how success is measured. That scope of change can only be driven from the top. A VP of Product or CPO cannot unilaterally change the decision-making culture of an organisation. They need the CEO to say — publicly, repeatedly, and with consequences — that this is how the company works now.

The data supports this. Organisations where the CEO actively champions product-led ways of working are significantly more likely to sustain the change beyond the initial enthusiasm. Organisations where the CEO delegates transformation to the product leader — "I hired you to fix this" — almost always revert to their previous operating model within 18 months.

The Playbook: Six Steps to Earning Authority

The handbook contains the full playbook with detailed implementation guidance. Here is the structure and the reasoning behind each step.

Step 1: Secure CEO Sponsorship

This is non-negotiable. Before any structural change, you need the CEO to understand what product transformation actually requires and to commit to championing it. This is not a presentation. It is a series of conversations where you surface the hard truths about the current operating model, present the evidence for why change is necessary, and agree on what "championing" looks like in practice.

If you cannot secure genuine CEO sponsorship — not approval, sponsorship — you need to be honest with yourself about whether the transformation can succeed. Running a transformation without CEO backing is a career risk with very low probability of return.

Step 2: Diagnose Honestly

Surface the hard truths about the current state. This means talking to people across the organisation — not just the product and engineering teams, but sales, marketing, customer success, and finance. What does each function believe about the product team? What has their experience been? Where are the specific points of friction?

The diagnosis must be honest. If engineering teams have legitimate grievances about product leadership, those need to be acknowledged. If the business has valid reasons for not trusting the technology function, pretending otherwise will undermine everything that follows.

Step 3: Name the Anti-Patterns

One of the most effective techniques for breaking through transformation fatigue is naming the specific anti-patterns that are operating in the organisation. When people can see and name the dysfunction, it becomes harder to maintain it unconsciously.

The Age of Product framework identifies five empowerment anti-patterns that appear consistently in organisations struggling with product authority:

Most organisations operate under two or three of these anti-patterns simultaneously. Naming them explicitly in a diagnostic report gives the CEO and leadership team a shared language for the problems that need solving.

Step 4: Build Credibility Through a Pilot Team

Do not try to transform the entire organisation at once. Select one team, give them a meaningful problem to solve, grant them genuine autonomy, and support them intensively. The goal is to produce a visible, measurable success that demonstrates the product model works in your specific context.

The pilot team should be selected carefully. You need a team with capable people, a problem that matters to the business, and a stakeholder environment that is at least neutral (not actively hostile). Starting with the most dysfunctional team in the most political area is a common mistake. Start where you can win.

Step 5: Formalise Decision-Making

Once the pilot team demonstrates that the model works, formalise the decision-making framework. This means documented RACI matrices, explicit portfolio governance, clear escalation paths, and transparent prioritisation criteria. The goal is to make the "rules of the game" visible and agreed, so that shadow governance has no room to operate.

This step is where many transformations stall. The pilot team was a success, but extending the model requires structural changes that affect powerful people. The CEO's active championing becomes critical here — without it, the legacy power structures reassert themselves.

Step 6: Keep Existing Roadmaps During Transition

One of the most counterintuitive but important principles: do not throw out the existing roadmap when you begin the transformation. The organisation made commitments based on that roadmap. Customers are expecting features. Sales has made promises. Abandoning the roadmap on day one destroys whatever trust remains.

Instead, honour existing commitments while gradually shifting new work toward the outcome-focused model. This parallel running is uncomfortable — you are operating two models simultaneously — but it is far safer than the "big bang" approach that characterises most failed transformations.

Timeline and Success Metrics

Anyone promising faster timelines is either working with a very small organisation or underestimating the depth of the structural change required. Culture does not change in a quarter. Trust does not rebuild in a sprint.