Outcome Laddering for Product Clarity

Focus your product, rally your team, and unlock your strategic influence

PRODUCT DEVELOPMENT IS HARD, even if you “do it right.” Work on products long enough, and you might have stories to tell about great ideas with obvious potential becoming mired in organizational dysfunction and missing their window of opportunity, or talented people struggling as their projects spiral and churn. Or the frustration of watching broken experiences ship and then stay broken.

There are many reasons why this happens, but Erika Hall (one of my favorite thinkers on tech and design) points out one of the most important:

“Bad design gets out in the world not because the people working on it lack skills, but … because the decision-making process is broken.” — Erika Hall

Humans being humans, and product development being a complex chain of human decisions, there will always be ideas in tension, shifting market forces, surprising technical discoveries (for good and ill), differing personal motivations, and imperfect coordination between imperfect people.

But some challenges are peripheral, and some are foundational. Focus on the right ones, and everything else tends to get better. To that end, I want to give you a peek beneath the hood of product development, so you can better understand where the decision process breaks — and what you can do about it right now, without waiting for that perfect project or promotion.

DESIGNERS LIKE ME LOVE figuring out an ideal process, and the many iterations of “the design process” have seemed to coalesce on something like this.

We wish it was that straightforward. When things go wrong, it can be more like the following scenarios that you may find uncomfortably familiar…

Shiny object

Someone powerful committed to a cool but strategically ambiguous idea. Now you’re expected to deliver it, but you’re unsure if it’s good investment of the team’s energy and resources — or your career.

Too big to fail

The features are already half-built, the political capital is spent, and the product experience is clearly not good, but the train isn’t stopping, and crippling tech and experience debt is accumulating. “We’ll learn in-market,” they say, “it will be our MVP!” So the team moves fast and breaks things—something is better than nothing, right? Except you’ve just shipped an expensive, high-risk prototype with unclear learning goals and limited ability to pivot. Maybe you’ll be lucky, but you worry that by the time foundational problems are discovered, it will be someone else’s problem, and much harder to fix.

Hunger Games

Nobody’s written anything down, and it’s hard to get a straight answer on what’s most important and why, leading to a loss of insight and momentum. Meanwhile, a competitive culture is starting to develop…

Firefighter

You’re trying to lead a product team, but without a compelling story of the work to build organizational support, spot strategic risks, make smart bets, and motivate the team, you feel like you’re just running around trying to put out the latest fire. This wasn’t what leadership was supposed to be.

It was a good deck, at least

Invigorating research discoveries led to intriguing insights that… sat on a server somewhere as the organization continued doing whatever it was doing before, as competitors gain steam.

BAD PRODUCTS don’t happen randomly. In my years of working on products large and small — huge platforms with massive user bases, flagship mobile and web apps, ground-up product entries into new markets, and even a hardware product — I’ve come to believe that the way teams decide what a product¹ should be (its focus and features) is where things most often go off the rails, and where the greatest opportunities lie for setting them right.

In other words, the decision process breaks when your team lacks a shared basis for deciding — together — what’s most important. There’s no testable, public, and mutually-owned rationale for what you should build next, and why. Which leads to the tensions and dysfunctions I described. Those differences might be the obvious source of open conflict. Or they might be simmering under the surface, causing unspoken resentment, avoidance, and disillusionment.

These are foundational problems, with dramatic implications for strategic clarity, ownership, and efficiency, if we can solve them.

We need a way to…

• Make product decision logic visible so everyone can influence it, take ownership for their contributions, and make conscious bets
• Ensure everything we’re building supports a clear strategy that produces the most important results to our customers and our business
• Translate insights into testable beliefs² that can be refined over time
• Identify the irreducible core of an experience as a starting point for roadmap planning, experience optimization, and technical prioritization
• Create a compelling product story to motivate and focus the team, and gain support from partners
• Clarify and strengthen the interdependent relationships between features so that the product works like a coherent experience (and not just a feature list)

