🎯 Why Innovation Governance
Innovation governance is the set of structures, processes, and roles that define how an organization makes decisions about where to invest, what to continue, what to kill, and how to allocate people and budget across innovation projects. Without them, innovation is a lottery: some projects move forward because of their owner's political clout, not their merit; others die in bureaucracy before proving anything.
📊 The cost of lacking governance
- ✗ Zombie projects: initiatives with no clear results that consume resources for years because no one has the courage to kill them
- ✗ Invisible duplication: three teams solving the same problem without knowing about one another (common in companies with >500 employees)
- ✗ Unbalanced portfolio: 100% in the core (H1), zero in H2/H3, the company wakes up disrupted in 5 years
- ✗ Decisions by hierarchy: the VP’s project moves forward, while the analyst’s dies — regardless of which has more potential
📈 Data that justifies the structure
- • Companies with formal innovation governance generate 2.7x more return on R&D investment (BCG Innovation Survey, 2023)
- • 68% of corporate innovation programs are discontinued for lack of clear decision criteria (McKinsey)
- • Teams with an active innovation committee deliver projects 40% faster through reduced ambiguity (HBR, 2022)
- • Amazon attributes part of AWS’s success to a structured decision-making mechanism (“two-pizza team” + 6-page review)
💡 Governance is not bureaucracy
The most common criticism is: "governance will stifle innovation." That’s true of poorly designed governance—heavy, slow, with cascading approvals. Good innovation governance does the opposite: accelerates by eliminating ambiguity, protects projects involving political interference and releases teams that experiment within clear limits. The difference lies in the design of the mechanisms, not in whether they exist.
👥 Committees, Sponsors, and Roles
The backbone of innovation governance consists of three layers of roles: who sponsors (provides legitimacy and resources), who decides (evaluates and approves), and who executes (delivers results). Confusing these roles—or leaving them vague—is the number one reason projects die in internal politics.
Executive Sponsor (C-level)
Layer 1 — Legitimacy and political protection
The sponsor isn’t window dressing. They remove systemic obstacles the team can’t remove: unlock the budget during crises, protect the program from short-term cuts, and signal to the rest of the organization that innovation is a real priority. Without an active sponsor, the program disappears at the first change in leadership. Companies like Natura and Magazine Luiza credit the continued presence of a C-level executive as champion for the longevity of their programs.
Innovation Committee
Layer 2 — Decision-making and portfolio balancing
The committee has a clear mandate: evaluate projects at the gates, allocate resources, rebalance the portfolio, and—crucially—make kill decisions. Ideal composition: representatives from business, technology, finance, and operations. Monthly meetings (not weekly—an overburdened committee brings progress to a halt). Document every decision with its criteria, so teams understand the "why," not just the "what."
Innovation Manager (Innovation Lead)
Layer 3 — Orchestration and enablement
The Innovation Lead is the program’s day-to-day manager. They prepare teams for the gates, facilitate rituals, connect projects that could build on each other, monitor funnel metrics, and report to the committee. They’re not the person with the ideas — they create the conditions for ideas to emerge and move forward. A role equivalent to Chief Innovation Officer at larger companies.
Innovation Teams
Layer 4 — Execution and learning
Small teams (ideally 4-6 people), multidisciplinary, with real autonomy within the limits set by the gate. Responsible for formulating hypotheses, running experiments, documenting learnings, and presenting results to the committee. The key is autonomy with accountability: the team decides HOW, the committee decides WHETHER to continue.
⚠️ Trap: Approval Committee vs. Support Committee
There is a critical difference between a committee that approves each step (bureaucracy) is a committee that supports e decides at the gates (governance). The first requires validation for everything — weekly meetings, long presentations, paralysis. The second intervenes only at defined inflection points. Approval committees send teams spending 90% of their time in PowerPoint, not on experiments.
🔌 Stage-Gate Funnel vs. Lean Approach
The debate between the Classic Stage-Gate (Robert Cooper, 1990) and the lean funnel approach (inspired by Lean Startup + Design Thinking) and is one of the most relevant approaches in modern governance. The right answer isn't to choose one or the other — it's to understand when to apply each logic and how to combine them without creating dysfunctional hybrid monsters.
💡 Hybrid Approach: the best of both worlds
The most advanced practice is to use Lightweight Stage-Gate for H1 (where predictability and scalability matter) and iterative lean funnel for H2/H3 (where uncertainty is high and the cost of error needs to be low). H2/H3 gates assess learning — "did we validate the hypothesis?" — not deliverables — "is the document ready?" Google uses exactly this model: OKRs for core projects and "20% time" without a formal gate for exploration.
⚖️ Kill / Continue / Pivot Decisions
The ability to kill projects without drama and the superpower of innovation governance. Organizations that can’t kill projects accumulate a “zombie portfolio” — undead initiatives that consume resources without delivering anything. The problem isn’t a lack of individual courage; it’s the absence of pre-agreed criteria and a clear process to make these decisions.
Continue
Criteria for advancing to the next stage
- • Main hypothesis validated with real data
- • At least 10 customers/users tested it
- • Team demonstrates learning, not just execution
- • Next experiment clearly defined
- • Resources needed are proportional to the current risk
Pivot
When to change direction, not close
- • Problem validated, but the solution was wrong
- • A different-than-expected segment has greater demand
- • Original distribution channel doesn’t work
- • Technology enables a better approach
- • Team believes in the problem, not the current solution
Kill
When to close with honor and without drama
- • Central hypothesis refuted by clear evidence
- • Market smaller than the minimum viable size for the business
- • Team can't recruit customers even with an incentive
- • Unit economics impossible to make work, even after optimization
- • Strategic shift made the problem irrelevant
📈 “Kill It Well” — How to End Without Stifling
Healthy wrap-up rituals
- • Structured postmortem: what did we learn? What works for other initiatives?
- • Celebrating learning: Amazon and Google celebrate “productive failures” at all-hands meetings
- • Hypothesis repository: project insights remain accessible to future teams
- • Dignified redeployment: the team is valued and reassigned, not punished
The mistake that prevents the kill
Companies don’t kill projects for three main reasons (MIT Sloan, 2021):
- 1. Sunk cost: “we’ve already invested too much to stop now” — a costly logical fallacy
- 2. Political protection: the VP's project cannot be killed by the manager
- 3. Lack of criteria: without a pre-agreed KPI, any result is "promising"
💵 Budgeting and Portfolio Management
Budget allocation is the more political decision of innovation governance. Everyone wants H1 money (predictable, clear ROI) for H3 projects (high uncertainty, distant ROI). Without a structured portfolio management model — explicitly dividing investment among core, adjacent, and transformational initiatives — the innovation budget will always be the first victim of any financial contingency.
✓ Allocation Best Practices
- ✓ Budget separated by horizon: a specific budget line for H1, H2, H3—not a single "innovation" fund
- ✓ Funding in tranches: small initial investment, with a larger tranche only after the hypothesis is validated (reduces risk)
- ✓ Metrics differentiated by H: H1 = ROI/payback; H2 = NPS + growth; H3 = learning + options created
- ✓ Quarterly review: rebalance allocation based on results instead of waiting for the annual budget
✗ Mistakes That Destroy the Portfolio
- ✗ Measure H3 projects with H1 KPIs (immediate ROI) — it kills 100% of long-term bets
- ✗ Taking budget from H2/H3 to “plug a hole” in the core business during a crisis — leaves the company more vulnerable in 3 years
- ✗ Overly concentrated portfolio: 20 tiny projects that never scale vs. 3–5 real bets
- ✗ Not communicating the portfolio to the board — without visibility, the investment looks like "spending with no return"
📋 Portfolio Model: Core / Adjacent / Transformational
Optimize, improve, and defend the existing business. Expected ROI in 0-12 months. Metrics: incremental revenue, efficiency, NPS, market share. Low risk. Amazon example: logistics improvements, category expansion, faster Prime.
Expand into adjacent markets or capabilities. Projected ROI in 1–3 years. Metrics: new users, conversion rate in the new segment, partners activated. Medium risk. Nubank example: expansion into insurance and investments from its account customer base.
Create new businesses and markets. Projected ROI in 3-7 years. Metrics: validated hypotheses, options created, strategic learning. High risk, exponential returns. Natura example: incubating digital wellness brands that weren’t in the original portfolio.
💡 The portfolio as a narrative for the board
The innovation committee needs to present the portfolio to the board as one coherent whole, not project by project. The narrative is: "we have X% of revenue protected in the core, Y% invested in adjacent areas that should mature in 18 months, and Z% in long-term exploration." This turns innovation from a "cost center" into a "portfolio of strategic options"—language the board understands and values (BCG, 2022).
⚖️ Balance: Control vs. Autonomy
The tension between control and autonomy and the central paradox of innovation governance. Too much control stifles it: the best innovators leave, bureaucracy takes over, and projects become too conservative. Too much autonomy leads to fragmentation: resources are lost to exploration without convergence, the portfolio loses coherence, and the committee loses visibility. The goal of mature governance is to maximize autonomy within well-designed constraints.
⚖️ The Control Spectrum
Approval for everything
Teams without decision-making authority
Analysis paralysis
Ideal zone
Autonomy within guardrails
Gates at inflection points
Zero accountability
Incoherent portfolio
Scattered resources
✓ Autonomy with Guardrails
- ✓ Define the problem, release the solution: the committee chooses the strategic challenges; the teams choose how to solve them
- ✓ Micro-funding: teams receive a small budget without a gate; a higher gate unlocks more resources
- ✓ Exploration OKR: the expected outcome is learning, not the product—which frees the team to fail fast
- ✓ Radical transparency: a portfolio dashboard visible to everyone — creates accountability without micromanagement
✗ Signs of Imbalance
- ✗ Teams spend more than 30% of their time preparing presentations for the committee (too much control)
- ✗ No project has been closed in more than 6 months (too much autonomy / no criteria)
- ✗ Top talent avoids the program (“too much politics”)—a classic sign of bureaucracy
- ✗ Portfolio has more than 15 active projects at the same time for a team of fewer than 50 people
🌟 Reference cases: how companies calibrated the balance
"20% time" for free exploration (autonomy), OKRs and monthly reviews for large-scale projects (control). Result: Gmail, AdSense, and Maps were born from 20%.
Amazon
“Two-pizza team” (small-team autonomy), mandatory “6-pager” before any decision meeting (structured control). No PowerPoint, no ambiguity.
Nubank
Autonomous “squads” with a clear mission (autonomy), quarterly chapter reviews, and a “tech radar” to align technology (lightweight control). Scaled from 3 to 300 squads while maintaining agility.
📋 Module Summary
Next Module:
3.10 - Community of Practice