Product Thinking Podcast — Episode 207: Mastering Predictable Product Success with the ODI Strategy featuring Tony Ulwick
Released: January 22, 2025
Host: Melissa Perri
Guest: Tony Ulwick, founder/CEO of Strategyn, inventor of Outcome-Driven Innovation (ODI), and pioneer of Jobs to be Done (JTBD)
Episode Overview
In this episode, Melissa Perri speaks with Tony Ulwick, a leading thinker in innovation and product development, about his journey creating Outcome-Driven Innovation (ODI) and how it enables organizations to conquer the unpredictability of product success. Tony shares the story behind ODI, its practical application, common misconceptions, and its strategic fit with modern methodologies like Agile and AI-driven innovation.
Key Discussion Points & Insights
1. Tony Ulwick’s Origin Story & The Genesis of ODI
- Tony recounts his formative failure at IBM
- Witnessed the major flop of IBM’s PC Junior, a billion-dollar investment meant to revolutionize home computing but quickly deemed a failure (05:18).
- “It was supposed to change the way people did home computing. It was supposed to beat Apple.” — Tony Ulwick [05:23]
- The fundamental question: “Is it possible to know way in advance how people are going to measure the value of your product?” (06:58)
- Inspired by Theodore Levitt’s classic jobs-to-be-done axiom:
- “People don’t want the quarter inch drill, they want the quarter inch hole.” (07:57)
- Early iterations at IBM:
- Tested various innovation methods but found no real process for innovation.
2. What is Outcome-Driven Innovation (ODI)?
- “If we study the job of creating the quarter inch hole as a process, we can apply all that same thinking and we can figure out how to get the job done better, faster, more predictably…” — Tony Ulwick [08:16]
- ODI Core Idea:
- People “hire” products to achieve specific outcomes. By analyzing those outcomes, organizations can systematically innovate.
Steps in the ODI Process (20:04)
- Define the Market
- Identify who the customer is and the job they are trying to get done.
- Understand Customer Needs via Outcomes
- Needs = metrics used by the customer to measure success (e.g., “minimize the likelihood of overcooking food”).
- Collect 75–125 such metrics for a given market.
- Quantify Unmet Needs
- Survey customers to determine which outcomes are unsatisfied.
- Analyze which needs are important but currently underserved.
- Outcome-Based Segmentation
- Segment customers according to unmet needs (not demographics or psychographics).
- “If you build for the average, you’re targeting nobody.” — Tony Ulwick [24:29]
- Develop Solutions via Ideation
- Use unmet outcomes to drive targeted product concepts.
Example:
- Cordis Corporation (Angioplasty Balloon):
- Applied ODI to identify a critical, unmet outcome (“minimize the likelihood of restenosis”), resulting in a product (“Heart Stand”) that became a billion-dollar business. [10:54]
3. ODI vs. Other Product Development Frameworks
- Misconception: Companies blend innovation and development processes, leading to confusion.
- ODI as the “front end” of innovation:
- Establishes high-certainty product concepts before development begins.
- Relation to Agile:
- ODI clarifies what should be built; Agile efficiently builds it.
- “ODI makes Agile more agile because you’re not iterating on what the product does while you’re creating it.” — Tony Ulwick [14:56]
- Critique of Lean Startup:
- “You’re trying to solve a very complex equation by hypothesizing the market, customer needs, and solution all at once… That causes you to iterate incessantly and you may never get out of that loop.” — Tony Ulwick [16:03]
- On Design Thinking:
- Useful as a toolkit for product development but not sufficient on its own to generate market-winning concepts.
4. The Importance of a Shared Definition of “Needs” and “Outcomes”
- Product teams frequently lack alignment on what a “need” is.
- “90% of product teams say, no, we don’t even agree on what a need is. Never mind what the needs are and which needs are unmet.” — Tony Ulwick [22:43]
- Recommend structured workshops wherein team members write their own definition of “need” to reveal misalignment and move toward a unified understanding. [27:06]
- Outcomes should be written as:
- Direction of improvement (typically “minimize”)
- The metric (time or likelihood)
- Object of control
- Contextual clarifier (if needed) [30:30]
5. Misconceptions and Execution Challenges with ODI
- ODI appears straightforward but requires a range of specialized skills (33:16):
- Project framing, qualitative/quantitative research, data analysis, strategic interpretation.
- Not every individual or product manager should learn all facets of ODI; instead, form cross-functional teams. [35:07]
- Product managers must at least understand what outcomes are and how to use outcome statements in their daily workflow.
6. When and How to Implement ODI in Organizations
- Teams under business unit heads or as specialized corporate teams are effective structures.
- Product managers and product teams should use ODI-informed outcomes for decision-making, not necessarily conduct the entire ODI process themselves. [35:07]
7. The Evolving Role of AI in Innovation
- AI opens opportunities to streamline ODI adoption, such as “synthetic outcome-driven customers” for rapid queries and simulation (37:26).
- ODI’s rules-based structure aligns well with AI, increasing predictability and efficiency in answering strategic product questions. [42:20]
- On AI-led rapid prototyping:
- While quicker iteration reduces building cost, guessing vs. “needs-first” remains inefficient:
- “What are the chances of you randomly coming up with a solution that addresses the top 15 unmet needs in the market? If you don’t know what they are, it’s zero.” — Tony Ulwick [39:14]
- “If you know exactly what those 15 unmet needs are in priority order… you’re going to get the job done better and succeed in the market.” [39:50]
Notable Quotes & Memorable Moments
- “Somebody has to decide what a need is, right? … An instruction that comes from a customer that tells you how to get the job done faster, more predictably, or without defects.” — Tony Ulwick [22:54]
- “If we can get the team to follow that path… they don’t all have to know how to do ODI. They just have to know that once they get that information, that’s the information they should use to drive their product decisions.” — Tony Ulwick [27:37]
- “If you build for the average, you’re targeting nobody, usually ineffectively.” — Tony Ulwick [24:29]
- “Vocabulary here is so important. We put a glossary of terms together that… shows how all these pieces fit together.” — Tony Ulwick [29:48]
- “With the advent of AI … there’s a lot of fun possibilities we’re thinking about… to help get the job done even better.” — Tony Ulwick [37:51]
Timestamps for Major Segments
- 05:18 — Tony discusses his formative product failure at IBM and motivation for innovation-as-science
- 07:54 — Inspiration from Levitt and the jobs-to-be-done framing
- 10:11 — Testing ODI at IBM and Cordis; the Heart Stand success story
- 14:21 — ODI vs. Agile vs. Lean Startup and Design Thinking
- 20:04 — Step-by-step run-through of the ODI process
- 26:53 — Facilitating organizational alignment on “needs” and outcome statements
- 29:08 — On writing good outcome statements
- 33:16 — Common pitfalls, required skillsets, and who should execute ODI
- 35:07 — Structuring ODI teams inside organizations
- 37:26 — The promise of AI in making ODI more accessible
- 39:14 — Why “guess-and-check” is wasteful even when iteration is faster
- 42:20 — Future trends, ODI, and AI compatibility
Conclusion
Tony Ulwick lays out not only the reasoning and architecture behind Outcome-Driven Innovation, but candidly addresses the challenges of implementation, the complementarity with agile approaches, and the conceptual clarity required for success. This episode offers practical, actionable insights for any organization looking to reduce risk in product strategy and move toward truly customer-centric growth—especially as AI unlocks new efficiencies without sacrificing foundational research.