In other words, we need a way to proactively confront the ambiguity in our projects and partnerships, and find our strategic footing from any point in the process. So for several years, I’ve been on the hunt for a better way to work. Drawing on my own observations and synthesis, as well as ideas from Jeff Gothelf’s Lean UX, Adaptive Path’s Cupcake Model, the Jobs to be Done framework, my former boss Jennifer Lopez, and the vertical slice model common in game design, I think I’ve landed on an approach that does this.

As the saying goes, “all models are wrong; but some are useful.” While this too will be “wrong” in some ways (it’s just one lens among many)³, I think it’s a lens that’s commonly missing, and I’ve seen its introduction help teams solve the problems I’ve described.

And the good news is that you don’t have to find a blank slate project, convince your team to start over, or wait until you get a fancy enough title to make all the decisions. You can start in the messy reality of where you are right now.

The Purpose of a Product

Let’s back up and talk about why we build products. What are they for? One of the most fundamental truths of product development is also one of the hardest to swallow: nobody cares about your product. Sorry.

Nobody cares about your product.

What they care about is what your product enables them to do: the overall outcome it enables in their life (similar to what the JTTB framework gets at: the “job” your customers “hire” your product to do). This is at the heart of every product experience. It’s the thing customers⁴ will pay for, which no competitor has adequately provided. It’s the solution-agnostic value-to-deliver by any demonstrably effective means (because of this product or feature, “now they can _______”⁵), and it’s the flip side of a customer need, or the primary problem they need solved.

To produce this net outcome, there is a definable set of problems we need to solve, or customer outcomes to produce. These are irreducible and interdependent, and they will be addressed by a more specific set of enabling outcomes at a closer level of zoom.

Notice the arrows are pointing up, because each outcome is there to produce the one above it

Of course, without producing business value, the product is not a viable value exchange in the market, which means it can’t survive to solve customers’ problems either. So the outcomes the product will produce for a customer must also produce strategic business outcomes. These are the results the business (offering the product) cares about — reliable revenue, competitive advantages, cost savings, etc. — and hopefully, in a company that values social responsibility, a positive impact on society.

These outcomes intersect in a solution (or product/feature), or your team’s best shot at ensuring those outcomes happen as completely and consistently as possible. In other words, a product is a mediator of a value exchange between customers and a business. By buying (with dollars or something else of value) and using the product, customers get an outcome to improve their lives in some way, and the business gets an outcome that improves their prosperity, strategic options, and competitive positioning.

As the market changes, as we develop better technology, or when we come up with better ideas, we might change the solution in order to more effectively produce the customer and business outcomes that are the real goal. We can expand this to include additional branches and levels of detail, but you get the idea.

Taken together, these outcomes and their mediating solutions are why products exists.

Visualizing product decision logic

If you want improve your product decision logic (more ethically grounded, satisfying, strategic, competitive, etc.), you have to understand what it actually is—the good with the bad. What if you had something that gave you that source of truth behind your product, something that was a shared, evolving snapshot of the outcomes the team believes it must produce to meet customers’ needs and yield sustainable business advantages, visualized in a hierarchy of enabling relationships?

This is what I call Outcome Laddering, and it’s changed the way I work. It’s the hidden skeleton of every product experience⁶, something that you can learn to see, something that can give you the ability to orient yourself, diagnose your team’s problems, and plot a path forward.

An Outcome Ladder is a shared, evolving snapshot of the outcomes the team believes a product must produce to meet customers’ needs and yield sustainable business advantages, visualized in a hierarchy of enabling relationships.

How Outcome Laddering Can Help You

With a clearer understanding of product decision logic, and a way to visualize it, you can help your team work better together to build better products.

• Sharpen your vision: Inspire your team with clearer sense of the purpose of the work, and align partner teams around the value offered by your product
• Focus on the highest-impact work: Illuminate unknowns and learning priorities to inform research plans (and make more conscious bets), and channel brainstorming energy and design feedback toward demonstrating effectiveness against prioritized outcomes
• Build a tighter team: Create a broader (and less territorial) sense of ownership by moving the product’s foundational beliefs from individual brains to a shared basis for prioritization, create a more unifying project story of what you’re building and why, reduce communication chaos with a central source of truth, and have more productive debates that expose and clarify the most important disagreements and ambiguities

