Product roadmaps are common fixtures in most industries and every bit as common as business plans. Every business has its unique take on the process and many try to establish their roadmap as a virtual competitive advantage.
Unfortunately, most fall into the same category as your average business plan — a pile of hopes with subheadings.
Here, we look at seven of our favorite blog posts on product roadmaps. Each post will challenge the way you think about planning and will offer a different view when it comes to executing your product vision. Here are the key takeaways:
1. Hope is a Four-Letter Word
“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.” — Cody Simms, Executive Director at Techstars
Cody Simms, in his piece Why Most Product Roadmaps are a Train-wreck (and how to fix this), talks about how so many companies tend to fill in product roadmaps with arbitrary estimates and rough guesses.
Cody explains that, specially when it comes to board meetings, “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.”
The alternative? Focus on learning goals. Timebox experiments and feed the next sprint with more and better learning opportunities. We all like to design solutions, it feels good to have new ideas, the hard thing to do is to focus on customer problems and structure ways to learn more about them.
It requires some intellectual honesty to accept that we are all victims of inertia, that we tend to do things because they have always been done that way. The challenge is to purposely take the time to do the right thing.
2. Roadmaps Kill Creativity
“Your ability to pursue new great ideas as they arise will be seriously dampened when you’ve already committed to a tall stack of requests eagerly awaiting implementation.” — David Heinemeier Hansson, creator of Ruby on Rails
DHH wrote a piece on product roadmaps worth reading. It is called, You Don’t Need a Product Road Map, and it makes a solid case for how laying out a product roadmap can stifle your creativity as you try to balance the promises you’ve made to your customers and stakeholders with the learning you are developing as you evolve your product.
DHH explains, “When you sell the software that you actually have, there’s a limited amount of wiggle room to cajole prospects. Customers have to make real decisions about whether the current state of your software is a good fit for them. Sometimes it’s not. That’s okay. It’s better to turn customers away than to placate their instincts and lure them in with vague promises.”
It takes a lot of self-discipline to not make empty promises. The pressure from stakeholders and high paying customers is always high, but it is that self-discipline that separates good from great product teams.
3. Business Is War (Not Really, But You Can Borrow Military Hierarchy)
“Roadmaps derive from the old centralized command-and-control model. A bunch of stakeholders meet, usually quarterly, in a room to come up with the priorities and the projects for the teams for the next quarter.” — Marty Cagan
In The Alternative to Roadmaps, author Marty Cagan talks about why product roadmaps are so popular. He blames it on the need of companies to preserve business value and put deadlines in place. He advises using a product team model instead, envisioning the company as an army and the teams as individual platoons.
Marty explains, “I often encourage teams to look back over the past year and grade themselves on the success rate of their roadmap in terms of how many of the items actually met the business objectives. If you do this, and if you’re not proud of what you find, then I’m hoping you’ll consider this alternative. Ensure your product organization has a compelling product vision. Ensure that each product team has a clearly defined, prioritized set of business objectives. Make sure any commitments that must be made are high-integrity commitments”
Similar to Cody Simms points, the focus should be on building better team structures where autonomous learning happens, where the focus is about outcome rather than output.
4. Perspective Changes Everything
“Roadmaps solve for the company not the customer.” — David Cancel, CEO of Drift
In David’s post, When it Comes to Building Products, Agile and Waterfall Just Don’t Cut It Anymore, he discusses the value of shifting perspectives.
Cancel explains, “I’ve never believed in setting a public product roadmap. The problem with product roadmaps is that they often satiate company curiosity more than they solve customer problems… What solves for the customer is non-stop testing and a continuous improvement. Instead of having 2–3 releases a month, we’re shipping daily. This way, the customer could help us correct and iterate on our direction — not approval from an executive.”
We often hear that to succeed in today’s business environment we need to embrace uncertainty. However, it seems that nobody gets excited about it. Instead we spend more time moving boxes around in our Gantt tables.
Product roadmaps and all the logistics around them make us feel busy and safe. Learning how to learn surrounded by uncertainty is a better approach but far more uncomfortable that most people are prepared to handle.
“Every company in the world will tell you they are customer-driven. They’ll believe in the principle. They’ll have framed posters on the wall about it. “Solve for The Customer.” But none of that means anything unless you actually make the structural decisions to ensure it.” – David Cancel, CEO of Drift
5. Expired Before it Started
“In my experience as a product manager, roadmaps are bullshit. They are created to make the company at large feel comfortable with where the product is going.” — Daniel Schmidt, product manager for Maze
In his post, Let’s Rethink Product Roadmaps, Daniel argues that roadmaps are already expired before they begin.
“Roadmaps make the product evolution legible. But inevitably, the experience of each project completely changes the trajectory. Things you thought were important aren’t…So if we don’t do roadmaps, what do we do instead? I’m not entirely sure yet. In my current company, I just say what we’re doing next and keep a list of all the things we could be doing but aren’t. The collective imagination of a company should be captured, just not with flawed forecasts for dreams becoming real.”
It seems that many of the authors mentioned in this post have found better ways to work by letting go the need to plan and control the future. Instead, they have found speed, impact and flexibility by focusing on the learning process.
6. A Common Language
“A common language goes a long way.” — Noah Weiss, Head of Search, Learning, & Intelligence at @SlackHQ. Previously at Foursquare.
Noah Weiss took a different approach in his post #now, #next, #later: Roadmaps without the Drudgery. At Foursquare, he had his teams divide everything into three timeframes, #now (2–4 weeks), #next (1–3 months), and #later (over 3 months). The simplicity makes it easy to adopt and the common language makes it easy for teams to communicate.
Noah explains, “between 20 people and 1,000 people is the sweet spot for a lightweight approach to product roadmaps. We had tried many at Foursquare, but none had stuck — including a few attempts at OKRs. The alignment from OKRs is great, but the measurement overhead is overkill for companies changing quickly and the quarterly cycle is too inflexible”
How many organisations with over 500 employees do you know that are comfortable with not having at least a 6 month roadmap already planned?
7. Solve Problems Instead of Building Features
“When a team has a clear definition of a problem, solutions are often easy. Usually, the biggest source of trouble with defining solutions comes from unclear problem definitions.”- Jared M. Spool, Founder of UIE
In Themes: A Small Change to Product Roadmaps with Large Effects, Jared Spool discusses the use of themes to frame a project. Themes based on customer problems.
He explains, “you can’t fill a roadmap with customer problems if you don’t know anything about your customers. By moving away from the invention of features (which can be done independent of whether customers need what you’re building), the roadmap technique requires deep and thorough customer insights.”
Switching from features lists to customer problems is a challenge for most organizations that crave certainty. Teams who want to move away from the feature factory will struggle, but those who succeed will enjoyed the benefits of having a shared understanding and the speed that comes with it.
The Wrap Up
Whether you think roadmaps are useful or not, we can no longer pretend that a long list of features with timeframes attached to them is the right way to build product. The job is to understand how we can transition to a problem-focused organization where teams can immerse themselves in continuous learning and fully embrace uncertainty.
This was originally published on Medium.