JTBD and ODI have together been instrumental within 2023 in diving deep into a business domain I had zero prior experience in. Judging from my validation rounds earlier this year, and the continued maturation of my understanding of that domain thanks to the groundwork I laid back in January to March 2023 with JTBD and ODI, I can confidently claim that the diligent application of these frameworks has delivered on their promises.
Note
Jobs To Be Done (JTBD) is a framework developed by the late Clayton Christensen and popularized in “The Innovator’s Solution” and focuses on understanding the underlying reasons why customers “hire” a product or service to get a job done (i.e., to accomplish something specific) in their lives, and thus helps you to identify, understand and address customers’ motivations and what they value.
Note
Outcome-Driven Innovation (ODI®) is a framework developed by Tony Ulwick and represents a systematic approach and structured process for defining customer needs, translating them into measurable outcomes, and using these outcomes as the basis for innovation, by emphasizing desired customer outcomes.
I’m not one to hype things up, and so I’ll put it simply: JTBD and ODI are solid. They are excellent tools for understanding customers, the things they struggle with, and their subjective definitions of value, and can help you explore options for serving some of those needs in ways that customers will appreciate.
If you want to get started, the ODI content by Tony Ulwick is, in my experience, the reference, go-to material. “When Coffee & Kale Compete” by Alan Klement is a nice addendum. I am aware that there is some drama going on, as these two sources disagree on a few things on a philosophical level; however, there is merit in studying both, and there is nothing to be gained by picking sides. Alan’s book is a gentler, fluffier, almost mindset-focused introduction to the field. Tony’s material is more structured and usable in practice.
The canvas conundrum
Also, my advice is to set aside Strategyzer’s “Value Proposition Canvas” , at least when starting out. The canvas and the way it’s presented in the “Value Proposition Design” book represent such a watered-down interpretation of JTBD/ODI, that it’s useless for anything beyond the first super-rough cut of your exploration. It’s certainly better than nothing when starting out, but not by much.
This isn’t a “hot take”, but a take based on experience. I’ve used the canvas at Hilti as part of a new process I developed for service product development and, given the company’s historical (up until ca. 2014) focus on predominantly tangible offerings, it proved useful for engaging people with strong and diverse options in productive discussions and teamwork, and for questioning prevailing assumptions about why customers would purchase a service product from the company beyond hand-wavy, brand-based justifications.
Strategyzer’s canvas was also useful enough while I was at Proceq (now part of Screening Eagle Technologies ), for collaboratively identifying value proposition elements of software-enabled sensor-equiped product systems, such as Proceq UT8000 portable ultrasound flaw detector and its companion iPad app . In that specific case, the shift from discussing design and specification to discussing what “jobs” the customer is “hiring” the product system (platform, sensors and app) through a subscription, instead of going with the incumbent’s offering, was instrumental in turning around a flailing project with a team bogged down in cross-functional disagreements.
Curiosity as the driving force
Why, then, I am advocating not starting out with the canvas?
Simple: because, as it turns out, the canvas by itself was not the important element of success. Rather, my experience has been that the canvas, with it’s visual and engaging form, is merely a conversation starting point, and the need to simplify JTBD/ODI to create a collaboration-friendly canvas means that the simplification of “jobs” into three types (functional/emotional/social) that look good on the canvas doesn’t do JTBD/ODI justice, and will hold you and your team back from looking at nuances – and it’s the nuances we are looking for, not the “obvious” stratospheric-level observations that can be captured through basic interviewing with a few domain experts.
In other words. the most important part of the Strategyzer book is not the canvas itself or the book’s watered-down version of JTBD, but everything else around how to iterate on the domain under investigation. That, yes, is a mindset shift that especially incumbents most likely need, to get out of their navel-gazing rut. The Strategyzer-popularized approach at gradually uncovering insights plus the actual JTBD/ODI methods and tools, together, are what can help you “read between the lines”.
Regrettably, too much emphasis is placed on the cute and inviting canvas instead of the way it can be used as “training wheels on the bike” of developing value propositions, especially in organizations that have gotten used to getting too far too fast with heavyweight documents on Requirements nad Specifications documents (the dreaded “Lastenheft” and “Pflichtenheft” in the German-speaking regions), long before desirable and valuable value propositions have been crafted, and uncertainties have been uncovered.
In any case, with or without a canvas, JTBD/ODI live and die by the degree to which you and your team are deeply curious about the domain you are exploring. No amount of pretty spreadsheets, canvases or other tools will cover for any lack of serious interest in figuring things out, and being ready to learn things that might sometimes go against your expectations and intuition.