Outcome Laddering for the real world

Let’s try it with Waze, since it’s ubiquitous and relatively simple. We might be familiar with the app’s features, but beneath the surface, there are a series of beliefs about problems customers have that were not being adequately addressed by the market. These beliefs are the reasons Waze built those features.

What problem are they solving for customers? While their team started with a set of beliefs and worked from there to features, we can work outside-in from a purpose statement I heard from them once: “Fight traffic together.” Why is that the outcome they’re focused on? We can infer a need: sitting in traffic is infuriating, because it makes you feel alone and helpless. They tapped into a powerful need: a desire to find company to be miserable with, to stick it to the man, to fight back. So in theory, if by some effective means we can produce the inverse of that experience, we get customer outcomes to focus on. This is one articulation of the essential value: what you can now do because of this product.

If the purpose of this app is to enable people to“fight traffic together”, we might break it down into two main branches:

1. stuff they need in order to fight traffic, and
2. stuff they need in order to do it together.

First, customers need to know what the best route is. For that, they need to be able to see and evaluate their options. A way to do that is automatic route plotting and selection (a feature we can design and build). Second, they need to be able to anticipate and adapt to changing route conditions. Some ways to do that are traffic monitoring, notifications, and route adjustment (features we can design and build).

What is the business outcome or opportunity that meeting this need for customers will produce? Probably something like licensing access to exclusive route activity data in a market where there’s widespread need for traffic and navigation services but little technical infrastructure to support it, geo-targeted advertising opportunities, etc.

Visualized with Outcome Laddering, we get something like this.

We could keep going, but you get the idea. Now, how do we know if we’ve landed on the essential core of the product’s value? Let’s take an outcome away and see if it still works — if we still get the outcome above it.

Nope, now it’s just a navigation app, with no differentiated value to offer customers. Waze probably can’t produce the overall product outcome without the “branch” focused on helping fellow drivers.

What about the gas prices? Does the app really need to address that to produce the outcome above it? Probably not. This indicates it might be useful thing to build, but it isn’t essential to the product’s value. Does it help though? Sure, that could be a next feature (I’ve indicated that with a dotted line). Think of this as something that is not essential to meet the core need, but allows Waze to more completely meet the need. Over time, they could add additional ways to fill out that opportunity area, or address an adjacent category of need and value.

If what remains are the essential outcomes⁷ (minus the one with the dotted line) and their best shot at solutions that produce those outcomes, this is what I call their Essential Value Scope⁸—basically, their 1.0.

This wasn’t hard to do, aside from forcing myself to ask tough questions and be very specific. It took me about 30 minutes to do this one, pulling language from their marketing website⁹ and inferring the rest from personal experience.

I’m not privy to the nuances of what Waze knows about their customer needs or business strategies, so I’m making some educated guesses for the purpose of this example. If you’re Outcome Laddering from scratch (versus inferring one from an existing product like I’m doing here), these outcomes should absolutely be based on insights from customer interviews, market trends, and other rigorous sources of evidence. But remember: Outcome Laddering don’t have to be right—yet. It just has to be clear, because it will reveal the quality of your team’s decision logic as it is today, and where it may break down into disagreement or guesswork.

If you can accurately articulate and visualize what your team believes right now — the actual rationale for decisions, regardless of its current rigor or validity—then together you can spot holes in your understanding, prioritize areas for further investigation and research, productively debate your true focus and scope, align on the latest iteration of your strategic beliefs, and test your way to right. And as you learn more about your customers and market, you’ll update your Outcome Ladder to reflect your sharper understanding, as it becomes a an increasingly reliable source of truth that everyone can rally around.

At first, it’s more important to be clear than to be right, because if you’re clear, you can test your way to right.

Let’s recap. In the Waze example, you can see the key ingredients of an Outcome Ladder.

Ingredients of an Outcome Ladder

