[How-to] Mapping user need and opportunity systems

A simple way of mapping user need systems and matching them to business opportunities

[How-to] Mapping user need and opportunity systems
Mapping needs and opportunities is at least as much art as science | Photo by Praewthida K / Unsplash

Editorial note:

  1. This is a working draft, open to feedback and iteration. If you have thoughtful, non-rant-y (!) feedback, please let me know. I'd appreciate your advice on making this better.
  2. This is fairly in-depth for a how-to guide (though I included a TL; DR section). But I hope you find it helpful. For a quick overview, just read (1) the bright orange boxes spread throughout the article or (2) jump all the way to the bottom of the post for my ultimate recommendation and a quick, visual summary of the entire guide.

TL;DR

To map user need and opportunity systems:

1. Collect and organize ("map") user needs themselves
2. Map value propositions resulting from user needs
3. Identify and map opportunities related to value propositions
4. Preview what's next: Opportunity sizing

Introduction

We have tons of tools to explore a user need and extract opportunities from it. Search for user journeys (e.g., here or here), value propositions, user empathy exercises, and you'll get inundated with training, templates, and tips.

But oddly, I can't think of a single "go to" tool for mapping complete systems of user need systems before you dive into any one of them. Capturing a range of user needs gets mentioned in passing or completed as a stepping stone. But it doesn't seem to have gotten the same love as other topics that are closer to "action."

If (unmet) user needs tell you where to focus, then opportunity or market maps tell you how to do it.

Things differ on the side of mapping market opportunities that stem from user needs... That topic has been covered more rigorously than user need space mapping. But that doesn't mean they are any better:

Consulting companies and business strategists elsewhere have developed sophisticated and standardized ways to map markets. But sadly, the consulting companies hold on to their own proprietary ways. So again, I'm not aware of any publicly-available best method. And even if such a standard approach existed, it might not work for innovation work because most market mapping methods depend on the existence of markets and related data. When innovators invent entirely new markets, then no data or pre-defined markets may even exist. So the standard approaches would struggle to apply. Again, no good options.

Here then is a simple way of mapping user need systems and matching them to business opportunities (opportunity maps/ value prop maps); emphasis on "simple." This how-to guide deserves much more thorough treatment. Consider it a crude MVP for significant iteration.

It draws from multiple sources, pulled together in my own idiosyncratic way. In other words, this is just "a way," not "the way." It works for me. But you may want just to treat it as a starting point. Re-mix it or evolve it significantly for your own needs!

High-level recipe

Here are the main points once more. You already saw them in the TL; DR. Next, we'' walk through each of them:

đź’ˇ
Recipe for mapping user need and opportunity systems

1. Collect and organize ("map") user needs themselves
2. Map value propositions resulting from user needs
3. Identify and map opportunities related to value propositions
4. Preview what's next: Opportunity sizing

1. Collect and organize ("map") user needs themselves

Define your user and use case

Get as specific as you can in describing users.

Remember that you may have a choice among multiple users. E.g., in a hospital setting, you might focus on patients, doctors, nurses, billing personnel, administrators, etc. Or in a retail store, you might focus on shoppers, different kinds of employees, etc.

Also consider that any topic has "lead users," "mainstream users," and "lagging users." E.g., communication needs will differ for "lead users" who bought the first smart phones vs. those who "lagging users" who still don't own a smart phone.

Consider use cases optional. They may or may not be critical to your situation. For example, when you think about driving a car, you might distinguish use cases like commuting, shuttling kids to activities, hauling cargo, showing off, exploring the country, etc. What people need may differ wildly by use case. And of course, again be as specific as you can. E.g., commuting on an empty country road in the winter is different from commuting on a clogged city freeway in the summer.

Collect needs

Come up with as many needs related to the topic as you can.

Format needs your needs as verbs. Needs are always verbs for our purposes! I "need to/ want to do something." That's the only way you can stay open to multiple solutions for meeting a need.

It's perfectly ok to think of both needs and wants. The distinctions can be critical or mere hairsplitting. We will only talk about "needs" here for brevity. But I always mean both.

Needs are also very closely related to "jobs to be done (JTBD)," a term coined by famed innovation researcher Prof. Clayton Christensen. Technically, JTBDs reflect the reasons "why customers make the choices they do ... to make progress" in their lives.

You can collect needs via pure ideation, secondary desk research, or primary research. Of course, it'll be critical to keep track of your degree of certainty. If you just made up a bunch of user needs, you'll need to expect that much of it is flawed or biased. At any rate, you'll need to back up assumptions with robust research and facts.

