One of the most common misunderstandings about product roadmaps is that their job is to list features. But they can — and should — do a lot more than just that. In fact, it just might be the case that roadmaps should be ditched altogether.
In their place, teams should focus on outcomes.
What exactly does that mean? Here’s how product managers can learn to steer away from making bad roadmaps and veer toward better outcomes instead.
Re-Examining a Trusty Tool
Product managers inevitably find themselves using product roadmaps. These classic developer tools have served as the yardstick of the development process for many years. From in-house stakeholders and top-level managers to the customers themselves, everyone involved in the launch of a new product has become accustomed to relying upon roadmaps as barometers of timeliness and success.
But there’s often a huge problem with that…
The Problem With Product Roadmaps
By creating a product roadmap, teams are essentially handing stakeholders a checklist by which to gauge their own performance. There’s a timeline packed full of deadlines and deliverables (features) that make it easy to know exactly where you stand and when the job is done. Order placed, order fulfilled.
So far, so good, right? There’s nothing wrong with checklists and accountability.
The problem is that very often, this type of setup turns the work of development into no more than order fulfillment. In these scenarios, product roadmaps are little more than lists of features to be developed. The roadmap becomes a progression of deadlines, a plan for churning out one feature after another as ordered by the customers or determined by someone higher-up in the company.
That leaves little creative work to be down at the team level, which seems like a waste of talent if you’ve managed to assemble some great team players. A big part of why teams work is that collaboration aids the creative process.
Roadmaps Wrongly Assume a Set Course to Your Destination
In addition, we all know what can happen to a list of features that’s drawn up too early in the development process: it can change… a lot! If priorities are shifting, those initial roadmaps can quickly become obsolete. What drives the team when that happens?
When your product roadmap is a list of features, it becomes a list of promises that seemingly need to be kept. Success gets measured by how well the team can stick to their roadmap.
That’s all well and good in a perfect world where it’s immediately apparent what features should be built to solve a customer’s problem. But we know that’s rarely the case. What we typically see is a product progression that goes from “good enough” to “great” through a series of feedback-driven iterations.
All people are forced to react to changes. Some react negatively, with frustration, anger or other sensations that paralyze and block. Others, on the other hand, do so with resilience. That is, instead of breaking under pressure, they respond with flexibility, and adapt positively to changes. Everyone should strive to be the latter, not the former.
“The key is to change the culture around roadmaps. They’re not a list of commitments. Features are secondary to outcomes.”
Ruben Lunda, Project Manager
With each iteration comes the possibility that certain features may get dropped from the roster or others could get added. Who knows? It’s an Agile process that unfolds organically as users try things out and report back to the team on how well the product solves their problem.
So you can see where this is heading…
A features-driven team shackled to that features-based roadmap has little recourse for determining their own path to success. They’re not given a problem to solve — they’re merely given a set of features to develop. No creativity, no flexibility.
The danger lies here: instead of solving problems for the customer, features-focused teams end up building something that may or may not solve the problems the customer brought to the table. So the team may reach its given goals by delivering each feature on time according to the roadmap but meanwhile, the customers is left wondering why success metrics haven’t budged one bit after using the product even for a short time.
It’s because a list of features isn’t always the solution to a problem. They might solve the wrong problem or no problem at all.
Products Should Solve Problems
When a team is features-driven, they run the risk of ignoring bigger issues at hand. A customer may come to the company with a list of features they want but any good manager knows that in order to truly satisfy the needs of a customer, they have to dig deeper to find the root of the problems they’re having.
In other words, the driving force of a successful team is problem-solving, not feature building.
It’s easy to think that developing a list of features according to a set of deadlines is how development teams should operate. That is, after all, how it was done for decades. Products were developed in a context that was almost completely lacking in an understanding of the end user’s needs. There was no feedback loop. There was no MVP, and there were few iterations if any. The product got developed and was launched is what was considered final form.
That may have worked back then, but today’s consumers demand a better experience and customers need better results. Today’s products need to solve real problems. Teams need to be looking at outcomes. Simply building a set of features that aren’t tied to solving a problem isn’t going to cut it in the long run. This is how teams end up building features that nobody uses, features that get in the way, features that cause problems.
Successful Teams are Outcome-Driven
OK so let’s recap. We shouldn’t be creating product roadmaps that are merely a set of features to be built out because they’re not necessarily going to solve any problems. What should we be doing, then?
1. Talk About UX Outcomes From the Beginning
Start with this: the best teams are collaborative efforts that bring in Quality Assurance right from the beginning of the process. That ensures that rather than being left as a slap-dash effort at the end of the process, UX is woven into the entire development routine.
2. Don’t Skip the Discovery Phase
And successful teams also know that the Discovery phase of the development process is key. Without that step, it’s hard to know what problems actually have to be solved.
Here at Making Sense, we suggest starting a new project taking this all-important step. We wouldn’t know the customer’s goals, the users’ pain points, or anything else that leads to the kind of deeper insight we need if we want to create a great product.
3. Set Goals According to Outcomes, Not Features
With a problem-solving approach to the development roadmap, Product Managers can set goals according to outcomes. This allows teams to bring creativity into the process because they’re looking for solutions, not simply fulfilling a checklist of technical orders.
Remember, there are usually several different ways to solve a problem. Teams are cut out of the creative process when they’re simply handed a list of features to develop. You are opening up all sorts of possibilities when you give a team a clear outcome rather than a set of orders.
4. Don’t Focus on New Features All the Time
And don’t be afraid to develop existing features rather than build new ones. If that’s how the outcome can be reached, all the better because it prevents wasted resources on features that aren’t necessary. Sometimes, less is more.
5. To Solve Problems, Ask About Problems
If you’re asking for input from your stakeholders, the way you phrase your question can make a big difference. Instead of asking what features they think might work, ask instead about why they think a particular problem is occurring. That way, you can get your team involved in coming up with solutions.
The Roadmap Wrap-Up
Roadmaps are misunderstood and perhaps overused. But that doesn’t mean you have to ditch them altogether. If they help you, there’s no reason why you shouldn’t use them. Just keep your priorities straight.
The key is to change the culture around roadmaps. They’re not a list of commitments. Features are secondary to outcomes. Keep those points in mind and you’ll eventually iterate toward an incredible product that achieves the outcome you want.