samarv Innovation often stalls because teams lack the explicit "permission to think" or are paralyzed by a fear of failure. This framework provides specific mechanisms to bake high-variance, big-thinking bets into the standard operating rhythm of a product organization.
1. The Annual "Crazy Ideas" Ritual
Establish a low-stakes, high-reward channel for radical ideas that don't fit into standard roadmaps.
- The Prompt: Create a company-wide document titled "Crazy Ideas." Define these as ideas that have a 90% chance of making no sense, but a 10% chance of making a 10x to 100x difference to the business.
- The Format: Keep it unstructured. Allow bullet points, demos, or brief memos.
- The Follow-up: Review the previous year’s doc during annual planning. Aim to fund and execute 3-8 items from the list.
- The Funding Model: Treat these as internal startups. Assign 1-2 people (e.g., one engineer and one designer) for the first six months. Do not scale the team until they prove ROI in engagement or revenue.
2. The "20% Think Bigger" Planning Filter
Force teams to look beyond their current resource constraints during every planning cycle.
- The Charter Addition: Add a mandatory "Think Bigger" section at the bottom of every team charter or planning document.
- The Key Questions:
- "If you had 20% more time/resources, what would you do that isn’t already on this roadmap?"
- "If we doubled your team size today, what would you change about our strategy?"
- The Goal: Surface high-impact opportunities that are being suppressed by "treading water" with technical debt or urgent bugs.
3. The "Scooter" Implementation Model
When building new products or big bets, avoid the "axle" trap. If you are building toward a "car," don't build non-functional parts (the axle) first. Build the "scooter"—the simplest functional version that allows a user to complete a value-added task.
- Vertical Slicing: Instead of building a general-purpose platform, build a specific slice for a niche use case.
- Example Application: If building a mobile app platform, don't build a general builder first. Build a specific tool for "Field Workers doing Inventory Management."
4. Guidelines for Protecting Innovation
- Build for the Best User: Do not design early-stage products around abuse cases or "worst-user" behaviors. Focus entirely on the user who "gets it" immediately. Optimize for the "best user" first; deal with abuse only when the scale makes it a "good problem to have."
- Isolate New Bets: Keep innovation teams separate from core product teams early on. Do not let them get bogged down in the maintenance, bugs, or standard processes of a product that already has Product-Market Fit.
- Normalize Failure through Public Learning: Replace "Post-mortems" with "Retrospectives." When a big bet fails, have the team write a "Learnings Note" and share it via company-wide channels (e.g., a "Shipped" email list or All-Hands) to celebrate the insight gained rather than the outcome.
Examples
Example 1: Expanding Product Scope
- Context: A team is focused on building a front-end UI builder.
- Input: The "Crazy Ideas" doc suggests users need to run scheduled tasks, but it doesn't fit the "UI builder" identity.
- Application: Fund a "Two-Person Startup" (1 PM, 1 Eng) to build a "scooter" version of a workflow engine.
- Output: The launch of a "Workflows" product that expands the company's TAM from UI building to full business logic.
Example 2: Planning with the "Think Bigger" Filter
- Context: A team is 100% booked with "Urgent" tech debt and bug fixes for the next quarter.
- Input: The "20% more time" question reveals the team has a vision for an AI-driven automation feature but didn't think it was "allowed."
- Application: The Lead identifies the vision, re-prioritizes 20% of the tech debt to the following quarter, and gives the team permission to prototype the AI feature.
- Output: A high-impact demo that secures permanent funding for an "AI Automation" pillar.
Common Pitfalls
- The "Process Average" Trap: Applying the same heavy templates and review cycles to "Crazy Ideas" as you do to core products. This brings high performers down to the average and kills creativity.
- Over-Engineering the MVP: Building the "axle" (the complex backend for a 3-year vision) instead of the "scooter" (a functional tool for a 3-week test).
- Worrying about Abuse Too Early: Adding friction to onboarding to prevent "bad users" before you've even proven "best users" want the product.
- Lack of Air Cover: Failing to "break the org" for a high-performer. Some innovators need to be exempt from standard processes to do their best work; managers must provide the air cover for this.