In fact, some teams even use generative AI for populating systems like this, particularly for draft versions. I'm not sure I can totally advocate that, except as a truly and completely sacrificial first draft. I say so especially because needs differ widely among user groups. You will only learn such nuances via your own research. LMMs will tend to average them away. Or at least you won't be able to be sure what is real and what is made up for a particular user group.

You can collect needs "bottom up" or "top down," just as is true for many other forms of ideation. "Bottom up" work means collecting needs in an unstructured way and then sorting them later. "Top down" work means coming up with a mental structure or framework that covers all types of needs in a given space and then coming up with needs for each of the types.

Structure needs into a map

Maps may differ vastly from one another, depending on what your situation calls for and on your style. For example, you might use purely verbal bulleted lists, abstract structures like "2x2" matrices, freeform mind maps, and more.

Whatever structure and visual approach you use, aim to end up with 3 to 7 needs or need groups at a top level. Create nested lower levels as needed to keep the top level simple. There is no hard rule that dictates this top level of 3 to 7 needs. It simply follows the amount of information that humans can comfortably absorb at a given time.

You can certainly create these kinds of structures on your own or in small groups on a whiteboard. But there's also value in creating them with a broader group of stakeholders, in a workshop format. For more on how to run such a workshop, for example, see Vijay Kumar's 101 Design Methods book (short overview e.g. here). It's "Analysis Workshop" method offers you a compact description for facilitating such work in person.

Identify unmet must-address needs

Not every need is an opportunity. If today's solutions perfectly meet people's needs, then there is little for you to do there.

Similarly, not all needs are important or urgent. Focus on those unmet needs that users (not you; you are not the user!) consider critical.

Understanding what makes for a an unmet must-solve need is sophisticated, nuanced work. We won't get into the specifics here, in the service of capturing the full topic.

Add other nuances to your map

Most maps offer readers much more than a single set of black and white line art. Tag, color, code, and otherwise enhance your map to your heart's desire.


2. Map value propositions resulting from user needs

Most products and services meet more than one user need. So we can't just stop after capturing our user need map. E.g., your car does not just meet one need among all the options, like "to get to my destination fast," "to feel safe," or "to show off." We need more. Enter the value proposition.

What is a value proposition?

Value propositions (often shortened to "value props") are abstract descriptions of the way that products and services can meet your needs.

Decide how to format your value propositions

As with so much in this guide, you have a choice of formats for describing your value props: Professionals will debate endlessly what the best, or even correct, format is for capturing them. That said, two common formats are the marketing-like tagline (e.g., "the best way to slice bread") and the much longer-winded but very common value prop canvas, created by a company called Strategyzer. In fact, another Strategyzer tool, the business model canvas, includes a field for value props that essentially is a marketing tagline.

I actually prefer to create even simpler, pared-down versions of marketing-like taglines when I create value prop maps. My goal is to describe, not to convince. So I cut the fluff and attempt to describe my value props in the most parallel way I can. For example, I might use value props like "be cheap," "be fast," be flexible," "be high-quality," and so forth. Minimalists might even subtract the leading "be" and stick to single adjectives.

Connect value propositions into a (quasi-)MECE system

In theory, there you also have a choice among infinite systems of value propositions for any topic. Don't try to create the perfect one. Instead, create a "we can live with it for now, good enough I guess" working definition that adequately covers the entire space you want to describe and does so in a logical way that leaves no major gaps.

As was the case above for identifying unmet must-address user needs, you can bring significant skills to bear to creating value prop maps well. But you don't need to be the world's expert at it. To start, just create your map and check that it passes the muster of those whose opinions matter to you, i.e., your stakeholders.

One way of checking whether your system of value props covers your space properly is to check whether your system is "MECE," meaning "mutually exclusive and collectively exhaustive." MECE is a fairly common tool among nerds in many fields. And you certainly could geek out on it. But in reality, it is quite simple. All it means is "no gaps and no overlap." Being completely MECE is often unrealistic. In fact, in a broad effort like this one, being truly MECE would involve boiling several oceans. You'd go mad trying. So don't be totally MECE. But at least try to be quasi-MECE or MECE enough. Use "monkey bar logic" and move step by step to avoid obvious logic gaps.

If you are working on a professional–especially a for-profit–topic, you can make things even simpler. Often you can fall back on common value prop classifications to start: Companies turn out to be rather rote in the way they position their brands and solutions, all claims to uniqueness aside. (In fact, rather orthodox frameworks and their adherents almost demand that you can at least can tie your positioning back to one of a small set of options.) So a small set of value props can cover a vast range of common options.

