Feature-less Roadmap: The Balance Between Delivering Concrete Features vs. Planning with High-level Themes

What’s the point of a product roadmap if it doesn’t have any features on it? Isn’t the entire reason for creating a roadmap to specifically layout which features are coming? And when to expect them?

That’s not a bad assumption. Most roadmaps are chock full of features, and 80% of the time they . But a feature-laden roadmap not only assumes your strategy is locked in place, but that the execution is already figured out as well.

There are inevitable downstream repercussions to believing that both strategy and execution are immediately figured out. Organizations can rapidly shift from “solving customer problems” mode to becoming . The pressure to treat a roadmap as a the list as you deliver them—may cause a team to miss the forest for the trees. There’s so much emphasis on the “what” that the “why” gets pushed to the background. The risk is that companies will start to go through the motions instead of continually scrutinizing and adjusting their roadmap.

Another danger is the implied commitment that once features appear on a roadmap they will definitely be delivered, even if the dates slip a bit. Since many roadmaps extend out 18-24 months, do you want to promise specific functionality two years from now?

But there’s another way—and frankly, I think a better way—to communicate long-range plans and strategic thinking without making unnecessary promises: theme-based roadmaps. What’s so great about themes? Let’s dive in and see.

Why Themes?

Your product may technically be a log/collection/huddle/stack of functionality, but that’s not what your customers see. For them, it’s a better way to plan a vacation, streamline accounting processes, or distract themselves by blasting zombies in a post-apocalyptic Hellscape.

They want frictionless experiences making their lives easier, more fulfilling, more efficient and/or more entertaining. Individual features help your customers achieve those outcomes, but no one wakes up in the morning dreaming of single sign-on or bulk importing CRM data (even when they do spend the afternoon peppering your feedback channels with specific feature requests).

“It forces you to consider ‘why’ you want to develop certain products or services,” says of Settled. “I always take out the “feature” layer purely because I don’t want us to be pinned down to one solution.”

Connect plans to strategy

Features are how you get the job done, but they’re merely a means to an end. Thus they shouldn’t be the focus at the roadmapping stage. Themes speak to larger goals and objectives, which is what stakeholders ultimately care about.

Theme-based roadmaps also do something most feature-based roadmaps struggle with: they build alignment and consensus. Roadmaps listing dozens of features create opportunities for endless debate, confusion, and disagreement amongst stakeholders. They become a convenient distraction.

An exec wants drag-and-drop. A salesperson clamors for double-byte language support because they have some hot leads in APAC. Marketing lobbies for Salesforce.com integration because they got a booth at Dreamforce.

Themes elevate conversations and gather momentum around larger concepts. These themes as a whole will have a greater impact than any one-off feature.

Instead, to use the example of the battling executives above, it’s prioritizing improving UX vs. international support vs. 3rd party integrations. Agreed-upon corporate goals and KPIs should dictate which theme moves to the front of the line. This will transport the conversation from pet projects to larger, big-picture initiatives.

Shift to a more timely and topical debate

means more contentious (yet ultimately less important and low leverage) discussions get delayed. This reserves the timeliness of feature-specific decisions until you’re actually ready for product development work. No more deciding months or years in advance which specific features will be added. Instead, discussions occur far closer to implementation, when more data and context is available. There may eventually be bickering over which features are more important or urgent but those conflicts exit the roadmap process phase and move to the implementation phase where they belong.

This also enables you to be far more adaptive to changing market conditions while adhering to your overall product strategy. No longer will you be locked into prescriptive, solution-based plans too far in advance. This enables nimble execution to coexist with long-range planning. It additionally prevents preemptive and unnecessary feature commitments.

“You’re going to get distracted. You’re going to get distracted by a loud customer. You’re going to get distracted by the next shiny object. Someone’s going to come to you with a fantastic idea, and that idea is often phrased in terms of a feature,” says ProductPlan’s Jim Semick. “With a theme, though, it helps you stay on track. You’re always tying back these things that you’re delivering, .”

Make the move to theme-based roadmaps

While it might be new for your organization, you’ll be in good company if you adopt theme-based roadmapping. That’s because so many product leaders realize that tying roadmaps to product strategy instead of specific deliverables is the best way to get stakeholder alignment. Plus it means your roadmap won’t be outdated the moment it’s published. Keep in mind the following two things.

1. Start with strategy

If you’re not sure where to begin, . If you look at the existing objectives, you can work backward and translate them into themes.

For example:

Let’s say increasing adoption by human resources professionals is a strategic goal. Break that down into which big-picture themes would get you there based on the customer research you’ve done on that segment.

Those themes might include “Improving Benefits Management” or “Automating Professional Development & Training” or “Simplifying Payroll.” Each would then have a bunch of supporting features prioritized beneath them.

2. Specific but not specified

Themes are far broader and high-level than particular features, but should still be defined using specific language. The intention of a theme isn’t for it to be a catch-all, but rather a very particular bit of you’re adding to the product.

And while a theme will likely include many features, the measurable goals and expectations should be at the theme level. Let’s say your theme is “Leveraging Social Media.” That includes integration with Facebook, Instagram, Twitter, and Snapchat. The metrics shouldn’t be specific to each platform, but rather an overall goal of “increasing brand awareness” or “building social engagement.”

There’s also no perfect size for a theme; it could be knocked out in a single release or span multiple quarters depending on its scope and scale. So don’t feel like this is just another way to break your roadmap up into chunks of time; each theme will take as long as is deemed necessary.

Finally, make sure your themes are iteration friendly and can inspire a stream of possible solutions. Let’s say an upcoming theme is “Going Mobile,” where you’re planning to make a significant chunk of functionality available on mobile devices. That doesn’t mean it has to all happen at once. You could easily bite off making sure the top five features work on phones and tablets. You can then reserve additional work for “More Going Mobile” in another 12 months.

Features are neither gone nor forgotten

Does this mean features will never appear on your roadmap? Probably not, but .

With tools like ProductPlan, individual features are slotted within the themes, epics, and stories. They remain hidden from view (but still available) during most presentations and conversations. You’ll still know they’re there. If someone asks about a particular one you’ll know where that feature fits into the plan given the current thinking.

Restore sanity and strategy to your roadmapping process with theme-based roadmaps. Break free from the feature factory mentality! Check out the webinar to learn more about .