Abstract

In the last few months, we’ve been working to integrate Ulwick’s Jobs To Be Done theory into our platform design framework. We’re doing so because of many reasons: first, ODI (Outcome-Driven Innovation) is a powerful tool and is very much adopted across the world by many innovation practitioners, secondly, it has given us a very pragmatic way to frame platform strategies inside our customers’ innovation context.

It’s important indeed to underscore how the approach behind ODI and JTBD is indeed very useful to frame how a platform strategy fits into a market of existing alternatives that serve entities that are currently engaging with problems and opportunities in the ecosystem: in a few words reconnecting with this approach has helped us bring the very systemic insights that ecosystem scanning and platform thinking gives back into a “customer” perspective of problems to be solved and outcomes sought by participants.

In this short post, we’ll share our first insights into how we are integrating both frameworks, and look forward to our practitioners for comments. Feel free to reach out if you have any experience in integrating the two. We always keep our users posted with our methodology’s progress, therefore subscribe to our newsletter if you don’t want to miss a thing!

A special thanks to Alessandro Fontana and Luca Ruggeri for collaborating on this update!

---

From Core Functional Jobs centered around one Customer to Core Systemic Jobs (as Arenas) centered around relationships: adopting the universal job map

As the loyal readers will know from our earlier post on Defining the Ecosystem Domain: Ecosystems, Arenas and Jobs-to-be-done at Boundaryless we’ve recently extended our exploration framework with the concept of Arenas, and we preliminarily linked that with the idea of Jobs to be Done. After further discussion and research, we’re testing a stronger integration between the two frameworks.

Note that most of the nonoriginal pictures on this page are taken from the excellent free download book: Jobs To Be Done: Theory To Practice by Anthnoy W. Ulwick.

A key element in ODI is the core functional job-to-be-done. According to Ulwick, the core functional job-to-be-done is “job the end user is trying to get done” and is normally articulated across eight steps that are described in the universal job map that was first introduced as “The Customer-Centered Innovation Map” (Ulwick and Bettencourt) in a well known Harvard Business Review article. According to Ulwick. the universal job map is “a visual depiction of a functional job, deconstructed into its discreet process steps” :

According to Ulwick this “job structure” is based on widespread research and represents at best what are the common steps of executing a certain job.

Furthermore, in ODI’s framework, the core functional job is normally complemented by: related jobs, emotional and social jobs, consumption chain jobs, and the buyer’s financial desired outcome. For details around these concepts, we remind the reader that the book “Jobs To Be Done – Theory to Practice” is available as a free download here.

Another key element of ODI practice is the identification of the desired outcomes that are related to each of the steps of the Job map.

According to ODI, numerous desired outcomes statements can be related to each step of the core functional job and give a much stronger understanding of what the customer is actually looking to achieve during the execution of the job.

The first experimentation we’re taking at Boundaryless is to use the universal job map as a potential way to frame the content of an arena. As we have introduced in our recent post on Defining the Ecosystem Domain: Ecosystems, Arenas and Jobs-to-be-done we frame ecosystems from the perspective of systemic jobs: we normally don’t focus around a single customer but always look at the execution of a certain Job as based on interactions.

We normally proceed through a two-step ecosystem breakdown:

In our approach and technique of ecosystem domain mapping, we often speak of arenas, instead, as being characterized by “clusters of jobs to be done“, where these clusters involve different entities in interaction. Such clustered interactions around somehow relational jobs-to-be-done are to be seen as producing certain continuous systemic outcomes. 

In recent experimentations we are using the frame of the universal job map as a way to frame the content of each arena: the key difference between traditional ODI’s approach and ours is in that we call the job a “core systemic job” (the arena) to stress out that we aim at mapping the whole set of ecosystem entities involved. Furthermore, we map each job’s step (arena’s step) visually on the three layers of the Ecosystem Scan as we are used to doing. For each of the entities involved in the interactive step we then map desired outcomes, similarly to what Ulwick suggests, but keeping in mind the multiple points of view.

