I wanted to spend some time discussing the concept of product roadmaps. Some development communities believe roadmaps are artifacts from prehistoric product managers that roamed the planet feeding waterfall software development life-cycles.
First a bit of perspective, if you are a small team operating in isolation, do what you need to do, with what you have, and when you need to do it. Your teams required agility will be frustrating at times requiring lots of go, go stops and stop, stop goes. Learn to embrace the chaos and make it a culture strength.
For those Product Managers with anxious investors or program managers, you will be required to provide a roadmap. Yes, we know you have an agile product backlog. The foremost reason your stakeholder ask for product roadmaps is that they want to make sure you have a vision. Your vision addresses market fit and the timing dynamics of change in an intelligent way. The second reason is that the funders want to assess your ability to resource and scale your culture, team, and channels over time.
Roadmaps should be inclusive of engineering, design and product requirements. Here is a work breakdown example I like to use when gathering inputs to a product roadmap.
Your roadmap should include hard dates or constrained resources for things like trials, product launches, marketing, legal and sales activities.