Themes: A Small Change to Product Roadmaps with Large Effects

Themes are a Promise to Solve Problems, Not Build Features

A typical roadmap feature might be a data export capability to Salesforce. Customers may have even asked for this feature, saying they’d buy a ton more licenses if the product made it easy to move the data.

But with Bruce’s Themes, the product strategy team would research why customers want to move their data to Salesforce. How does it make their life easier? Might it be even better if the data could move in both directions? How up to date does the Salesforce data need to be? What happens after it gets into Salesforce? What’s the bigger problem that needs solving?

That last question is quite interesting. By understanding how having the data exported to Salesforce contributes to solving a bigger problem, the team may uncover interesting alternative solutions. Maybe Salesforce is just an intermediate stop along the way to becoming something bigger? If so, maybe there’s functionality the team could add to the product (or even better, might already exist but is currently hard to find)?

Bruce says Themes help teams stay focused without prematurely committing to a solution that may not be the best idea later on. This is particularly important for roadmaps that go out 2, 3, or more years into a fuzzy future. The viability of a feature may shift dramatically, while the nature of an important customer problem will likely remain the same. As each part of the roadmap gets closer, the customer problems often become clearer, making solutions easier to find.

We’ve found this to dovetail nicely with another phenomenon we’ve observed: When a team has a clear definition of a problem, solutions are often easy. Usually, the biggest source of trouble with defining solutions comes from unclear problem definitions. By making the problem the centerpiece of the strategy, more resources will be available to help with definition.

Strategy with Customers at the Center

The sheer brilliance of Bruce’s idea is how, with a single gesture, learning everything about the customers becomes the most important focus of creating the product strategy. When companies talk about features, they are saying, “Look at us. Look at what we can do.” When companies talk about the problems of the customers, they are saying, “Look at what you’re dealing with. Look at how we want to help.”

Whereas the company used to want to have dozens (or in some cases, hundreds) of features in each release, customer problems can be smaller in number. If it’s a big problem that lots of customers are dealing with, it can be the only thing included in the release.

Now, after the team starts to solve the problem, it might mean they make a bunch of changes throughout the product. But each of those changes goes straight to explaining its role in solving that specific customer problem.

This becomes an important razor for deciding what takes priority. Pick 2 or 3 important customer problems for this release. Any change to the product that doesn’t help solve one of those problems is eliminated from the backlog.

So many features in today’s products are solutions without a clear problem to solve. This razor keeps teams focused, which means time to delivery will often be faster.

User Research Shifts from Nice-to-Have to Must-Do

You can’t fill a roadmap with customer problems if you don’t know anything about your customers. By moving away from the invention of features (which can be done independent of whether customers need what you’re building), the roadmap technique requires deep and thorough customer insights.

The best way to acquire these insights is through solid, constant user research. Product managers now need to initiate customer visits and observations, looking for what those customers truly need and what obstacles they face.

User research changes its status, from a luxury of the product design process to a preliminary requirement of the strategy process. Tracking and synthesizing different problems now becomes a standard way to talk about how the product is built. Customers are at the center of every discussion of what’s in and what’s out.

Abandoning the Game of Competitor “Catch-up”

Another major benefit of the shift to solving customer problems is the shift away from playing competitive catch-up. As the product team studies what their customers need, they won’t start by looking at what the competition has. Any competition still working with a feature focus will miss opportunities.

Almost always, important customer problems aren’t being solved by any companies in the competitive landscape. This is because everybody is constantly trying to out-do each other, not paying attention to customers at all.

The first company to move to defining their roadmap as solvable customer problems gets a jump on the competition. They provide innovative solutions just by solving pressing problems, getting an immediate jump on what the competitors incorrectly think is important.

Instead of doing a competitive analysis, the strategy team is now talking about what’s missing in the marketplace. They’re completely focused on what nobody else is doing. That’s a solid competitive advantage.

Marketing the Story of the Solutions

Marketing groups face a chore when it’s time to tell the world about the next major release of their product. They have to gather up all the features and synthesize a narrative that makes people want all those things. What is the big story about how these independently designed and developed features make the customer’s life better?

Bruce’s Themes replaces that chore by handing the narrative to the marketing group on a silver platter. Here are the problems we set out to solve and here’s how we solved them.

Every element of the new release tells the story marketing needs to tell. (And if the marketing group was smart, they were part of the strategy team in the first place, so they saw this coming their way all along.)

Developing a More Cohesive Design

Part of solving a customer’s problem is making sure you don’t make it worse. By having the problem as the starting point for the project, the development team has an instant baseline to measure against.

Given a customer problem, the team will come up with multiple solutions. Picking the best solution becomes a trade off of effort against the improvement they can deliver. Determining these factors is easier when they start with a clearly defined problem. Without a commitment to specific solutions, the team has flexibility.

One consistent problem with the feature approach comes when the team tries to wedge more features into an already crowded and complex product. They run the chance of making the product even more difficult to use because the new features don’t dovetail nicely with what already exists.

With Bruce’s Themes approach, the team now has the power to say “no” to any solution that makes the problem worse. That includes making the product more complex. The base requirement of making the customer’s life easier forces a more cohesive, simpler design to emerge.

Shifting to Themes Is a Challenge

Organizations who have grown up in a feature mindset will struggle with the shift to customer problems. The primal desire to ask, “But what feature are we shipping?” will not go down without a fight. Vigilance among the product strategy team (and air cover from senior management) will be a basic requirement to make Themes work.

However, after the team gets the hang of thinking in terms of solving customers’ problems, and reaps all the benefits that come from that, it’s likely to become the norm. The wins felt by every part of the organization as customers are put into the center of the strategy process will easily make them a driving force in the market.

Thanks to Bruce McCarthy for providing the fantastic idea of Themes.