If you've been in any strategy meeting in the last decade, you've probably heard of the 70 20 10 rule for innovation. It's tossed around as the golden ratio for growth. But here's the thing most articles don't tell you: most companies get it wrong. They treat it as a rigid budget mandate, a checkbox exercise that leads to frustration and, ironically, stifles the very innovation it's supposed to fuel.

After advising dozens of teams, I've seen the same pattern. The 10% "moonshot" projects get starved of real talent because everyone is "too busy" on the core 70%. The 20% becomes a dumping ground for slightly improved features. The result? Incrementalism wins, and transformative ideas die in committee.

So, what is the 70 20 10 rule for innovation, really? It's not just a spending rule. It's a strategic mindset and an operational framework for managing the inherent tension between exploiting your current business (which pays the bills) and exploring future opportunities (which ensure you have bills to pay in the future). It's about deliberately allocating resources—time, talent, and capital—across three distinct horizons of growth. Let's cut through the noise and build something that actually works.

Where the 70-20-10 Rule Really Came From

Credit often goes to Eric Schmidt, former CEO of Google, who popularized it in the mid-2000s as a model for Google's innovation time allocation. But the intellectual roots go deeper. It aligns closely with the Three Horizons Model developed by McKinsey consultants Mehrdad Baghai, Stephen Coley, and David White in their book "The Alchemy of Growth." That model frames growth across Horizon 1 (core business), Horizon 2 (emerging businesses), and Horizon 3 (new ideas).

The 70-20-10 rule operationalizes this thinking. Google's application was specific: 70% of engineering effort on core search and ads, 20% on related apps (like Gmail, which leveraged search for organizing emails), and 10% on wild cards (like Google Glass or self-driving cars, which became Waymo).

The key takeaway isn't the exact percentages. It's the recognition that different types of innovation require different management styles, metrics, and mindsets. Treating them all the same is the first mistake.

The Three Parts Explained: 70%, 20%, and 10% Demystified

Let's break down each bucket. Think of them not as siloed budgets, but as different types of work with different goals.

The 70%: Core Business Optimization

This is the engine room. The work here is about making your existing products, services, and processes better, faster, cheaper, and more efficient. It's focused on your current customers and markets.

What it looks like: Incremental feature updates, performance enhancements, cost reduction initiatives, scaling infrastructure, A/B testing for conversion rate optimization, and core maintenance.

The goal: Defend and extend your market leadership. Generate reliable cash flow that funds the other 30%.

The common trap: Letting this consume 95% of your energy because it's where the immediate pressure is. If you do that, you're mortgaging your future.

The 20%: Adjacent Innovations

This is the growth zone. Here, you're stretching your existing capabilities into new, related areas. It involves lower risk than the 10% but higher potential than the 70%.

What it looks like: New features that open up new customer segments (e.g., a business tier for a consumer app), applying your technology to a new industry, building new channels to market, or strategic partnerships.

The goal: Build the next wave of revenue growth. These projects should have a clear path to becoming part of the core 70% within a few years.

The common trap: Dumping "kind of new but not too risky" projects here without a real strategy. True 20% projects leverage existing strengths in a new way.

The 10%: Transformative or Radical Innovation

This is the frontier. These are the moonshots, the experiments that might fail but could also define your company in a decade. They often involve new technologies, new business models, or serving completely new needs.

What it looks like: Research into nascent technologies, exploratory projects with no clear business model yet, skunkworks teams building prototypes for futuristic concepts.

The goal: Learn about the future and plant seeds for long-term survival. The metric here is often learning, not revenue.

The common trap: Measuring these projects with the same ROI yardstick as the 70% projects. That's a guaranteed way to kill them. I've seen brilliant 10% ideas get axed in their first quarterly review because they couldn't show a profit forecast. That misses the point entirely.

How to Implement the 70 20 10 Rule in Your Organization

Okay, so you're convinced. How do you actually make it happen? It's a process, not a flip you switch.

Step 1: Audit Your Current Allocation. Be brutally honest. Track where your key people's time is actually going for a month. You'll likely find 90% is in core activities, 9% in firefighting, and 1% in anything new. This baseline is crucial.

Step 2: Define Your Buckets with Specific Goals. Don't just say "20% on growth." Be specific. "20% of our product team's capacity will be dedicated to exploring integrations with the healthcare SaaS ecosystem to access the enterprise segment by Q4."

Step 3: Create Distinct Processes for Each.
For 70% projects: Use your standard Agile or Scrum cycles. Prioritize based on ROI and customer feedback.
For 20% projects: Run them as dedicated mini-ventures. Assemble cross-functional teams with clear, medium-term objectives. Use a stage-gate process to decide if they graduate to core or get killed.
For 10% projects: Insulate them. Form small, autonomous teams. Fund them for a defined period (e.g., 6 months) to explore a specific question. Their deliverable is a "go/no-go" recommendation based on validated learning, not a shipped product. Resources like Harvard Business Review's work on discovery-driven planning are invaluable here.

Step 4: Communicate Relentlessly. Explain the "why" to everyone. The team working on the core 70% needs to know their work funds the future. The 10% team needs to feel permission to fail forward.

Step 5: Review and Rebalance Quarterly. This isn't a set-it-and-forget-it model. A successful 20% project should eventually move into the 70% bucket. A failed 10% experiment should free up resources for the next one. Be dynamic.

The 5 Most Common Pitfalls (And How to Avoid Them)

1. The Percentage Police: Enforcing 70/20/10 as a rigid, top-down mandate for every single team and department. A finance team's allocation will look different from an R&D team's. Apply it at the portfolio level.

2. Lip Service to the 10%: Calling something a 10% project but staffing it with junior people or making it a "weekend side project." If it's important, give it important people and protected time.

3. Using the Same KPI Dashboard: Measuring your 10% moonshot by its quarterly revenue contribution is like measuring a sapling by its fruit yield. You'll uproot it before it has roots.

4. Letting the 70% Cannibalize Everything: When a crisis hits in the core business (and it will), the instinct is to pull everyone back. You must have a non-negotiable agreement that a portion of resources is sacred for exploration.

5. No Pathways Between Buckets: If a 10% project shows amazing promise, how does it get more funding? If a 20% project fails, how does it wind down gracefully? Define the transition gates upfront.

Real-World Examples: Who Does This Well (And What We Can Steal)

Google (Alphabet): The classic example. Their 10% time policy for engineers is legendary, though its implementation has evolved. The key lesson is that they structured it to allow bottom-up innovation, leading to Gmail and AdSense. Today, Alphabet's structure (with Google as the 70%, Other Bets like Waymo and Verily as the 10%+) is the rule scaled to a corporate level.

Amazon: They execute this through their famous "two-pizza teams" (small, autonomous teams) and a culture of writing future press releases. Their 70% is relentless optimization of AWS and retail logistics. Their 20% might be expansions like Amazon Pharmacy. Their 10%? Projects like Project Kuiper (satellite internet) or their early experiments with drones. They are masters of using the cash from the 70% to fund massive, patient bets on the 10%.

A Small Software Company Case: I worked with a 50-person SaaS company. They dedicated one full-time senior developer and a part-time PM (about 15% of their capacity) as their "10% pod." Their charter was to explore AI automation for their service. In 9 months, they built a prototype that automated a key, manual customer onboarding step. It didn't generate direct revenue, but it proved feasibility. That project then became a 20% initiative, got more resources, and 18 months later, it became a core, paid feature—their 70%. That's the cycle in action.