Why Most Product Roadmaps are a Train-wreck (and how to fix this)
It is 2017. We have Agile. We have Lean Startup. We have a million (give or take) product management blog posts about how to properly do A/B testing and experimentation. We have incredible off the shelf testing software like Mixpanel, Optimizely, and (nameyourfavoritehere). Heck, we’ve killed the MVP and replaced it with the RAT (one of my fave product posts of the last year).
And yet every single investor deck, board deck, and company all hands deck has it. And it’s a train-wreck. You know what I’m talking about. The 12-month product roadmap.
I’m just telling it like it is. Whether you are a CEO, board member, investor, or employee…EVERYONE knows that the roadmaps that are published in these documents are a joke. And yet, there they are. Every time. A random list of features with monthly or quarterly delivery dates assigned to them.
They are doing such a disservice to everyone. What are they meant to be? A hard and fast promise about what the company will deliver by when? Good luck with that…that’s a disaster of expectation-setting waiting to happen. An aspirational plan of what you hope to achieve? There are better ways to motivate people about your aspirations than to create a big list of features that you don’t know anyone wants and assign arbitrary dates to them. Plus, when you inevitably (and magically) “vanish” things off the roadmap after good experimentation proves them not valuable, there’s a decent chance your credibility takes a hit even when you are actually doing the right thing.
It’s an odd, unspoken tension in our industry. And it’s really hard to solve. How do you manage a product development schedule that is appropriately short-term focused, experimentation-based, and tuned to validate assumptions via testing, with a need to show a long-term view over where you think the product and market is headed? Your team, your board, your current investors, and your prospective investors all need and want to see where you want to take the company in the future…so how do you show this to them without making a bunch of stuff up that you already know isn’t likely to be where you actually go?
Waterfall Era vs Internet Era
The 12-month roadmap has its origins in the distant, pre-internet past, and back in those dark ages it was a relatively accurate reflection of what features were going to ship when. But that was back when software was written onto discs or CDs and put into boxes on shelves at Best Buy or CompUSA. In this “waterfall” era of software development, you knew what was going to ship when because the product cycles necessitated a vast amount of lead time in order to actually get physical product through supply chains in time. Customer research learned what people wanted, product management defined how it should work and how much it should cost, engineering defined when it would be delivered, and marketing defined how it would roll out…and the groups would sort of spar with one another until a Product Requirements Document and a Roadmap was signed (yes physically signed!!) by all parties. And then, presto, product would ship out many months (or years!) later.
In today’s mobile and internet world, that’s just not the case at all. At all. We build products iteratively, and we adjust features and functionality in minutes, hours, or days based on what data and users are telling us. User research, product, and engineering work in concert with each other in daily or weekly sprint planning, and marketing works to drive a continuous stream of organic and paid users into a funnel in order to test conversions and see how users react to product changes. Data comes in instantly. It’s all so fluid.
Product Roadmap vs Learning Roadmap
So how should a head of product or a CEO represent this fluidity to their team, their board, and their investors who also inevitably want to have some degree of understanding about the long term plan?
The key is to get away from a roadmap that assigns feature delivery dates and to move to one that establishes validation dates. Rather than having a 12 Month Product Roadmap, have a 12 Month Learning Roadmap.
Some of this is semantics…it’s the difference between saying “Redesigning our signup flow by May is critical; we’re putting all hands on deck” (bad) to saying “We believe that having a truncated signup flow will increase signups and retention and we plan to run experiments in order to learn if this is true by April 15” (good).
In most cases, your Learning Roadmap will define a timeframe by when you hope to have validated if something is important or not rather than a time frame by when you plan to broadly ship a feature to production. And in most cases, your Learning milestones should be earlier than when you’d actually like to see a feature shipped (assuming that you validate that it’s actually important) in order to give you time to take the learnings from your experiments and roll them into production-readiness.
The best founders I know are actually not huge risk takers. Most of them took their largest risk the day they hit “start” on their business, and from that day forward they work tirelessly to de-risk every assumption they have by validating beliefs and running experiments every step of the way. So let’s start publishing roadmaps that reflect this iterative and learning based approach.
It’s 2017…you shouldn’t be shipping features without the unfair advantage of already having testing data that informs you that the feature is going to work…and so if that’s the case why would you ever publish a Product Roadmap of a bunch of features that you think may someday be what your team is working on but don’t really know. Don’t fall into this trap. Start building your Learning Roadmap now. The dates you should represent to your stakeholders are the dates by when you hope to validate a problem. Do this and you’ll begin to truly bake an experiment and assumptions-driven product planning DNA into your company culture from today forward.
Start Learning Now
As I visit our various Techstars programs across the world, the thing I try to impress upon the companies I meet with is to try to change your company habits into a learning-based culture by doing two things:
- Every person in the company should have a daily individual learning goal. Each person should wake up each day and have one thing that they plan to learn about their product, market, or customers that day that they can learn in 10 minutes or less without writing code. You can learn it by studying your analytics dashboard, by asking your customers something new that day, or by reviewing sales or purchase data. But make a point of learning something and sharing it back with your team or your company during standup.
- Have a weekly company-wide learning goal. This should be a goal that the entire company works in some way shape or form toward learning in a given week. It should be established at a weekly all hands or sprint planning session and reported back to the company with lessons learned (ideally in the form of data) the following week. It should be meaningful and may require some work. And if you really get in a habit of doing this well, you’ll soon increase your throughput and will have bandwidth to do more than one company-wide learning goal per week and will soon have a bigger backlog of desired learning goals than you can imagine (which, aha moment here!, becomes your Learning Roadmap!)
Remember, if you don’t have data, you only have hope. And none of us are doing what we’re doing because we hope it will work. We believe it will work and we’re doing everything we can to validate our beliefs every single day.
Thoughts? Comments? Would love to hear how you manage the tension between short term experimentation and long term planning in your company.
