Build products that make a difference in each user’s work and life.
When people think of product management or product strategy, the first thing they think of is the product roadmap. And for good reason. Roadmapping offers a tangible view into the product development process. That’s why you’ll find so much information about how to approach and build better roadmaps. But as valuable as they can be, you need to make sure they don’t handcuff your product development process.
Everything starts well. You might spend weeks or more researching and planning the perfect 12-month roadmap. You hold a big meeting to unveil your amazing product roadmap. Everyone is impressed. It’s a huge success, and now it’s time to execute.
But as you begin to deliver, your team starts to fall behind. Your customers start to ask for features you didn’t plan for. Market dynamics change and new competition heats up. To make matters worse, the first couple of features you launched didn’t have the impact you were hoping for.
Your roadmap is starting to look dicey. But after going through a significant effort to produce it and get buy-in for it, it’s looking like you’re behind schedule and not meeting expectations. There’s a ton of pressure on you to figure out what’s going on.
That process is a recipe for disaster, and it happens when an organization views the roadmap as a sole and static record of authority. After all, there was so much planning that went into creating it! In effect, they become handcuffs in the product management process.
That process is a recipe for disaster, and it happens when an organization views the roadmap as a sole and static record of authority.
To break free from your handcuffs, you need to shift your perspective of roadmapping altogether.
I think what happens in a lot of organizations is that they look at the roadmap as a project management deliverable. In reality, your roadmap should articulate what’s coming next as part of a broader strategy or vision. It gets people excited about what’s coming next and aligned on how to get there.
But if you present the roadmap as a timeline with hard dates, then it essentially becomes a project delivery plan. It’s not to say there isn’t a space for this and obviously, you need to work with project management to get the product released to customers. The purpose of your project plan is to communicate dates. The purpose of your roadmap is to communicate how the product impacts business objectives. Prioritize communicating how Feature X will improve churn as opposed to its release date.
But as market dynamics change, customer insights change, and as you learn from interactions with customers, how you hit your objectives will likely change. Understanding this makes it more natural to communicate changes both to the general timelines and expected features when necessary.
This framing also allows for a more dynamic roadmap based on feedback coming from places such as sales, support, etc. This collaboration makes everyone a part of the process. Your organization will better understand that your roadmap is an ongoing project; something that needs to be continuously worked on and updated.
Roadmap handcuffs create anxiety that generally comes from some unknown fear of the future. “How can I pull off that feature 3 quarters from now when we’ve done so little research on it? Is it going to be possible? The whole company thinks that’s coming then!”
Planning your roadmap for the next 12—18 can be too far ahead to be realistic. In today’s competitive market, things change so fast. Not only is it challenging, but it could create additional risk. You could very well end up building features you don’t need in 18 as it’s hard to forecast that far out.
When you’re focusing on the short-term, you might consider building a rolling roadmap — meaning you continuously manage and update it.
For example, say you planned a new roadmap for January through June. Once your team has gotten through the January section of the roadmap, add a July section. Just keep going. The rolling roadmap is something that John Cutler, a Product Evangelist at Amplitude, advocates:
Now you might be thinking, “How do you convey your long-term product vision with this kind of setup? If you choose this method, there are still ways to communicate your vision. It may be through company presentations or even adding a “long-term” section to your roadmap.
What’s the point of your product? It’s to help your customers do something. Without your customers, your product is useless. If you want to break free from your handcuffs, you need to make sure your roadmap is entirely customer-focused.
By tying items on the roadmap to customer insights and feedback, you can simultaneously add credibility and flexibility to your roadmap.
You add credibility by having an answer ready when someone asks, “why are we doing Feature X instead of Feature Y now?” You can point directly to the feedback to explain the prioritization. Without this data, the ‘loudest voice in the room’ may make these decisions. Unfortunately, this may deviate from the customer needs creating unhappy customers and underwhelmed stakeholders.
You add more flexibility by being more responsive to changing customer needs. Say you’re two months in, and your customers give you feedback about what you’ve already built, which forces you to reconsider something about your product. With a flexible, collaborative roadmap, you’ll be more easily add or remove new feature ideas into your roadmap.
If your customer is the center of your roadmap, you’ll build a better product. But by tying your roadmap to the customer, you never lose sight of them. This helps you break from expectations created from a different set of expectations.
There is no bigger trap than treating the dates on your roadmap as a means by which you should measure your success as a product manager. Your roadmap should be a guide, not a deliverable to evaluate progress.
When you focus on delivery as a metric of success, you can lose sight of your customer and instead deliver “productivity theater.” That could turn your team into a feature factory that delivers features that your customers don’t understand or want.
It can be hard to balance delivering features on time and delivering quality consistently.
That’s why you need to choose customer-focused metrics as success metrics for your features. Here are a few good ones to start with:
Your primary goal isn’t to deliver value based on a timeline. Your goal is to deliver a product that will positively impact your company’s objectives.
If you want to build a great product that can compete in today’s rapidly changing market, you need a roadmapping process built around the agile methodology. Spending time to create a long-term roadmap that implies the ability to see far into the future may put you in handcuffs.
Break free from your old roadmap handcuffs by changing how you communicate, focusing on the customer, prioritizing the short-term, and not letting your roadmap be the success metric.