1. Clearly-articulated, prioritized outcomes for customers (the result, not the means)
2. Clearly-articulated, prioritized outcomes for your business (the result, not the means)
3. Hierarchy of enabling relationships between outcomes (in other words, to sufficiently address X outcome, we need to be sure to we address its essential components — outcomes Y and Z…)
4. Your team’s latest, best solution proposal for producing the outcomes above (regardless of development status — whether just an idea or something already in-market)
5. Essential Value Scope, showing the irreducible and interdependent outcomes to address in order to make a valuable product — in other words, if you address fewer than these outcomes, customers won’t want it and you can’t compete)

What Outcome Laddering is not

Outcome Laddering is not a way to plan out how an experience or a project will play out over time, and it’s not journey mapping or process mapping or roadmapping. There are better tools for that. It’s a tool to help you agree on what to build, so you can know the best investments of your team’s time and energy. It’s a way to expose the logic behind every part of the product so your team can align, optimize, and plan. It’s a way to help fix the part where I think a lot of projects go wrong: product definition. It’s just a way to see, a way to empathize with your partners, and a way to align the energy of your team so you’re heading in the same direction with a basis for strategic course-correction.

Putting Outcome Ladders to Work

Planning a product or platform

On my team, we’ve created an Outcome Ladder of an entire platform redesign, oriented by outcomes to produce, from individual feature controls all the way up to the mission of the business. Each design lead defines a branch of this map (based on evidence collected thus far, and the perspectives of the team), and some of them have used it as a facilitation and synthesis tool to better align with their feature partners.

We made this one in Mural—an excellent tool for a first-pass at low-fi Outcome Laddering

This has helped us refocus our work on core user workflows and goals (rather than its prior orientation by project or solution), avoid shipping the org chart, and illuminated new opportunities for how we might organize the platform’s functionality, guiding IA, navigation, feature crossover, etc. It’s also been a huge help in aligning with partners and creating a strategic story, with the language and structured thinking we got from doing this (relying on research insights from the team and conversations with partners) serving as the backbone of the strategic framing we worked with our senior partners to create, and it showed up in leadership communications with the entire organization.

We created a more robust version in Airtable (template coming soon), where we’ve included useful metadata such as confidence levels for strategic focus and solution effectiveness, supporting evidence, risks, project leads, and other dimensions we wanted to track.

Auditing your product

Now that you understand the basic logic, you can use an Outcome Ladder to fill in what you know already, and notice what you don’t. The places where you don’t know exactly what to write, or where the team starts arguing, are the places where you most likely lack a clear and shared rationale. That’s good to know! Use the Outcome Ladder as a prompt for that discussion, capturing the team’s beliefs and hypotheses and then iterating as you push for clearer articulations.

Focusing your role

If you think of your role as “the outcomes you are most directly responsible to ensure”, you can Outcome Ladder your job too.

I’ve used this to:

• clarify my own priorities,
• communicate my goals and areas of focus to my manager and partners,
• audit and adjust how I’m spending my time and energy, and
• track progress against outcomes for performance reviews.

Using an Outcome Laddering approach, I’ve mapped my areas of responsibility defined as outcomes to ensure, and various projects I’m responsible for laddering up to those.

Similarly, I’ve used this as a tool to facilitate a growth and career recalibration for one of my teammates, which was clarifying and inspiring to them as they plan their next steps.

Getting Started

Chances are, you and your teammates already have some strong opinions, and as well as some controversies and unknowns. Time to try it for yourself! Download the Outcome Laddering Quick Reference as a guide, fill in what you have with your favorite tool (Mural, Post-It notes, etc.), and work from there.

Here are some tips to help you get started.

Start where you are

I’m convinced that any truly useful tool must start by dealing with reality. Not where you should be, but where you are right now. And the reality is that many of us live in the complicated ambiguity of the middle, and very few have the influence or authority to scrap a product vision and maintain employment. But here’s what I’ve been surprised to discover: half-baked ideas, educated guesses, or vague directives can be a perfectly acceptable starting point, at least in the messy middle where many of us live. Your perspective will be incomplete, and that’s OK! Remember, the goal is to be clear enough for the decision logic of the team to emerge. Since your Outcome Ladder is a snapshot of the team’s collective beliefs right now, your Outcome Ladder can and should change (sometimes after every meeting!) as you learn about your customers, market, business opportunity, most effective solution.