In a new version of the Arena Scan (see below draft 0.2, which you can download here) the reader can see how we’ve updated the definition of Arena as a “systemic job”: we haven’t embedded the names of the 8 steps of the universal job map in the schema because we think that those phases are not always present, and furthermore, due to the very systemic nature of the Arena, we believe that constraining the mapping to a particular structure may be too limiting.

Having said that we recognize that the 8 steps of the universal job map provide a powerful framing and we encourage the users to keep that structure in mind when mapping what happens during the execution of a systemic job.

 

Enrich Ecosystem Scans and Entity portraits by linking them to desired outcomes in the context of core systemic jobs

Adopting a universal job map to map out the experience the entities are currently involved in and extending the traditional Ecosystem Scans including a link – for each of the entities, during each of the phases – to the list of desired outcomes is a powerful complement to the basic practice. It will give practitioners not only a picture of what’s currently happening in the ecosystem but also how this response to the entities’ expectations. It’s good practice then – to understand what an entity is looking for – not only to use the Entity Portrait but also the list of situated outcomes related to the particular steps comprising the arena.

The Entity-Role Portrait will indeed provide a synthetic description of the entity’s context, and help you extend the traditional idea of “personas” with a more scalable and generalizable way of framing the user, but also with a direct reference to the three types of key gains that one needs to deliver in a platform context: not only the general value gains (freedom, actualization…), and the convenience gains (doing things faster, cheaper, easier) but also the gains related to scope, and connecting with the right “niche” a trait that is essential to platform value propositions (that of customization and personalization). On top of that, mapping the list of desired outcomes that all the players involved in each step of the arena/systemic job execution are looking for will provide a rich complement that is situated in a particular moment of the experience.

Opportunity Segmentation

ODI approach can come in handy again when it comes to choosing where to start “platformizing” the ecosystem. in the Jobs To Be Done book Ulwick provides readers with an approach for opportunity segmentation based on an approach called Outcome-Based SegmentationTM . With that one can understand how different clusters of users value certain outcomes and how satisfied they are with the processes they’re currently using to respond to those needs. According to Ulwick, such outcome-based segmentation is much more powerful than traditional persona-based (qualitative) or other quantitative approaches and we tend to agree.

According to such an approach in ODI one should be able to identify what innovation strategies are available (see the map below) and craft a market and product strategy accordingly for each segment of users based on the outcome-based segmentation.

The application of the quantitative analysis to the outcome-based segmentation will give practitioners a good idea of which of the steps of the arena experience is the most problematic and those that make the case for a platform strategy. Often indeed, when mapping an ecosystem we’ve been finding ourselves overloaded with opportunities, relationships, and phases while at the same time conscious that a platform strategy needs to start from a core focus (around a specific relationship and some core steps) to later expand. This has been for example the experience of Airbnb that started from a core experience and focus (renting a room/mattress) and evolved into now a complex set of interlaced value propositions (experience booking, professional room rentals, co-hosting, etc…).

One possible way to adopt outcome-based opportunity segmentation in this context – and one that we’re increasingly using – could consist of:

• mapping all outcomes in each arena;
• performing the quantitative analysis (as described in the ODI book, through surveys and similar techniques);
• understanding which arenas/systemic jobs among the ones mapped have the greatest set of currently problematic experiences for users (mainly overserved and underserved).

Why focus on overserved and underserved customers? Platform strategies can be widely competitive, especially in two spaces: charge less and get the job done better. 

How can a platform strategy enable you to “charge less”?

• by providing a product bundle (often a SaaS) that reduces the cost of executing the business process;
• by allowing into the market otherwise not active producers that can effectively charge less in an attempt to either gain reputation or even fill a particular niche of low spenders;
• by mobilizing dormant inventory (underutilized fixed assets).

How can a platform strategy enable you to “get the job done better”?

