Features and Solutions: How They Can Work with Themes

If themes represent the customer’s most important needs or problems to be solved, then features (or solutions) are what you plan to build or implement in order to help users manage them. Even though we advocate focusing on customer needs during roadmapping, it is sometimes appropriate to account for certain solutions on the roadmap as well. In this section, we tackle how themes and features can be combined successfully.

Where Do Features Appear on the Roadmap?

When adding features to a roadmap, it’s important to retain the context of why they are there. We don’t want solutions to replace themes on the roadmap, and we don’t list features and themes side by side. Instead, we recommend adding features as subthemes so it is clear what problem they are intended to solve. As a reminder, subthemes are more specific needs, and generally provide more detail about the need expressed in the higher-level theme.

In Figure 6-1, which uses the physical therapy example again, you can see the product team has included three subthemes. The first two are need-based, but the third clearly defines PayPal as a probable solution. As this example shows, subthemes can be need-based, but they are also a great way to capture known or probable solutions when appropriate.

Figure 6-1. Subthemes can relate to both needs and probable or known solutions

Buffer’s feature-level roadmap

Buffer, the social media sharing tool, has taken sharing to new levels, publishing information on revenue, salaries, diversity, and, as of recently, their product roadmap, shown in Figure 6-2. Like the Slack example we showed earlier in the book, Buffer is using Trello to communicate what it is working on (or planning to). Here, the individual items are very specific as to the deliverable planned. Labels like “Pause Button” and “Allow multiple admins for Business customers” leave little room for discovery or experimentation and do not describe the problem to be solved, job to be done, or value to the user.

Buffer takes transparency far here, allowing customers to comment and even vote on individual features (Figure 6-3). Buffer also solicits feature requests, which can be viewed, commented on, and voted on in turn.

Many product people are rightfully wary about sharing this level of detail with customers, as are we. Early in the process—when specifics are not certain—problems, needs, jobs to be done, or other ways of framing the theme of the effort are usually sufficient.

Figure 6-2. Buffer’s public roadmap on Trello

Figure 6-3. Buffer allows customers to view, comment, and vote on individual features

Using Stage of Development

Before being released to the public, products generally pass through several steps in the development process. Different industries and individual organizations use their own terms, but commonly there is a discovery, market research, or R&D stage before stages like design, testing, or prototyping. These are then followed by stages with names like development or pre-production. In the software business, there are often stages approaching a first general release called alpha and beta or early access, where a limited set of customers test the product to provide feedback. Labels like this clearly convey to the team and stakeholders where we stand on solving for each need. In early 2017, Evan and C. Todd worked with the Spotify product team to identify opportunities for improvement in their roadmapping process. During that workshop, one of Spotify’s lead product managers shared a version of her roadmap. On the roadmap she’d tagged each item as either “think it,” “ship it,” or “tweak it.” In this simple way, her team was able to indicate the stage of each item on the roadmap to all stakeholders. When a stakeholder sees an item labeled “think it,” they know the theme is still being considered or explored.

Another interesting insight about the Spotify example is that status labels also help differentiate between themes and features. Any item labeled “think it” has clearly not been solved for yet, and therefore by definition is a theme. Any item labeled “ship it” or “tweak it” means that a solution has been chosen, and can therefore be considered a feature. This is a great example of how a team might use status to provide additional context to the roadmap.

Communicating Confidence

In order to be 100% confident in our ability to execute on a roadmap item—or that a particular item will still be a priority months from now—we’d have to be able to predict the future. Since no one we know possesses that power, we’ll go out on a limb and say you should never have 100% confidence in anything on your roadmap. By nature, the roadmap is a strategy tool that outlines what we think is important to our stakeholders. Yes, that information is generally vetted and validated before it hits the roadmap, but there’s no way for us to be 100% about any of it.

To a certain extent, the timeframe columns on your roadmap will indicate, at a high level, your confidence in your ability to tackle each theme. Generally, confidence is strongest for items in the nearest column, and wanes the further out you go on the roadmap.

However, even with the implied confidence inherent in roadmap columns, we often add a confidence score to each column as well. For example, we might attach a 75% confidence to the Now column, 50% confidence to the Next column, and 25% confidence to the Later column. These confidence percentages represent our level of certainty that we will deliver on those items in those timeframes.