The Outcome Ladder reveals the clarity and alignment of the team’s strategic thinking. If you discover gaps in your map or the team starts to argue, that in itself is an important insight: now you know a source of confusion or disagreement that may be causing problems for the team. If you get stuck, make a note and move on to the next element. Once you get most of it filled out, you’ll have a better sense of what you’re missing.

Choose the easiest medium

Outcome Ladder on a whiteboard if you want. Use Mural, or Miro, or Whimsical, or Google Jamboard, or Airtable. Use Post-it® notes (the real ones, not the cheap knockoffs — you’ll thank me later when they stay on the wall). Doesn’t matter. Use whatever tool is easy to learn, credible in your organization, and gives everyone access to the process (and secure, of course, as it will show potentially sensitive product strategy plans).

I recommend starting with something that feels low-fidelity to you. Something where it’s easy to move stuff around, with minimal psychological barriers, as you’re trying out value statements and figuring out where they go.

Use consistent color coding for the different elements — like blue for customer outcomes, orange for business outcomes, and green for solutions or product offerings.

Want a head start? Use these templates I made in some popular collaboration and visualization tools.

• Airtable template (coming soon!)
• Mural template (coming soon!)
• Miro template (coming soon!)

Find a partner in crime-fighting

Find someone willing to try a new approach with you — someone who works on the same product, but preferably not in the same job function. You’ll move a lot faster, and the debate that naturally emerges will dramatically clarify your thinking, as well as make the ideas you capture much more representative of the team’s perspective (and thus easier to adopt as a strategic anchor).

Anchor on outcomes, not solutions

Regardless of where you start, customer outcomes can be tricky properly define. It’s easy to describe them in terms of the solution, or the work the team is doing, rather than the net result for the customers, which obscures the real opportunity. Remember, the product or feature is not the value; the feature is the means by which the value is delivered.

You’ll know you’ve clearly articulated the customer outcome when you can answer:

• What is the one thing that customers need to be able to do that is unique to this area of focus (addressable by a discrete platform / product / feature / control, depending on your level of zoom)?
• If we could magically create a perfectly effective solution — if a product or feature we could build was wildly successful — what would now be true for customers? What would be their new reality? What goal would they be able to achieve? What are they currently prevented doing which would then be possible? “Now they can _____?”

Notice that well-articulated outcomes are framed as something they’re doing, not something you or your product is doing. It’s not their use of product; it’s the thing they want to be able to do as a result of their use of the product.

Business outcomes are generally more straightforward. They’re just the results the business wants to see from the project, and you can usually get those specifics from business leaders or product managers if you don’t know them already.

Force clarity on the underlying beliefs, and don’t settle until you know the precise belief on which a proposal or priority is grounded. This is the hard part — there’s no shortcut to clarity, but someone has to do it. Expect the pain, and keep asking why, until the Outcome Ladder is precise enough to disagree with and make real commitments from. If you’re good at synthesis and wordsmithing, take initiative to facilitate. If there’s someone else who’s stronger, get their help. If the group starts debating, you’re doing it right!

Define the “Essential Value Scope” (EVS)

Once you’ve got the outcomes documented that you could address, try taking them away and see what happens. You’ll quickly get a sense for what the team believes you can’t live without, which is a version of the true product core, from which you’ll expand to meet adjacent areas of customer need and business opportunity. Next, take a pass at agreeing on levels of confidence for each element. The results will help you understand where more research is needed (or where the riskiest bets might be).

Share as soon as possible and iterate

Outcome Laddering is not about creating a polished artifact; it’s about making a snapshot of what the team believes right now. So as soon as you have anything intelligible, share it with the team, and get them involved in filling it out or getting it clarified. Use it as a reference point in meetings, and update it real-time. I’ve found that usually the team will be interested in a clear articulation of the rationale behind the work everyone is doing.

