The Logic of Many Models
Models are low-dimensional representations of high-dimensional spaces (Page, 2018). A price model of a marketplace has a supply dimension and demand dimension. Or consider a map, a model of a physical space. Rather than representing every dimension in that space — sound, light, elevation, vegetation, fauna — maps show only the dimensions pertinent to navigation. Other dimensions are left to other models. Perhaps an explorer also has a survival manual (model) for guidance on making potable water or avoiding bears.
Adding models together — instead of adding dimensions to models — improves decision making by bringing in the best tool for each job rather than expecting one tool to do every job (Page, 2018). A map and a compass are easier to use together when they are separate. An explorer can hold the compass in one hand and orient the map to the landscape with the other.
To enable more and better combinations of models, make models that are narrower — by reducing their dimensions — and more specific — by reducing the overlap of dimensions across models (Page, 2018). Reducing dimensions in a model trades completeness for clarity. Reducing the overlap of dimensions trades redundancy for novelty. The combination of models you use is your model ensemble, a group whose elements are more productive together than individually.
If a model in your ensemble is not contributing predictive value for your product space, don’t add information to that model: add another model that makes both more predictive. If two models in your ensemble do not add much insight when used together because they are largely the same, then make each more specific (more orthogonal) and use both. More models are needed, not fewer (Page, 2018).
Strategy and Design are disciplines that draw on many models. Strategy has the SWOT, 5-Forces, Growth-Share Matrix, Value Chain, and many other representations of costs, customers, and competitors. Design is founded on Personas, Journey Maps, User Flows, Service Blueprints, and many more variations that represent context, cognition, and collaboration. Often, strategists and designers use models from each other’s disciplines; strategists recognize the value of deep customer understanding, and designers the importance of competitors’ responses.
Sometimes, the models seem to collide. The Persona, which arose in design, and the Job-To-Be-Done, a strategy tool, are currently the subject of intense debate: Is the Persona or the Job-To-Be-Done the superior model (Klement, 2016)?
Personas capture the typical behaviors of a person playing a role (parent, business person, etc.) given specific goals. Persona advocates argue for adding information (dimensions) to Personas to make them more informative. Adding contextual information to a persona at the expense of information about the persona fits the persona too closely to the context, as if the way business travelers behave in an airport is the way they behave everywhere. Business travelers might overpay for business magazines at small newsstands but only because that is all that airports provide. Adding dimensions to Personas tells us more and more while helping us understand less and less. Personas should tell us not so much about what people do in one context that we cannot imagine what they might do in new contexts, including contexts that are new because of what we design.
Jobs-To-Be-Done encompass a causal event and the people and affordances available in a particular context (a franchise restaurant, a bus terminal, etc.). Job-To-Be-Done advocates argue for replacing Personas with a Job-To-Be-Done. But, to model a “person hiring a product to do a job” (the conceptual framework of the Job-To-Be-Done), one needs to describe that person in a general but useful way, which is exactly the purpose of a Persona (Christensen, Cook & Hall, 2005). Trying to excise a person from the Job-To-Be-Done just results in awkward framing. Christensen, Bartman, and van Bever attempt to distinguish the “voice of the customer” from the “voice of the job”, as if a job could have a voice without a Persona to provide it (2016).
Moreover, without a Persona representation, the Job-To-Be-Done tells you a product was “hired” — someone bought a milkshake at a burger franchise — but not why. Knowing that people bought milkshakes doesn’t tell you what goals motivated that behavior, and without those goals, you’re left to randomly try new designs. It also risks overgeneralizing from the actions you observe in a context. Seeing a group of 15 people order two milkshakes each could be a reason to design a bigger but still easy-to-hold disposable cup, unless you know the group of people are ultra-marathoners refueling after an 80 km race.
In fact, Christensen et al.’s original presentation of the Job-To-Be-Done does pair Job-To-Be-Done contextual information about a franchise restaurant with not one but two Personas: a Business Traveler and a Parent with Kids (2005). Knowing their customers’ goals, represented in the Personas, enabled designers to imagine new possibilities for milkshakes given the context represented by the Job-To-Be-Done. For the Business Traveler, that was an easier way to buy a milkshake and get back on the road. For the Parent, it was a straw that their children found easier to suck up a thick milkshake.
If you have accepted the power of an ensemble approach to modeling, then you can see the issue with the Persona v. Job-To-Be-Done frame of model “superiority”. It’s not whether one model is superior to the other; it’s whether the models were designed to be used together. The ensemble frame for the Persona or Job-To-Be-Done debate is: How can you make your Persona and Job-To-Be-Done models more generative as part of a set of models? Making your Persona and Job-To-Be-Done models more generative requires making them narrower, by reducing their total dimensions, and more specific, by reducing the dimensions they have in common. Then, add other models to represent additional salient dimensions of the opportunity space.
An Ensemble of Models for Strategy and Design
The ensemble of models I discuss here represent different dimensions of strategy and design — disciplines so closely intertwined that Richard Rumelt, one of the world’s leading strategists, went so far as to declare that “strategy is design” (emphasis added) (2011).
The three models for strategy and design are:
- The Episode
- The Business Model Graph
- The Value Path
Below, I introduce each model and its components, and provide an example of using each model.
The Episode model is itself a set of three models: the Persona, the Scenario, and the Outcome. Generally, the Persona is your customer, the Scenario is her immediate environment and an inciting event, and the Outcome is how she resolves the tension or conflict that arises in the Scenario. An Episode fits into the more familiar Journey Map the way a chapter fits into a book or a scene fits into a screenplay.
More specifically, the Persona is the role, setting, goals, and behaviors of the customer your product is designed for. This could be a:
- Role: New Dad
- Setting: An airport at midnight
- Goals: Get home after a business trip; make the connecting flight; update his family; sleep
- Behaviors: Watching the flight board, dozing on his luggage, texting important updates to his family
The Scenario is a causal event, the Persona’s context — or affordances and people in his immediate environment — and a set of activities he could undertakes. This could be:
- Causal Event: A ‘mechanical issue’ results in a canceled flight, and the New Dad Traveler is stuck in the airport.
- Context: The New Dad’s tools, including a smartphone and laptop; people he is chatting with while waiting; airline and airport personnel; and various stores and spaces in the airport.
- Activities: The New Dad begins looking for a new flight or a way to wait for the flight his airline automatically re-booked him to… 6 hours from now. He talks with the personnel at the airline desk, fellow travelers he has befriended, paces through the airport looking for options, and searches his phone for new flights and alternatives to waiting in the airport.
The Outcome is the exchange in which your product provides value, described qualitatively in terms your Persona would use:
- Product: Carry Bot, an upright robot that moves on a single wheel and has two arms; two gripping extensions on the end of each arm; a pleasant robot face; and a human-like voice.
- Exchange: Carry Bot robot wheels up to New Dad Traveler and offers to carry his luggage as New Dad Traveler paces.
- Value: Peace of mind (New Dad Traveler feels that his luggage is secure), and physical comfort (he’s not lugging heavy bags).
Note how the models in an Episode are interlinked: for example, the Persona’s setting is expanded on in the Scenario’s context, and the Scenario’s activities are extended in the Outcome’s exchange. This interlinking structure has three important features:
- Allocation of information to the best model. People make decisions given their personal inclinations, experiences, and available options. The Episode provides a model for each of those decision inputs.
- Illuminating which links are missing or incomplete. Who are we providing value to? Under what circumstances? What is that value from the perspective of our customer? Each question is necessary but not sufficient for product development and corresponds to the Persona, Scenario, and Outcome, respectively.
- Guiding exploration. Exploring new Personas, Scenarios or Outcomes can be done by changing dimensions rather than whole models. Change the Persona’s role from New Dad to Empty Nester: for your product to add value, what in the Scenario or Outcome needs to change, and what can stay the same? Or change the Scenario’s causal event from an overnight delay to a 2-hour delay: what in the Persona or Outcome must change or can remain? Alternatively, it can be done by setting some dimensions to a more general level to focus more on other dimensions. If your Persona is “An Employee” or “A Commuter”, what dimensions are uniquely relevant to that broad class of people?
The Business Model Graph
The Business Model Graph is a graph (network) representation of a product development game (a game in the competitive, strategic interaction sense), which includes players, their capabilities, and their interactions (Gans & Ryall, 2017).
Each of these terms is general. Player can mean suppliers, competitors, customers, or complementers. Interaction encompasses collaboration and competition: you, your customers and your suppliers collaborate to create value and compete over who receives that value. Appropriating more than your costs requires strategic advantage. Capabilities are the resources you have access to, including your technology and employees’ skills, your other products, and your suppliers’ products and services.
In this BMG, Carry Bot and Sing-n-Carry Bot each have one unique capability (voice design and music licenses, respectively), and have a robot manufacturing capability in common. You use the “voice design” capability to endow Carry Bot with a natural, human-like voice. Sing-n-Carry Bot uses its “music licenses” capability to sing children’s music, although it has to use the standard, robotic voice supplied by its general “robot manufacturing” capability.
The BMG provides several insights:
- Products link customers to capabilities. Your Carry Bot links New Dad Traveler to a robot that can carry his luggage and has a human-like voice. Sing-n-Carry Bot links him to a robot that can carry his luggage while singing children’s tunes in a robotic voice (Sing-n-Carry Bot doesn’t have a voice design capability).
- Your added value depends on your unique capabilities. If you and your competitor link a customer to the same capabilities, then from the customer’s perspective neither of you is adding value. To see that, imagine that one of you exits the market. The value available for your customer is unchanged — he can still interact with the remaining firm and receive the same value (Brandenburger & Stuart, 1996).
- Complementary capabilities add more value. As opposed to ad hoc capabilities, often proposed as discrete additions to an existing product, complementary capabilities make other capabilities more valuable. In the BMG above, adding a “tape dispenser” capability to the Carry Robot adds value on its own (however small), but doesn’t make any other capability more valuable. But adding “expressive robot face design” is valuable on its own and even more so in combination with the “voice design” capability.
The Value Path
The Value Path is a like a UI Flow but with an outside view; it’s “UX is not UI” in model form. It has decision points when your Persona is deciding to use your product or your competitor’s product. It adds design inflections that increase the Persona’s likelihood of selecting your product or decrease his likelihood of selecting your competitor’s product. The Value Path expands the opportunity space outside of the product to the Persona’s setting and Scenario’s context by representing how new decision points could support new design inflections. That is, decision points and design inflections are not a given but can be created.
Here, the Decision Point is the first interaction between New Dad Traveler, your Carry Bot, and Sing-n-Carry Bot. You created two design inflections: one is a positive inflection, a wry smile on your robot’s face; the other is a negative inflection, a white noise machine that mutes Sing-n-Carry Bot’s children’s tunes.
In the next Value Path, a new decision point is created around a charging station for the Carry Bot to support the positive design inflection of a charging point for travelers.
The Value Path models how design can shape not just the direct product experience but also the environment in which that product is used. Value Paths are especially important in for multi-channel products and multi-product firms:
- A multi-channel product’s Value Path can have decision points and design inflections across channels — think of the “Open in our app” notifications on mobile websites for products like Medium or LinkedIn, which increase the likelihood a person uses an app but are decision points outside of that app.
- The Value Path for a product in a multi-product firm can have decision points and design inflections that make a set of products more valuable together, like Google’s Drive products, which enable easy cross-product sharing and integrating.
No single model, whether it is a Persona, Job-To-Be-Done, Business Model Graph, or Value Path, can answer every question that will arise when going from product-market intuition to product-market fit. Adding models together, whether it’s a Persona and Job-To-Be-Done, or the models I discussed above, shows their limitations and contributions — what they overlook, and where they focus — in a way that adding information to any single models cannot. This is the logic of the ensemble approach: combining narrow, specific models generates insights beyond what any single model is capable of.
The ensemble of models for strategy and design I discussed — the Episode, the Business Model Graph, and the Value Path — blends design and strategy concepts and is informative for both. These models are tools for developing an experiential and strategic understanding of your capabilities, customers, and competitors, or for imagining new ones. But they only represent what to look for, not how to look for it or how to make sense of what you find. How you gather data for them, what you find important in that data, how you categorize and combine data into dimensions that generate insights — that is the creative, challenging work required for strategy and design (Brandenburger, 2018).