First up, let’s start with a definition of a product roadmap. You hear this term thrown around a lot but what actually is one?
Well, the clever folks over at ProductPlan have kindly supplied this definition of a product roadmap:
“A product roadmap is a high-level visual summary that maps out the vision and direction of your product offering over time. A product roadmap communicates the why and what behind what you’re building. It’s a guiding strategic document as well as a plan for executing the strategy.”
One of the key points here is that it is a ‘high-level visual summary’ - and the reason it needs to be high-level is that it will change over time.
This is inevitable for any startup or product incubator team. In fact, if it isn’t changing, then you’re doing something wrong! And don’t be surprised if you end up changing it every month or even every week, again, that’s perfectly normal and shows you’re responding well to your customers’ needs.
It also means you’re staying on top of the latest tech. This is especially true if you’re building a product on Blockchain where the underlying tech can be changing every week.
Getting to that overall vision
That said, you do still need a product roadmap - and the part that needs to be clear and more or less fixed is the overall vision and end goal. The why and what behind what you’re building!
Some handy questions to ask yourself here are:
- Where do you want the product to be in 1 year?
- Where do you want it to be in 5 years?
- What are the bare minimum features you can build now that will provide real value to your customers?
- What features are ‘nice to haves’ that you can leave until later?
Some of this goes back to an earlier blog post we did on How to Build an MVP. It’s useful to think here of the old 80/20 rule - what 20% of features will deliver 80% of the value to your customers?
Also don’t be afraid of sharing your roadmap and vision with customers and prospects.
It’s a great way to keep them engaged and if they know that a certain feature is coming later, then they’ll be more inclined to stick around in the early days of your MVP and Beta versions.
A bit of housekeeping!
One final word on the product roadmap, and this relates more to the technical build side of things. Make sure you link your roadmap stages to clear and organised technical documentation.
This could be a new appendix to your MVP, or the reason why a certain part of your product has been coded in a particular way.
This housekeeping early on will really pay off later as you’ll be able to refer back to earlier thinking and also make sure that future iterations are fully aligned with your overall objectives.
If you need support planning out your product roadmap or even want to bounce it off people who have ‘been there and done that’ a few times in recent years, then why not get in touch. We’d love to chat!