Add dimensions that matter to your team

If your team has significant risks to navigate, attach those to the relevant points on the Outcome Ladder. If you want to keep track of who’s responsible for what, evidence to support a point of view, levels of confidence, or what technical capabilities will be necessary to deliver those outcomes, put that on there too. While the team may not formally show it, it can become a source of truth that informs communication and planning within the group, and with other leaders or teams.

I hope this has been helpful to you. I’ve shared my perspective on some common questions below, but if you’ve got additional questions or feedback, get in touch on Twitter or LinkedIn.

Special thanks to Greg Storey, Sarah Goelitz, Kate Tikoian, Beth Schwindt, Jess Bowman, Griffin Mullins, Kim Stockley, Toni Drenckhahn, Tommy Rayburn, David Fine, Ron Irizarry, Catherine Sun, Eli Cruz, Tim Gilligan, and others, who generously provided encouragement and feedback as this framework developed.

Q&A

What if the beliefs in my Outcome Ladder are wrong?

Outcome Laddering isn’t in the beginning about being right (yet!). It’s about being clear. Of course, your beliefs should be grounded in valid evidence, skillfully synthesized by competent practitioners. But regardless of whether they’re correct, the point of Outcome Laddering is to expose and clarify those beliefs, so that together, you can figure out if you’re right, and adjust your product vision accordingly.

Is Outcome Laddering just a form of product management?

Maybe? But does it really matter? What really matters is making high-quality decisions together. This is a way to help you know what goes into that, and what to focus on next, in a way that everyone can own and contribute to.

When should I start Outcome Laddering?

Outcome Laddering is most useful when you’ve identified a target customer and problem area, and want to clarify a product vision. If you have no idea what problem you’re trying to solve, you should be doing research first. But as soon as you start to have hunches or beliefs, I think you should start mapping them. so you can start to see implications, gaps, and opportunities.

What if my boss / teammate isn’t interested?

At a minimum, your own work will be more focused, strategic, informed, and effective. That said, I’ve never shown this to a partner who wasn’t grateful for the clarification of the team’s hypotheses, priorities, risks, and purpose. Leaders are doing their best under a heavy load, trying not to fall behind as they juggle various pressures, and someone taking the initiate to make strategic sense of the chaos is a very useful contribution, no matter who it comes from. So do it anyway — you’ll be much more disciplined about what you know and don’t, what’s present and what’s missing, where you might need more evidence, and what you might want to focus on next. At least you’ll better understand what’s holding you back. And besides, you don’t need to be formally in charge if you’re creating connective tissue, which is great way to influence regardless of your position.

Who should “own” the Outcome Ladder?

An Outcome Ladder should represent the beliefs of the team, so it belongs to everyone — doesn’t really matter who updates it, and over time, this should become a distributed responsibility. But until the team is well-versed in Outcome Laddering, it may need one person to ensure clarity: prompting healthy debate, helping draft nuanced outcome statements, etc. Generally speaking, I’d recommend that the lead primarily responsible for a feature or product direction, or someone particularly skilled in synthesis, take the lead on their respective branch or level of zoom on the map.

Is Outcome Laddering just Jobs to be Done?

I’m not a JTTD expert, but one key difference I’d suggest is that JTTD focuses on discovering and orienting around the ultimate purpose of a product offering (especially the customer tasks to support, in typical use), while Outcome Laddering is about deciding together which “jobs” we care about for the purposes of product development, arranging them in enabling hierarchical relationships, and clearly defining the irreducible and interdependent set of outcomes to prioritize. In other words, Outcome Laddering is primarily a source of truth for product definition and collaboration.

What if a customer outcome / feature doesn’t create business value on its own?

Some value that doesn’t create immediate value for the business (revenue, current or future) is still necessary to deliver to customers, in order to do the right thing for customers or deliver overall value to the business. For example, supporting location services for a ride-sharing app may not provide inherent value to the business (the business offers that part of the service free of charge), but it is necessary to deliver the overall value to customers of a ride-sharing experience / the ride itself, for which it charges a fee.