Predictive Index uses something like this—in its case a decreasing gradient bar—in its roadmap to make it clear that certainty about the contents of the roadmap drops as timeframes become more distant (Figure 6-4).

Figure 6-4. Predictive Index uses a decreasing gradient bar to indicate that confidence drops as timeframes grow more distant

Some product people like to include confidence estimations on individual themes and subthemes. If the additional granularity on each item is helpful for your team, adding confidence to each item on the roadmap can be valuable as well. We’ve seen this work best when a column represents a general “confidence threshold.” For example, if our Now column represents a 70%–95% confidence estimate, then each item can have its own confidence number within that range:

NOW (70%–95%)

• Theme 1: 95%

• Theme 2: 85%

• Theme 3: 80%

• Theme 4: 70%

Finally, some product teams like to include a confidence separation line in their Now column (Figure 6-5). The idea here is that the team is confident in their ability to address anything above the line in the next release. Anything below the line is aspirational. If they get to it, great—bonus points! If not, no harm done. The team can simply move (carry over) the items they miss to the next column or version of the roadmap.

Confidence Questions

Ask yourself these questions when deciding whether to include confidence information in your roadmap:

• Does your roadmap include specific timeframes—e.g., months, quarters, or years?

• Does your roadmap show themes or features far enough into the future that you find yourself reluctant to commit to those items?

• How regularly does your development team hit dates projected months in advance?

• Do your stakeholders tend to assume that if it’s written down, it is a promise?

• Have you already included stage-of-development information that might provide enough insight into confidence?

Figure 6-5. How a confidence separation line might appear on a roadmap

Identifying Target Customers

Many times a product serves more than one customer type. For example, if you set out to solve a problem in the education space, your product might consider the student, teacher, administrator, and even the parent. In addition, your product’s users might be different from the actual buyer. If you have to solve for multiple customer types in order for your product to be valuable, then it’s a good idea to identify which themes or features apply to which customer types.

On the roadmap this can be as simple as tagging or labeling each theme by the relevant customer type (see Figure 6-6). Other teams create rows in the grid of their roadmap, or swim lanes, for each type of user to create a clearer separation.

When identifying customer needs, it’s important to consider all of the roles or personas (recall these terms from Chapter 3) your product will solve for. Forcing your team to tag each theme by customer type can help ensure you’re focusing on the right customers at the right time.

Target Customers Questions

Ask yourself these questions when deciding whether to include target customers in your roadmap:

• Do you have distinct customer types with different needs?

• Is it important to achieve balance in addressing the needs of each?

• Conversely, are there one or two customer types that are more important?

• Will clarifying the customer type be helpful in guiding stakeholder conversations?

Figure 6-6. Specifying the relevant customer/user for your product

Tagging Product Areas

Similarly, it can be helpful in ensuring you’ve covered the essential functionality required by your product to annotate the items on the roadmap by area within the product. A software product might have areas such as user interface, platform, administration, and APIs. A product like our garden hose might have weather surface, exoskeleton, water channel, and connectors.

Each may have separate sets of details such as stage of development, but more important, each must receive sufficient attention on the roadmap to come together into a fully functioning product that meets customer needs. Each may also have separate business objectives.

Product areas can be labeled on themes and features in a similar fashion to target customers or stage of development by using color coding, text labels, or separate rows on the roadmap. Be careful of information overload, though, and consider which of these labels is most important to your stakeholders! (Chapter 9 contains guidance on which stakeholders care most about what information.)

Secondary Components Summary

Summary

You learned in this chapter when to incorporate solutions or features into the theme-based roadmap described in Chapter 5. Even though we like to keep the roadmap at the needs level, we acknowledge that features and solutions sometimes need to be included. Generally, we do this by adding them as subthemes to ensure the why is retained in the roadmap.

We also spoke about tagging items on your roadmap with additional information such as stage of development, confidence, target customers, and product areas. This additional detail forces you look critically at each item, and provide your stakeholders with enough context to answer their questions and assuage their concerns. The more work you do up front to clarify these details, the easier it will be to communicate with your stakeholders and gain buy-in.

The next step is to start prioritizing to make sure you’re addressing everything in the right order. Chapter 7 will walk you through this, so let’s get into it!