You may want to tweak things of course. But fundamentally, you can often start with options like those I used above in my example, such as: "be cheap," "be high-quality," "be specialized," "be multi-purpose," "be on trend," etc.

If such an approach just galls you as being too abstract and too far removed from the humans that the map is ultimately supposed to help, remember that there are much more real-world-based ways to create quasi-MECE systems. They make equally good foundations for a value prop system. For example, a user journey is nothing but a sequential MECE system. Many other standard and custom frameworks created as part of human-centered design (HCD) work equally well. I have for example been part of similar work based on the 5E model from service design (e.g., explained here along with the framework's history).

Of course, the steps of a user journey or another framework typically are not yet in the form of a value proposition. That's why those models can only serve as the basis for your system. You still need to decide how to convert into actual value propositions. But you will at least know that your work rests on a solid logical backbone.


Not all value propositions are attractive to your organization, even if they all relate to "must-address" user needs. You and the user are not the same. So we still must choose on what value props to focus.

Intersect value props with your strengths and goals

Strategists might dedicate entire multi-month projects to determining what value props to pursue. But the essence is fairly simple. You want to focus on topics that users care about (here, value props), on which you can deliver great work (your strengths and capabilities), and that you actually want to pursue (your goals and vision).

The mad-lib approach to describing opportunities

In its most basic form, you can describe such an opportunity in the form of a mad-lib. For optimal effect, you will definitely want to read your mad-libs out loud in your best movie trailer voiceover voice. This mad-lib of course comes with endless ways to customize it. But in its basic form, it goes something like this:

In a world, where [a group of users] need to [meet an unmet must-address need] ...
[our organization] can come to the rescue!
We can help [users] to [realize a value proposition]
thanks to [our capabilities and strengths].
Even better? It'll get us that much closer to our [goals or vision] too!

This kind of mad-lib can get the job done. You simply apply it to each value prop and gauge to what degree you can reach a "fit" that makes the value prop a promising one to pursue.

But mad-libs are also an intensely verbal approach that may work well, in particular, for auditory learners but may also feel much less appealing to visual or kinesthetic learners, among others.

Three ways of visualizing opportunity systems

People differ so vastly from each other that no single way of visualizing opportunities will satisfy everyone. Here then are three different methods that might appeal to different audiences.

The first method appeals to structured sequential thinkers like strategists. The second one aims at visual and non-linear thinkers. And I have used the third one with executives and others who want to stay at a summary level, out of the weeds of your work.

Of course, these three do not form an exhaustive set. They simply reflect the types of people with whom I have worked on this topic. But even if they don't fit your needs, they may make you think of other ways that you might like more:

A strategist's visual approach to describing opportunity systems

If you'd like another, more visual and hands-on way of achieving the same goal, I suggest the book Where to Play by Marc Gruber and Sharon Tal and their "Market Opportunity Navigator."

Their "Worksheet 1," the "Market Opportunity Set," achieves a very similar goal more visually and can easily turn into a workshop with more real-world interaction.

The nice thing is that the work you have done up to now will still serve you well. The "customer" and "application" sections of Gruber and Tal's worksheet 1 offer great landing spots for the needs and users we have already collected. All it takes is a word swap: We'd swap in "user" for their term "customer" and talk about "needs" or, closer yet, "jobs-to-be-done" instead of their "applications."

Once you have located where to connect our content to the Market Opportunity Set, the rest of the Where to Play methodology will guide you on along one way of prioritizing opportunities to pursue further. It's not the only way. You may already have other ones. But it's solid and definitely worth giving a try.

A visual HCD approach to describing opportunity systems

The flow and feel of the Where to Play methodology may particularly make strategists and business designers feel at home.

But if it feels a bit too structured, you have other options too.

The other visual way I have liked for describing opportunity systems comes from Human-centered Design (HCD). My favorite description of the approach comes from Heather Fraser's book Design Works. Her "Gear 3: Strategy & Activation" includes the "Activity System" tool. Visually, it appears like a sophisticated mind map. But it's the combination of visuals and disciplined terms that makes the framework shine. The Activity System gives you yet another way to visualize your opportunities and the connections among them that combine them into a true system. E.g., see here for an example of one such Activity system.

A system-level, stakeholder-oriented approach for describing opportunity systems

Both the Market Opportunity Set and the Activity System offer ways of visualizing opportunities in a "point in time" way. In other words, they describe how opportunities relate to each other to form a system. But they do not show how the entire system relates to its broader context, either to the entirety of the project of which the opportunity mapping is a part or to the organizational goals that the opportunities are supposed to help achieve.

But it is entirely possible to connect these opportunities to their broader context. All it takes is to create an "if-then" logic chain that ties the opportunities to the problems that they are meant to solve and the solutions via which you might bring the opportunities to life. Pull it off, and you also simplify stakeholder interactions. That's because these logic chains create the possibility of "choosing your own adventure," just as in the children's books.

Book cover of the "Choose Your Own Adventure" book "The Cave of Time" by Edward Packard
1979's original Choose Your Own Adventure book | Cover image from Wikimedia

My favorite way of creating tight logic chains of this time is the P4S framework. A longer description would distract from this guide's focus. But in short, it simply involves visualizing a mind map, logic tree, bulleted list, or other way that ties together the following one "P" and four "S" elements (thus "P4S"):

  • Problem – I.e., the business problem to solve that triggered your work, not the user-facing problem
  • Strategies – I.e., the boiled-down solutions we realistically have for solving the business problem
  • Spaces – I.e., the topics "where you may realistically want to play"
  • Solutions – I.e., the specific product or services or, better yet, the groups/ platforms of them that you might implement
  • Steps – I.e., the platform components or other milestones that show how the solutions are reasonable and attractive to activate

The beauty of P4S or another logic chain like it is that it summarizes your entire work in a compact way that hides away almost everything other than the connections among your ideas. Such glaring simplicity allows skeptical stakeholders (or "enthusiastically skeptical" teams) to use their own judgement to gauge whether your logic is any good, i.e., whether the proposed solutions actually have a chance to achieve the desired goals.

Focus on "jobs-to-be-done" and "opportunities." Resist "segments," "solutions," and "markets"

As you work through the opportunity mapping, the differences of doing this kind of work in operational (company core) and innovation settings become important:

In short, stay disciplined by not mandating a specific user "segment" or "solution" (such as a product or service). In operational settings, with their well-defined, stable markets. Those terms are legitimate and useful. But in innovation work, they will hurt you.

For one thing, that's because the opportunities often appear between or orthogonally to existing user segmentations. And for another thing, it's because multiple kinds of products or services can meet user needs. For example, in Clayton Christensen's classic jobs-to-be-done example, bagels, bananas, and milk shakes can all act as solutions that users "hire" for their JTBD, even though they belong to completely different product categories. Focusing on product categories, and, by extension, on pre-defined markets, would leave you completely blind to other ways to meet user needs.


4. Preview to what may be your next step: Opportunity sizing

A final word for overachievers: Mapping opportunities is one thing. The next step, prioritizing among them is quite another. In particular, sizing opportunities to understand their financial potential turns out to pose one of the more gnarly challenges in transformational innovation work.

Essentially, this is what "market sizing" is in more established markets.

We won't cover opportunity sizing in detail here. That work veers away from mapping a space and toward evaluating individual opportunities.

But if you'd like a starting point for your opportunity sizing journey, consider the book Discovery-driven Growth by Rita Gunther McGrath and Ian MacMillan. I found it invaluable for sizing opportunities that don't neatly fit pre-existing markets, especially when your team roughly follows a Human-centered Design approach, i.e., one that starts with users and their needs, as we have done here. If a whole book feels too daunting, you might also get the cliff notes in the authors' earlier article covering the same ground. It's just a wee bit older, and so its examples (from 1995) feel a bit dated by now. If you can look beyond that, the core of that HBR article, called "Discovery-driven Planning" is just as fresh and helpful today as it was then. Be sure to note the sidebars and tables. They help to illustrate the points from the text.


Further reading

Fraser, H. M. A. (2012). Design Works. University of Toronto Press. https://books.google.com/books/about/Design_Works.html?hl=&id=7tREE-3Xaa8C

Gruber, M., & Tal, S. (2017). Where to Play. Pearson Professional. https://books.google.com/books/about/Where_to_Play.html?hl=&id=YIRpvgAACAAJ

Kumar, V. (2012). 101 Design Methods: A Structured Approach for Driving Innovation in Your Organization. John Wiley & Sons. https://books.google.com/books?id=WJQmHlsDhQUC

McGrath, R. G., & MacMillan, I. (1995). Discovery-Driven Planning. Harvard Business Review, 73(4), 9. https://hbr.org/1995/07/discovery-driven-planning

McGrath, R. G., & MacMillan, I. C. (2009). Discovery-driven Growth. Harvard Business Press. https://books.google.com/books/about/Discovery_driven_Growth.html?hl=&id=aye6y6uAHuUC

Credits

Photo “Multicolored abstract illustration” by Praewthida K on Unsplash