What do I do if the team gets hung up on a product solution?

Don’t be afraid of the people obsessed with a feature idea: when there’s that guy, there’s a passionate opinion beneath it that’s easier to draw out, clarify, and evaluate together. Withhold judgment, push for the underlying belief, and try to get it as clear as possible. Once it’s clear and external, it will belong be easier to assess its basis and validity with the whole team. The person with the feature idea will feel heard, but will be less prone to dominate the conversation, since the idea now has a home on the Outcome Ladder and not just in their brain.

What if the team can’t agree on hypotheses?

Make two Outcome Ladders! Again, the important thing is to be clear on the beliefs behind the product, in order to plan, test, and build. If you’re clear enough to turn it into a prototype, you can test both. Most likely, there’s some truth to both, but you’ll find out!

Is this just roadmapping / information architecture / navigation / etc.?

Nope, but since it helps with clarifying the underlying decision logic, it’s complementary to all of those tools, and in my experience, has been effective in improving them.

Is this just another framework?

I feel you. Every day there’s a shiny new framework from a Thought Leader, and those of us who live in the Real World have learned to be wary of those. Outcome Laddering won’t solve all your problems. What we need is a way to make meaningful progress on solving our most important problems. You could call Outcome Laddering a framework, but if you forget the rest and install the decision logic behind it in your brain — orienting by outcomes in enabling relationships — then I’m happy. I just want teams making better strategic decision together, and this is my attempt to help them do that.

Footnotes

¹ For simplicity, I’m using the term product pretty broadly, but I believe this approach can be useful for defining large platforms, business units, or even whole companies.

² A note on language: I generally prefer the term beliefs over hypotheses or assumptions. Hypothesis tends to mean something scientifically verifiable, which is great, but I don’t think it’s always necessary as long as you’re making smart bets with your eyes open. Assumption tends to mean a guess with no basis other than personal opinion, which is rarely the case, even if the basis is some kind of informed intuition based on something like experience in a given industry. Usually, I find it most productive to start with articulating what the team believes, and then examine why.

³ I’m increasingly convinced that good strategy boils down to asking (and answering) the right questions in the right order. It’s about making high-quality commitments that enable a business to serve customers, seize opportunities, and manage risks. Frameworks and tools are just ways to help you do that — usually by illuminating an oft-neglected dimension of decision-making (as “design thinking” ostensibly did for integrating customer needs and feedback into business decisions, despite its now-obvious shortcomings).

⁴ Although some distinguish between paying customers and non-paying consumers or users, I’ve intentionally used the term customer throughout. This is because I see any exchange of value between a business and a person as a business relationship (whether the product or service is paid for with dollars or data), with all its associated moral and ethical responsibilities.

⁵ Thanks to my colleague Steph Hay for the wording of this prompt.

⁶ My product design career has focused digital products (currently FinTech), but I believe outcome laddering is generally applicable to any kind of product.

⁷ Or outcomes that are essential to enabling other outcomes.

⁸ I propose Essential Value Scope (EVS) as a less-catchy but more precise alternative to MVP, since in my experience, the term MVP is usually misunderstood. This has led some to propose language like Minimum Valuable Product (MVP), Minimum Lovable Product (MLP), etc. These are not wrong, but, in my view, by anchoring on “minimum” they obscure the true purpose of this designation, which is to clarify the product’s value and starting scope. A true MVP (as originally conceived) is not the 1.0 making first contact with the market; it’s the quickest and cheapest thing you can build to gather feedback and learn what you should launch to customers. In other words, you’re trying to figure out the bar for value, and a broken MVP can help you know what a good 1.0 is. In this framing, an MVP has a useful part to play as a prototyping and learning tool, while an EVS helps a team agree on the irreducible core of their product.

⁹ When marketing is done right, it’s a great window into the outcomes a company believes they’re in business to produce. This can also be a useful way to do a quick competitive analysis or product teardown, and even predict where a competitor might move next.