Twin Turbine Product-Ops
"Uber always has this mentality and Opendoor does too of like a twin turbine jet plane where you can fly the plane on one engine for a little bit if you need to, but it's operating most efficiently and effectively if both are working together." - Brian Tolkin
What It Is
The Twin Turbine model is a mental framework for thinking about the relationship between product/engineering and operations teams in companies with significant operational components. Like a twin-engine jet plane, both engines (product and ops) need to work together for the business to operate at peak efficiency.
Operations teams can iterate faster, scale customer conversations efficiently, and gather rich qualitative insights from the field. Product teams bring scalable technology solutions. Neither can substitute for the other—they must operate in harmony.
The key insight is reframing the relationship from competition to symbiosis. Product teams often look down on ops teams as doing things that "don't scale," while ops teams may feel like they're doing the real work while product sits in San Francisco. The twin turbine model encourages both teams to see themselves as complementary engines driving the same plane forward.
How It Works
Operations Turbine Strengths:
- Iterates faster than building software
- Scales customer conversations efficiently
- Gathers deep qualitative insights
- Understands local market nuances
- Can experiment quickly in the field
- Provides real-world feedback on what's working
Product Turbine Strengths:
- Builds scalable technology solutions
- Creates leverage through automation
- Handles high-volume transactions
- Provides consistency across markets
- Enables global reach from centralized teams
The Harmony Point:
- Operations provides insights that inform better products
- Product builds tools that multiply operational efficiency
- Feedback loops run in both directions continuously
- Local experimentation feeds global product decisions
- Technology reduces operational burden over time
How to Apply It
Foster mutual respect - Both functions must recognize the other's value. Operations isn't just "things that don't scale"—it's a Petri dish for innovation. Product isn't just "ivory tower builders"—it's the leverage engine.
Create bidirectional feedback loops - Build formal mechanisms for operations insights to reach product teams, and for product updates to reach operations. Consider creating a Product Operations function to bridge this gap.
Be intentional about tech investment - Identify where technology creates the most leverage given scarce resources. Early Uber focused engineering on dispatching and pricing—the core value creation—not on every operational process.
Accept entropy - The real world is messy. Build products with flexibility and fail-safes because humans aren't deterministic like computers. GPS fails, drivers cancel, homes aren't as described.
Evolve the balance over time - Early stage, more ops-heavy. As you scale, technology takes over more processes. The ratio shifts, but both engines always matter.
When to Use It
- Building products with significant real-world operational components
- Structuring product and operations organization relationships
- Deciding where to invest engineering resources vs. operational resources
- Resolving tension between centralized product teams and distributed field teams
- Evaluating whether to automate a process or keep it human-driven
Source
- Guest: Brian Tolkin
- Episode: "Lessons from scaling Uber and Opendoor"
- Key Discussion: (00:00:03) - The twin turbine metaphor and product-ops harmony
- YouTube: Watch on YouTube
Related Frameworks
- Product Operations Function - The organizational solution to bridging product and ops
- Do Things That Don't Scale, Then Scale Them - The evolution from manual to automated
- Tech Leverage Identification - Finding where technology creates the most value