• by providing a streamlined productized experience of the core business workflows automatizing otherwise distracting aspects (through the core product bundle);
• by connecting the users with the “right half of the apple” (the right producer for the right consumer, connecting long tails);
• by providing – for example – demand generation on top of a product bundle;
• by providing plug-ins, extensions, and apps to complement a core set of functionalities through an extension platform pattern.

If we look at the picture below (from our recent Value Propositions in Business Ecosystems – Products, Marketplaces, Extensions) we also need to take into account the usual patterns that platforms use in getting the compounding value propositions to the market.

If we think about starting from a SaaS (or product bundle) to later activate an extension platform or a marketplace (or potentially both) we’re probably going to start from a Disruptive strategy and then move into a dominant strategy. This could be for example resonant with what OpenTable did, by providing a table-management SaaS first (to substitute more complex/costly solutions or processes for small restaurants) and then moving into generating demand through a marketplace to achieve a dominant strategy (cheaper, providing more value).

If instead, we think of providing a demand aggregation marketplace first we’re probably starting from a marketplace that can charge less in terms of customer acquisition cost (alternatives for demand generation such as advertising are usually more expensive) to then evolve into a dominant strategy by providing an extra layer of value, to keep the customer loyal (a free product bundle, or SaaS.

The key message is: that a platform strategy normally starts as a disrupting strategy and then evolves into a dominant strategy.

A quick way to explore how a platform strategy can respond to the expected outcomes landscape could be to take the arenas where most of the overserved customers and currently noncustomers (for example professionals that are being gatekept out of the market by incumbents) exist and apply a Wardley map-based, value chain analysis technique that consists in the application of the Six Platform Plays – as explained here in this example and more widely in our Platform Opportunity Exploration framework).

Applying the Value Chain analysis starting from the ecosystem scan related to such a particular set of arenas that emerged as in need of a disruptive strategy will allow you to understand:

• what are the target users you should be focusing on (likely, the producers that you bring on top of the value chain (platform play #2)
• what transactions can be standardized (between the producer and the consumer,  platform play #3)
• what product features can be created and how/if they can be expanded with an extension platform strategy (platform play #4)

Thus giving you a rough idea of how a potential platform experience can generate a disruptive strategy and then evolve into a dominant one.

Conclusions and a recap of the process

The process we suggest in this short essay represents some early (and in flux) work that we’re pursuing in the effort of integrating ODI/Jobs To Be Done practice with the Platform Design Toolkit (and most specifically our Platform Opportunity Exploration part of the framework). The steps we suggest in the integration follow:

 

• Perform the first arena scanning (see here) considering arenas as “Systemic jobs to be done”;
• Use the universal job map as a basis and inspiration to break down the systemic job related to every single arena into “steps”;
• Use the Ecosystem Scan three-layered approach to map all the entities and how they related to each other and to resources across the steps;
• For each entity involved (at any layer) try to identify desired outcomes related to each step;
• Perform quantitative analysis of the outcomes (see Outcome-Based SegmentationTM in the ODI framework) and identify which Arenas/Systemic jobs offer the most overserved customers or even not yet served ones – most likely the gatekept producers);
• Apply Wardley mapping according to the steps indicated in our Platform Opportunity Exploration guide (including the application of Platform Plays);
• Envision how you can design a disruptive to dominant market play by leveraging on a SaaS/product bundle first or a Marketplace first approach to the market as explained above.

We want to stress again that, the work presented in this short essay is preliminary and experimental and will be subject to change and to future further and more structured releases. We encourage you to come back to us with reflections and suggestions. Also, it’s important to point out that Tony Ulwick and Strategyn didn’t endorse this work in any way.

---

Are you curious about developing mastery on the application of such techniques, access our beta tool releases and more?

Join us at the upcoming Platform Design Bootcamp in June:

 

---

Before You Go!

As you may know, everything we do is released in Creative Commons for you to use. In case you’re getting value out of these reads and tools, we encourage you to share with your friends as this will help us to get more exposure, and hopefully, work more on developing these tools.

If you liked this post, you can also follow us on Twitter, we normally curate this kind of content.

Thanks for your support!