Don’t build a roadmap for a SaaS product, build a valuemap instead

After 10 years of using roadmaps, I decided to ditch the standard way and build a valuemap. The result? Everybody loves it and we can happily deliver value to customers instead of organizing boxes.

What’s behind the corner? No idea! But hell… it looks like a roller coaster to get there. Putting an item on the roadmap is the pinnacle of product leadership, but delivering it brings a different story . Don’t take your customers and teams on the bumpy ride to promise-land with you.

First, do you need a roadmap?

In my previous blog, I argued that if you are in the early market selling to technology enthusiasts and visionaries you don’t need one. But as your product grows and you get past the early adopters, things start to change rapidly. The story often goes like this: You have initial traction, a few big logo customers, but most of the deals don’t close quickly, and those that do close are for pilot projects rather than full-scale adoption. Your customers are asking for strong customer references, comparison sheets with your competitors, roadmaps, ROI calculators and a bunch of whitepapers on various topics. You are in the Chasm and you are selling to Pragmatists who are looking for a whole product. Selling to pragmatists is the sign that you have reached a mainstream market segment where people want complete solution and convenience rather than the newest thing on the market. Making the leap to the mainstream market is not an easy task. There are many things that need to evolve in your organization, but one of the essential artifacts that often pops up on sales conversation is the need for a structured roadmap.

(This is the phase where most startups perish and disappear — 42% to be exact.)

Why is there a need for a roadmap? Pragmatists love to be on a beaten path — it’s proven, safer and they won’t be blamed for going with the flow. As your product scales, you will often have multiple decision makers involved in a deal that command the need for more reference materials including a roadmap. But don’t jump the gun to deliver a fancy roadmap, because this is when the pain starts. And don’t hire a product manager to build a roadmap for you just because your customers demand one.

The typical roadmap and its shortcomings

We have all seen it. A bunch of features spread out over a timeline that you try to stick to. But pragmatists want to use your product roadmap to make business decisions apart from the one on whether to buy your product or not. And if you fail to deliver, the consequences might be detrimental for your business: loss of confidence, angry customers, high churn rate and internal stress.

What are the hidden costs of building a roadmap?

Doesn’t communicate value

It’s focused on features written in a way that your team and some customers might understand, but it’s often too specific and complex for prospects. It doesn’t communicate the value that it will deliver as this is left for interpretation. It’s a common case to deliver a feature and fail to meet customer expectation only because the objectives and key results of this feature weren’t obvious on the roadmap.

No prioritization context

As a product leader, you are making a lot of decisions and rationalization to come up with the right priorities for your roadmap. With a roadmap, your rationale ends up hidden. Just look at the following roadmap demo example from Asana on how prioritization typically looks like. It’s definitely (not) easy to spot why Email API integration is much better than Faster mobile app (75% faster)

Pressure to stick to it even if no longer optimal

Your team and customers require a roadmap. They think it’s an essential input to most of the decisions they make. Whether to buy your product or not, or what the release themes will be or what needs to be researched ahead of time. And because it’s just so simple to put an item on a roadmap without incurring any costs today, you often end-up with a sub optimal plan to which you are bound to stick to.

Change means communication

A roadmap is a commitment, and if you want to change it, you have to deal with a lot of communication both internally and externally. This often can be a more stressful exercise for your employees rather than your customers. I had spent countless hours of communication internally to ensure our engineering, sales, marketing, and support is well aligned on what’s coming, what’s not coming and why the plan has changed. These “change” conversations and fire fighting are hard to handle and usually lead to zero improvement of a product itself.

Hyper-focus on roadmaps

What makes a roadmap so hard to do is also the fact that nowadays everybody is a roadmap expert. You can easily blame the roadmap when there is a bad business model, inefficient teams or unwilling to change management teams. Just search for Product Manager jobs in Glassdoor and you can spend 1-hour enjoying crazy definition of how a product manager should do his job in regards to a roadmap:

“Use evidence-based decision-making to intelligently prioritize and align the executive team with your product roadmap. You’ll regularly present why you’ve selected one direction over another for each iteration of the product, using compelling explanations backed by real data.” by Brandyourself, New York

Your executive team wants to see your roadmap so that they can perform their “Swoop and poop” management style.

Your best alternative: Valuemap

At Payhawk, I decided to ditch the concept of a roadmap and go for what I call a valuemap.

Valuemap focuses on value rather than time to group features. It’s the best way to communicate your path with customers in a SaaS world.

Super simple structure

You group features by value drivers that either benefit customers or your team.

• Customer value drivers answer the question: How do we save customer’s time or money or help them make money?
• Internal value drivers answer the question: How do we save our time or money or make more money?

Depending on the goals and problems you face, you can first prioritize the drivers by order and then prioritize the features in each driver on how to get there. Any bullsh*t on the valuemap will be instantly obvious to everyone.

It’s great for validation

Just like UX wireframes with no design emphasize your information architecture, a valuemap with no delivery schedules emphasizes value. At Payhawk, we uncovered a new customer segment and split our product in two editions to serve two different audiences based on whether a company works with an internal or external accounting team. A big chunk of our customers didn’t see value in some of the things that we were doing while others were overly excited about them. Since our conversations were mostly focused on value, we manage to understand what resonates for each segment most.

If you struggle to organize your current map into a valuemap, then you have a scrappy plan in place.

No commitment on dates

A plan is nothing, but planning is everything. The roadmap is bound by certain — dates, months or quarters. This is another pressure point where you could waste time debating about when rather than what. The valuemap is perfect for continuous delivery where your priorities and ideas can change quickly.

Inspire democracy and new ideas

Good ideas can come from everywhere, but I have often observed developers unwilling to suggest ideas because of the super-busy looking roadmap and tight delivery scheduled ahead.

Keep everybody on the same page when prioritizing

This is best illustrated in an article by Camille Fournier, CTO of Rent the Runway who has been struggling to get her team hit product milestones due to their desire to build quality and new systems. She has been struggling to communicate with her technical team that:

The job is not to build technical architecture, but to create living systems that support the growth of whatever business you are part of.

Your valuemap can promote great discussion around what’s important for the business and how this can align with your internal struggles. It’s often that the pressure a product manager feels is hardly visible by the engineering team.

No need for features “organization”

All of the roadmap and software tools out there are pushing you to organize your product in areas — Mobile app, Web portal, Back office and so on. This is how our productboard roadmap looked like before we ditched it.

We love it so much that we will be delivering all of our Payhawk release notes in this format, so everyone can see where and what value we add with each iteration.