...
A product roadmap is a plan of action for how a product or solution will evolve over time. It helps the product team to determine what they should be working on and when. It's more or less a prioritized list of features and projects.
...
It helps us make sure we work on the highest-value thing first.
It helps run the business, it's basically a plan that gives an indication of indicates when we'll be able to launch key capabilities or features.
Share it with customers and give them insights into when they can expect what
...
We have been there ourselves before, and there is are a ton of resources you can find out there that describe the problems inherent to roadmaps:
It leads to very poor business results.
Because just not all our product ideas are going to work out.
Many ideas usually need multiple iterations to get to the point where it delivers they deliver expected business value.
We don’t build software to ship features, we do it to solve problems (or JTBD)and get the jobs of our customers done.
A roadmap itself isn’t of value. The value is in the conversations you can have around it, once you use it to outline your assumptions.
It causes unnecessary pressure for everybody on the team because if you have to be honest, how often do things work out exactly as you planned? Deadlines mean pressure, pressure means shortcuts, and shortcuts result in friction that will slow you slow down in the long run.
We are still an early-stage company so context tends to change quite quickly. You can’t do that if you have a roadmap of features for the next 6-12mo12 months.
And To conclude, the most important problem we see with Roadmaps is that no matter how many disclaimers you put on it, people will interpret it as a commitment. And that’s the crux as you're now committed to building and delivering something, even when it doesn't solve the underlying problem.
...
Leadership might be ok with changing course, but what about everyone who saw the roadmap and was eagerly awaiting feature C? What about the conversations with customers where someone in the company assured them to just hold tight because C is coming? Despite our best intentions, if we say we’re going to do something, it’s going to be really hard to back out of that, both internally and externally.
...
The realities of life and uncertainty show us that 100% of the things on the roadmap are not going to happen on time the way we imagine. And meanwhileMeanwhile, the world is not going to stop and wait for us to finish the old list.
New ideas are constantly coming up. New requests and new problems constantly arise. If we hold ourselves completely to the roadmap, we’ll have to say no to new important things we actually want to do. And if we interrupt the roadmap to do those new important things, we’ll have to push back other things we promised. And that won’t feel good.
The alternative
We can’t have our own cake and eat it too. The value a Roadmap brings is still valid so the alternative still needs to account for:
...
This is what our Strategic Contextcontext and Drumbeat helps us to do and we believe this should aid our teams to figure out what are the most important problems to solve next and what are the best ways to solve particular business these problems.
Making date-based commitments
There can, of course, be cases where we will get a specific question like “Do you integrate with platform X, and before we buy, can you tell us if and when you will be integrated with it”? That’s a pretty reasonable question as that integration might be table stakes for them in order to use our product.
Whether or not we would want to fulfill such a request would be a strategic decision first. However, the timing question can be treated as High-Integrity Commitments.
...