Outcome-Driven Innovation for Product Managers

BY CHRIS MASSEY ON JANUARY 23, 2017

Tony Ulwick is a pioneer of jobs-to-be-done theory, the inventor of the Outcome-Driven Innovation® (ODI) process, and the founder of the strategy and innovation consulting firm Strategyn. In this talk at ProductTank San Francisco, he shares how jobs-to-be-done theory and the Outcome-Driven Innovation (ODI) process are being used to help startups, Fortune 100 companies, and others be significantly more effective at creating customer value and creating breakthrough products and services.

Start with the need

Innovation is the process of producing solutions which satisfy unmet needs. Traditional innovation is ideas-led and Tony argues this is a guessing game of fail-fast, pivot-often. Despite this being the innovation method used by most major companies, product success rate here is around 5%. The alternative is needs-led innovation.

What is the Job-To-Be-Done Framework?

Outcome Driven Innovation defines customer needs as Jobs to be Done (JTBD). By viewing innovation through a Jobs to be Done lens, we can see that the value of an innovation is in how it helps us to get the jobs we need to do, done. Most importantly, the job in this model is not at all married to a specific product. This new lens leads to more comprehensive understanding of the needs we seek to satisfy and changes the way we define markets.

The market is not the product

With clear examples from the music industry, Tony demonstrates how markets are defined by the Job to be Done, not by the products that do them. In the Outcome Driven Innovation model, the market is the group people who wish to carry out the job. Products create value in the marketplace based on how well they do the job better than other iterations or alternatives. Tony introduces the Outcome Driven Innovation (ODI) Job Map which allows product managers to define, size, research, and locate the market and which forms a predictive model for the future growth and evolution of solutions in your marketplace. The envisioned future of your company should be to enable customers get their job done better and better over time. This kind of thinking roots the definition of the market firmly in the customer need and away from specific products.

Using outcome statements

The Outcome Driven Innovation model frames customer needs as Outcome Statements which have direction, metric, object and context. Crucially, these customer needs are actionable but free from solutions. Eventually, they will become a means of measuring product value: How well does your product help get the job done better?

Of course it’s also worth bearing in mind that you may well have multiple customers whose needs you’re trying to address – the buyer might be a completely different person from the the actual product user, who is themselves a different person from whoever has to maintain the product (particularly in a business context). Your challenge as the product manager is to understand the Jobs that each of those personas is trying to get done, and work to meet their needs.

Unmet needs drive strategy and growth

Which of the needs identified in your outcome statements are most important and which are unmet?

“If a need is both important and poorly satisfied it represents an opportunity for innovation and growth”

Strategy in the ODI model is about looking at this opportunity landscape and finding needs which are high importance / low satisfaction. Precision is needed to work out exactly where in that landscape to focus to create value.

The crucial thing to take away from all this is that Outcome Driven Innovation reveals previously hidden segments of opportunity. When we see these segments and their needs with greater depth and clarity, opportunities arise for growth through more intelligent marketing and product innovation, which is something we should all aspire to.

About CHRIS MASSEY

Chris Massey has been marketing B2B software products to developers for 8 years, building communities, content and publishing platforms along the way. He's an editor for Mind the Product, as well as a fan of JTBD, JFDI, and JEDIs.

  • A “job to be done” is not the only form of need. Actually, a JTBD is the context in which a problem or unmet need occurs.

    It is always possible, in principle, for a user to “get a job done” or achieve a functional goal. For example, the JTBD might be delivering a gift to someone in the Sahara Desert. Almost anyone can get this job done. We can take a plane, fly as close as we can to the Sahara Desert, stock up on plenty of water, and walk to the destination to hand-deliver the gift.

    The question is how challenging it is. Does it take too long? Is it too cumbersome and unpleasant? Is it unsafe or risky? Is it too expensive? The JTBD is just the context in which we ask these questions.

    While the outcome-based innovation and JTBD are all the rage these days, Alistair Cockburn addressed them back in the 1990s with “structuring use cases with goals”. Use cases represent the functional goals or JTBDs. Use cases have preconditions, postconditions, and invariants. The conditions represent the problems that users want solved, or to avoid, in the context of getting the job done. They are the nonfunctional requirements, and they’re the most interesting.

  • Nice article Chris, thanks. I have one question…

    Who, in your view, defines the solution?

    In my experience, there is usually an ongoing battle between product managers, business analysts and developers who are waiting for each other to define a clear solution to the problems (or usually a request to handle the ‘job to be done’) from the market. There’s also issues whereby the customer thinks they know the solution but don’t

300 Shares
Share
Share
+1
Email
Tweet