The great Dwight D. Eisenhower famously said:
“In preparing for battle I have always found that plans are useless, but planning is indispensable.”
Having a public product roadmap seems to be a pretty controversial topic in software product development, and rightfully so; it’s a hard thing to do well. Many tech companies focus on the first part of Eisenhower’s quote (that plans are useless) and forget about the last four words.
It’s understandable. In a world that is changing at an unprecedented rate and with technology driving that change, what’s the point of creating a roadmap that everyone involved knows will have to be changed or discarded completely? If the only constant is change, what’s the value in creating something based on the assumption of constancy?
Plenty. The Head of Product has the responsibility to provide the larger organization with their vision and direction for the product. I think most of us can agree that transparency inside an organization is a good thing. It breeds trust, communication and fosters a firm foundation of collaboration within a software company where we all make the products we sell.
However, is it important to make that transparency available to the general public, your customers, your competition? Is a roadmap too rigid of a planning method to be successful for the product itself? Does it stifle innovation if you narrow your focus to swimlanes? Is the roadmap an actual commitment?
At Dwolla, it is our intention to support the value layer of the internet. We’ve put a little extra pressure on ourselves by creating a product roadmap that is readily available for those who ask for it. We believe in our mission and having a plan makes us confident that we are on our way.
And that’s what it boils down to. At the minimum, what a roadmap should convey well is confidence. The confidence of the direction for a company and the products they service their customers with. This is an important thing if you are trying to establish a foothold in a new market, or if you are looking into new revenue vertices that are complementary to your legacy services.
Additionally, your roadmap should reflect not just WHAT you’re building but should demonstrate HOW you go about building it. The Dwolla public roadmap is broken down into two quarters at a time to reflect our agile methodology. We show the current quarter’s planned work, work that is in progress and finished work, along with what we believe the next quarter will hold. This model has been successful for us because it allows us to convey the product’s direction, but also gives us a chance to demonstrate the discipline of iterative development and the necessity of customer feedback.
I think it’s a good way to set an expectation for the consumer of your roadmap that while you believe that the direction this quarter is X, and you think the next quarter will be Y, you don’t often know many of the variables that go into a successful outcome for your current effort. Assuming you know everything at the beginning of a cycle puts your effort at risk of focusing on that assumed outcome instead of the feedback you get as you’re building it.
If you get data that you’re going the wrong direction in your idea, you should be brave enough to pivot from that direction and accept that with that pivot, your roadmap will change.
Roadmaps are a common tool in this industry. Regardless of where you stand with the value of a roadmap, external or internal, it’s good to remember that it is just that, a planning tool. A product roadmap, like any map, is not an end of itself, it is only as good as the people navigating it. The real magic of product development happens with your team and your customers. If you focus on the success of the latter, it makes the former much easier to manage (and more fun).