Chapter 5. Uncovering Customer Needs Through Themes
What you’ll learn in this chapter
The importance of expressing customer needs
Definitions of themes and subthemes
Ways to uncover themes and subthemes
How to use job stories and user stories to support themes
How to transform needs into themes and subthemes
Ways to relate your themes to objectives
How to handle features in your roadmap
Identifying customer needs is the most important aspect of your roadmapping process.
Roadmaps should be about expressing those customer needs. Therefore, most items on your roadmap will derive from a job the customer needs to accomplish or a problem the customer must solve.
Uncovering those needs can be a challenge in and of itself. On top of that, you must vet every need to make sure your understanding is not biased by your assumptions or warped by your rose-colored glasses. So, in this chapter, we’ll go into quite a lot of detail on how to investigate, identify, and define customer needs.
Expressing Customer Needs
In the Preface, we related the product professional to an executive chef, and compared building products to crafting meals. In this metaphor, the roadmap is equivalent to the chef’s menu; it defines what will be delivered. But so far we don’t have anything on it! Now we get to the real value—figuring out what goes on the menu, in what order, and how it will be presented.
If you’ve done the groundwork, you will have uncovered a real problem worth solving. In other words, you have identified a “job to be done” that is frustrating and inconvenient enough for a customer to seek out and “hire” a solution to address that discomfort. Additionally, if your guiding principles are properly set, then you also have a clear vision for a desired end state and the goals that will get you there. With those things in place, you’re ready to get into the details.
The next step is to extract all of the precise problems or needs that must be addressed in order for your product to add value to the customer. This is a critical component because every decision about your product should be rooted in customer needs. Staying focused here helps you avoid building things your customers don’t need, forces you to be efficient, and ultimately ensures that you deliver the highest possible value to your customer base.
Your roadmap helps you match those customer needs with what’s important to your business to thrive and grow. It doesn’t matter whether you’re building an MVP, a version 2, or release #97. We recommend you start by understanding and organizing the most important customer needs first.
As we touched upon earlier, we recommend that you draw a clear distinction between the product roadmap and the release plan (see Figure 5-1). Your roadmap should be a high-level view of what needs and problems your product should solve, while also helping you confirm why. In contrast, your release plan should detail how you will solve them. The product roadmap should not be about developing solutions or defining what your product will look like. Leave that to the release plan!
Figure 5-1. A product roadmap versus a release plan
Themes and Subthemes
As we’ve touched on, in the relaunched roadmapping process we use themes and subthemes to express customer needs. This is probably a new concept for many of you, so let’s define what we mean by these terms.
Themes are an organizational construct for defining what’s important to your customers at the present time.
The difference between themes and subthemes is granularity, or level of detail. A theme is a high-level customer need. A subtheme is a more specific need. Themes can stand on their own, but they can also represent a grouping of subthemes. Let’s look at a generic software example:
Theme: | Address key usability issues |
Subtheme: | Pagination |
Subtheme: | Menu navigation |
Subtheme: | Save status |
In this example, you can see the high-level need is to improve usability for the customer. The subthemes then highlight more-granular needs that you can explore to accomplish the larger theme.
Now let’s revisit the garden hose example from earlier in the book:
Theme: | Indestructibility |
Subtheme: | No kinks |
Subtheme: | No leaks |
So, again, themes and subthemes represent the needs and problems your product will solve for. A need is generally something the customer doesn’t have yet, whereas a problem is something that’s not working right (with the existing product, or whatever substitute they might currently be using). Even though these two terms suggest subtle differences, the important point is that both refer to a gap or pain in the customer’s experience. When identifying the themes and subthemes for your roadmap, remember to consider both needs and problems from all angles.
Jared Spool, paraphrasing our very own Bruce McCarthy, says, “Themes help teams stay focused without prematurely committing to a solution that may not be the best idea later on.”1 As Spool points out, it is important to focus most of the roadmapping effort on customer needs and problems because “the viability of a feature may shift dramatically, while the nature of an important customer problem will likely remain the same.”
Organizing roadmaps by theme and subtheme can have a number of distinct advantages. Some of those include:
Focusing on customer needs helps the team say “no” to unnecessary solutions.
Focusing on customer needs helps the team shift away from playing competitive catch-up (and instead gain competitive advantage by focusing on what’s missing or what nobody else is doing).
Focusing on customer needs creates a better and more intuitive narrative for sales and marketing.
A clearly defined need makes solution development easier.
Starting with customer needs provides development teams with more freedom and flexibility when considering solutions.
Customer needs are generally smaller in number than a laundry list of features, making the roadmap easier to read and use.
In our experience many product teams fail to hit the mark with their products because “so many features in today’s products are solutions without a clear problem to solve.”2 Their understanding of customer needs or problems is unclear or off-base. One of the reasons we believe themes are so important is because they force you to focus on the need before you even start to consider solutions—and then to evaluate how well each potential solution meets that need. The more rigorous you are about understanding customer needs, the easier it will be to develop the right solutions.
Ways to Uncover Themes and Subthemes
User Journeys and Experience Maps
One great way to begin unpacking customer needs when developing a new product or rethinking an existing one is through a user journey map. The journey map is a tool that helps you understand every step a user takes when solving a problem. Beginning with the moment the user realizes the problem exists, the journey then tracks the user’s actions through the current methods they employ to address it, and ends when the problem has been solved and the user moves on.
Good user journey maps are usually highly detailed, examining even the most minute actions, movements, and tasks. They help uncover opportunities to improve snags and pain points. These snags and pain points end up being the basis for your themes and subthemes.
If you’re looking to learn more about user journeys, we’d highly recommend James Kalbach’s book Mapping Experiences: A Complete Guide to Creating Value Through Journeys, Blueprints, and Diagrams (O’Reilly).
Figure 5-2 shows an example of a vacation traveler’s user journey. This is a very simple example, but here you can see we’ve identified high-level phases in the journey and then defined the more detailed steps in each phase the user will take when planning to travel.
Figure 5-2. A vacation traveler’s user journey
At times it can be helpful to go a level deeper on the user journey maps by plotting all of them together into an experience map (Figure 5-3). Experience maps show how customer actions relate across customer types and phases, and can also be used to tease out other dimensions like emotions, technology needs, and more. We create experience maps when we want to understand how everything fits together. They also help validate which points and opportunities are most important.
Jim Kalbach’s book, mentioned earlier, is a fantastic source for understanding how to properly explore, understand, and map journeys and experiences.
Figure 5-3. A user experience map
To bring the concept of journey mapping into more focus, let’s consider another example of a product that you may be familiar with: the popular ride-sharing startup Lyft. It’s fair to assume that one of the initial problems that Lyft set out to address was that in a hectic urban environment, it was generally hard to find a taxi (in addition, of course, to other taxi-related problems, like not accepting credit cards, dirty cabs, unpredictable fares, etc.). To competently solve this problem, the product team at Lyft needed to understand all of the incremental steps in the urban traveler’s experience. To do so, they might have created a map of the journey the user takes to resolve the problem.
In the case of Lyft, the customer’s journey usually starts with a need to go from point A to point B. Some steps in the journey might look like this, in order of experience:
Search for travel options.
Decide which travel method to use.
Employ chosen travel method.
Board the travel mechanism.
Travel from point A to point B (aka transit).
...and so on until the individual has reached the destination and moved on with their day.
The visual metaphor we like to use for the journey map is crossing a fast-moving stream. Imagine for a second your user is standing on one side of a rushing stream, trying to figure out how to cross without falling in. In order to do so, they need to choose which rocks they will step on, in what order, to land on the other side safely. Not only that, they’ll want to pick the easiest and most efficient path. In this metaphor, you can think of the stream as representing the user’s “problem” and the rocks as the steps in their journey toward solving that problem.
The steps in the journey map give you zones you can zoom into to understand the user at a deeper level. With this understanding, you can start to define each need or job in more detail. Those needs go on your roadmap as themes and subthemes.
Existing Product Needs
If your product team is working on an existing product, you may already have a good understanding of user journeys. Or then again, do you? How long has it been since you sketched out a user journey map? Have you ever gone a step further and created an experience map? In dealing with lists of feature requests and stakeholder demands, we sometimes forget to be discerning. In other words, many product people fall into the trap of accepting those requests at face value instead of asking the right questions, like “Why does this matter?” or “What need or problem does it solve?” or “How does it make the customer’s life easier?” or “Is there a bigger problem that needs solving?”
With existing products, it can be easy to operate on autopilot, especially when you’re in a rhythm of collecting and prioritizing feedback. Maybe we get overconfident from years of working on the same product with the same customer base, or maybe we simply get lazy. Regardless, the key is to focus on understanding “why” a need or problem is worth solving (or not). The user journey map is a great way to do this because it provides context. (Job stories and user stories also help ferret out “why,” which we’ll discuss a bit later in the chapter.) When you get a request for a feature, you can employ the user journey map to make sense of where that need fits into the context of the user experience. Is it a critical path item, or simply nice to have? Is the existence of the unsolved need or problem impeding the user’s journey in a significant way?
Teams working on stable existing products likely won’t need to create the user journey from scratch, but you can certainly benefit from returning to it to cross-reference how a request or demand fits into the experience. Once you understand how and where the customer experiences the need, you can work directly with them to validate the problem and test possible solutions. Returning to your user journey maps on a regular basis will also ensure they stay up-to-date. As human beings we constantly evolve and change, which means your understanding of your customer’s journey may already be out-of-date!
System Needs
So far we’ve talked about the concept of themes and subthemes in the context of customer needs. The reason for this, of course, is that your product exists to improve the life of the customer! However, not every need will come from your customer. You must also consider “system” or infrastructure needs. There are layers of functionality and operational tooling that need to be built into the backend or framework of your technology in order to make it work. You need to account for these critical items on your roadmap as well. Some product professionals differentiate between these two types of needs by calling them functional needs (customer-focused) versus technical or nonfunctional needs (engineering-focused). If it helps, you can think of your system as a special sort of customer.
To use another metaphor, we can compare building a product to constructing a home. The infrastructure or backend of a product is akin to the foundation, framing, rough plumbing, and electrical of a house. These forms and systems tie everything together and make the house functional. The flooring, windows, furniture, and other finishes are equivalent to the frontend layer that the customer sees and interacts with. Again, most of our discussion around themes to this point has been related to customer needs, because that’s who you’re serving. However, the infrastructure also has to be in place in order for the tool to actually function.
Let’s consider a simple example. In 2014, Evan’s product development firm built a mobile physical therapy application. The product was designed to replace the traditional one-page paper handouts that most physical therapists assign as homework for patients in between visits. These handouts are typically cartoon drawings of exercises with short, and often insufficient, text descriptions.
There are a number of problems with these handouts. Most commonly, patients misplace them and thus forget how to do the exercises or lose motivation altogether. No exercises, no healing. To address this problem, Evan’s company developed an interactive mobile tool with exercise videos, progress tracking, and a direct line of communication to the PT.
After the initial release, many client facilities wanted to address the need for patients to pay for services directly in the app. This customer need was added to the roadmap as:
Theme: Billing & payments
However, this theme required backend or system-level integration. Therefore, a few technical subthemes were included:
Subtheme: Billing & payments API integration
Subtheme: API integration testing
So while your roadmap should first and foremost be focused on customer needs, make sure you consider the infrastructure needs as well.
Opportunity-Solution Trees
Many teams generate a lot of ideas when they go through a journey-mapping or experience-mapping exercise. There are so many opportunities for improving things for the customer that they quickly become overwhelmed by a mass of problems, solutions, needs, and ideas without much structure or priority. We’ll cover prioritization techniques in detail in Chapter 7, but it’s first helpful to organize the information you have into a manageable framework.
Teresa Torres, Product Discovery Coach, Product Talk3, has developed a visualization for this problem that she says has revolutionized the way teams make decisions. She calls them Opportunity-Solution Trees and we’ve found them a brilliant way to distinguish solutions from the problem, need, or other opportunity they are intended to address—while at the same time tying them together logically.
Teresa says it all starts with a clear desired outcome. Remember those business objectives from Chapter 4: examples such as increasing your conversion rate or customer engagement? Those.(Hopefully you can see where this is going.) What Teresa calls opportunities, we call themes. We share the nomenclature of solutions and experiments designed to validate those solutions.
This hierarchy, similar to what we advocate in this book, simplifies decision-making by separating decisions among objectives, themes, and solutions. Each decision is a comparison among a small number of like things. Working down this hierarchy, level-by-level, allows teams narrow their testing and development efforts to solving one problem at a time.
Figure 5-4. A concept of the Opportunity-Solution Tree
Imagine, for example, that you are a sea captain in the 1500s and you have an objective to cross the Atlantic Ocean. You may encounter certain problems along the way such as scurvy or pirates. Preventing these problems become your themes. If scurvy becomes an immediate problem (because some of the crew are already suffering), you will begin to generate solutions such as feeding them oranges or grapefruit. Feeding them apples might also seem like a good idea in general, but since only citrus fruits contain the necessary vitamin C, apples do not solve the problem at hand and should be set aside. (See? This is why you should never compare apples and oranges!)
If the objective is a healthy crew, the themes in this example would emerge as: Healthy Diet, Regular Exercise, and Ship Cleanliness. Fruit is a solution (i.e., feature) and the experiment between Apples and Oranges could determine which crewmembers get healthy quicker.
Figure 5-5. An example of the Opportunity-Solution Tree
Using Job Stories and User Stories to Support Themes
Describing customer needs without getting into the solution can be tricky business. To make it easier, many product teams use a framework to tease out the reasons behind a need and justify its importance. The purpose is to prevent assumptions and avoid building things that don’t match the real needs of the customer. The two most common forms of this method are called user stories (from Agile software development) and job stories (from the jobs-to-be-done framework).
The format for user stories is typically:
As a [user type]
I want [desire]
So I can [result]
The generally accepted format for a job story is:
When [situation/motivation]
I need [desire]
So I can [result]
In each of these frameworks, the focus is on the customer, what they want or need, and (critically) why that’s important to them. Themes work in the same way but at a higher level, and we’ve developed a similar (but 33% simpler!) framework for expressing themes.
The format for themes is:
Ensure [result] for [stakeholder]
Some examples:
Make mobile experience as good as desktop for users.
Make sharing via social networks fun and easy for users.
Ensure access during peak times for users.
If you’re familiar with Agile methodologies, this will feel familiar—and that’s very deliberate. Just as Agile epics break down into their constituent user stories, we use user stories or job stories to support themes as well. The point is to make sure we answer why each theme is relevant or important before committing to it.
Let’s use the Lyft example again to look at how these concepts can all fit together.
| Term | Definition | Example |
|---|---|---|
Theme | A high-level customer or system need. | Avoid surprises for customers |
Job story | A motivation focused story about the customer that provides as much context as possible on a specific customer need.1 | When a user has to travel across town for a last-minute meeting |
Themes Are About Outcomes, Not Outputs
Many product people are used to filling roadmaps with features and solutions, and we can attest from experience that old habits die hard. The key question to ask yourself when faced with a list of concrete deliverables is why? Why are these things important? What will result from doing them? How will the fortunes of the company or the happiness of the customer improve? Why would we do this at all?
By asking yourself (or whomever is requesting a particular feature) why, you are attempting to discern the difference between the output requested and the result or outcome desired. In other words, you are attempting to distinguish the end from the means. Recall our discussion about output versus outcome from Chapter 4 in regards to objectives and key results. This is making a similar point, but in the context of themes. Table 5-2 gives some examples you can use to help you translate ideas for solutions into themes.
Notice that translating proposed outputs into themes leaves open the possibility there may be other—even better—ways to achieve the same outcomes. Maybe instead of an HTML5 redesign of the whole site, certain core functions mobile users like to perform on the go could be ported into a native iOS or Android app. That might be less work and more effective in achieving the result described in the theme.
| Output | Why? | Theme (Outcome) |
|---|---|---|
HTML5 redesign | Works better on mobile | Make mobile experience as good as desktop |
Twitter and Facebook integration | Allows customers to promote the product by sharing results | Make it easy and fun for users to promote our product |
Infrastructure work for scalability | App slows down under heavy traffic | Ensure access and that we can fulfill peak demand |
Relating Themes Back to Your Objectives
Now that you’ve identified needs and translated them into themes, your roadmap is starting to take shape and become useful. Before moving on, though, you must tie the themes on your roadmap back to your strategic objectives. This step is incredibly important because it helps you stay focused on the right things and avoid distraction. Let’s take a second to review the product roadmapping hierarchy again:
I. Product vision
The problem you’re solving, or the change you want to see in the world
II. Objectives
The high-level goals you want to accomplish in this next version of the product
III. Themes and subthemes
The customer needs or problems that you are addressing
What you’re striving for is to ensure that every step in the roadmapping process is incremental and builds on the one before it. Remember, your roadmap is the foundation or blueprint for what you’re building, so it first and foremost needs to answer the why. Each element informs and feeds into the next. Your objectives help you realize your product vision, and your themes and subthemes help you accomplish your objectives.
So, with your strategic objectives clearly defined and approved by all stakeholders, the next step is to make sure that every theme on your roadmap relates directly to your objectives. Look at each theme or subtheme critically with your team. It’s possible for a theme to link to more than one objective, and that’s fine. In fact, it’s great if a theme can inform multiple goals.
One good way to link themes to objectives is to color-code your objectives, and then tag themes with the associated color. Figure 5-4 shows an example of such a “theme card.” On the card, we’ve included a section at the top identifying the business objective the theme relates to. As you can see, the color-coded orange bar references Objective 3.
The theme card is only one possible approach. There are other ways to present this, but we’ve found this to be useful.
Figure 5-6. A sample theme card
Let’s think again about the SpaceX example from Chapter 4 and above. If one of the themes on the SpaceX team’s roadmap is “refuel in orbit,” we can link that to the objective “reduce the cost of space travel to what an average American family can afford.” Here we imagine that refueling in orbit is an efficiency-related priority, which, if executed successfully, should help lower the cost of travel. Figure 5-5 shows what that might look like in another version of the card format.
If any theme on your roadmap does not map back to an objective, this should be a warning sign. This is an incredibly important point, so we’ll say it again: every theme on your roadmap should relate to at least one of your strategic objectives! If you have trouble connecting a theme back to an objective, take the time to review the theme in question with your team to determine if it should be part of your roadmap at all. It may be that it simply needs to be reframed or reworded. Or maybe it needs to be moved to another column in your roadmap to be reconsidered in the next round.
As a final note, we want to stress that every time you plan a big update to your roadmap, you should review and reconsider your objectives. For example, when you’re ready to move things from the Next column to the Now column, or from the Later column to the Next column, this is a good time to reconsider your objectives. The reason is that as time passes, your strategic objectives will change. Your business or product may be making a transition, rendering some of your objectives obsolete. Or maybe some of your objectives have been adequately addressed for now and you want to prioritize other things. Regardless, each new version of your roadmap should start with revisiting your product vision and strategic objectives. Linking themes to objectives will then ensure you’re moving in the right direction and will increase the chances of your product adding real value—to your business, your customers, your technology, or all of the above.
Figure 5-7. Using a theme card to link a SpaceX theme to one of its objectives
Real-World Themes
The High Cost of Space Travel
In his roadmap to Mars, which we covered in Chapter 4’s case study, Elon Musk identified the core problem preventing people from emigrating to Mars: cost. His roadmap for developing a lower-cost interplanetary transportation system had to reduce the cost of going to Mars by 5 million percent. That sounds crazy, and the SpaceX team has not yet developed the technologies to make it work, but at the time of announcing this roadmap, they had worked out what would be necessary to make it work. The themes, then, of Musk’s roadmap are these four problems they need to solve:
Full reusability
Refueling in orbit
Propellant production on Mars
Right propellant
Fun as it is to think about interplanetary homesteading, let’s take a look at how themes work in more terrestrial product roadmaps.
Slack’s Theme-based Roadmap
The popular messaging platform Slack recently followed many others in publishing a public roadmap via Trello, as shown in Figure 5-6.
Details on anything not yet released are thin, and the names and descriptions of individual items are chosen with the goal in mind, rather than the specific deliverable. Items like “Streamlined app development” and “Deeper integration points” provide the team leeway in determining the best solution and design for tackling each problem. (Some others are more specific, including “Advanced link previews.”)
What best communicates where Slack is focused, however, is the “About this roadmap” card, where they say the roadmap “describes our platform development plans for the benefit of developers creating tools that interact with Slack.”
They then add: “There are three major themes in our platform roadmap that we want to highlight,” including app discovery, interactivity, and developer experience. They cover a little about the goals of each, with explanations like “we’re doing more to help customers discover the right apps and engage with the apps they’ve already installed.” Each roadmap item is then tagged with one or more of these themes to indicate why it is important to their chosen customer, the app developer.
With very few details, Slack’s roadmap effectively communicates who they serve, what their priorities are and why, and just enough details about what’s in the hopper to make people confident in their direction.
They can do this because they know who their customer is and what they expect. As product executive and strategist Sarela Bliman-Cohen explains, “In order to have a good roadmap, you need to look at the markets you’re after. You need to identify the ones where you can succeed. Once you understand the markets you’re after, then you can have a thematic roadmap.”
Figure 5-8. Slack’s public roadmap on Trello
GOV.uk’s Gantt Chart with Benefits
GOV.uk provides an online service to help UK citizens find government services and information. Their 2016–2017 roadmap, published in ProductPlan, does a good job of organizing a lot of detail into themes, as shown in Figure 5-7.
Each of the major white sections describes a long-term theme such as “Make it possible to join content together as services,” and contains a few subthemes, like “Improve tagging, navigation, search, and notification systems.” This is clearly an attempt to get more specific and describe the value of their planned work in a way that might be understood by outsiders (though it does still contain some tech jargon).
If you click on one of those subthemes, it expands to show you the phases of work going on to support that objective (see Figure 5-8). Many of these (“Discovery on moving to PaaS,” “Alpha on moving to PaaS,” “Move 1st frontend apps”) may be cryptic to the average citizen, but you get a sense of things progressing, and we applaud the attempt at transparency. These additional details provide a sense of status for each item, which is a very helpful component to add to the roadmap. We talk more about this in Chapter 6.
Figure 5-9. GOV.uk’s roadmap on ProductPlan
Figure 5-10. Expanding one of GOV.uk’s objectives to see the phases of work going on to support it
Note
Themes are customer needs.
Note
Not features.
Summary
Uncovering user needs is an incredibly important part of product roadmapping because your product exists to make the customer’s life better. Thus, most of the items on the roadmap should be focused on serving the customer.
User journey maps can be used to outline a user’s path through the problem space. A close inspection of those maps will help you clarify the customer’s needs. Once you’ve validated the needs, you can add them to your roadmap as key themes or subthemes to address. Those themes and subthemes can then be vetted and supported by job stories or user stories. Buttressing your themes with job stories helps you cross-check and validate their importance to the customer and the value in solving for them. Finally, make sure every theme or subtheme on your roadmap is linked to a strategic objective and contributes to the overall goals of your product.
One key point we’d like to reiterate: stick to needs when defining themes and subthemes. You will be very tempted, believe us, to start brainstorming solutions or sketching ideas. Avoid this temptation! Stay focused on the needs at this stage. Defining solutions will come next, and developing them will be a whole lot more fun and effective when you’re confident about why they need to be implemented.
1 https://medium.com/uie-brain-sparks/themes-a-small-change-to-product-roadmaps-with-large-effects-a9a9a496b800
2 Ibid.
3 For more about the Opportunity Solution Tree see Teresa Torres’ blog: https://www.producttalk.org/opportunity-solution-tree