Startup life: The Art of Product Roadmaps
A few startup founders have expressed to me how frustrating it is that there’s not a good template for product roadmaps. A simple Google search shows that there’s a lot of advertising and very little substance to this simple question.
So I thought I would take a stab at this.
The roadmap is one of the key deliverables for a product leader. It is important for communicate goals, priorities and urgency.
So let’s start with purpose of the roadmap:
- Clarifies what the team needs to build when.
- Clearly communicate who is working on what.
- Give a clear sense of priorities for projects and goals.
- Finally, helps the team understands what the goals are, why those are the goals and what the overall product strategy to achieving those goals are.
Non goals of the roadmap:
- A long list of features and metrics without clear priorities or motivation.
- A detailed spec with all dependencies and tasks, a roadmap should be easily digestible and does not include every implementation detail.
- Something so rigid that it leaves the team no room to adapt.
- A huge surprise for anyone involved with the product.
So here it is:
Structure of the template:
- Overview — quick clear why and how for the roadmap.
- Focus areas — represent key strategic investment for the product. Usually also represent teams. Each focus area should have a success metric and list of key features or things you want to build.
- Key dates — optional but for some products, there are hard dates like conferences or Black Friday or Back to School that are important to highlight.
- Details — keeps the roadmap simple and digestible by moving mocks/specs and other details into links.
How long should roadmaps be?
Long enough for the team to focus and make progress, short enough to adapt and be flexible. This depends on your product? For instance hardware products will naturally have longer roadmaps. For software companies particularly consumer products, I like yearly goals and quarterly roadmaps. It’s healthy to check in every 3 months or at most every 6 months to see how the world has changed and whether you’ve made the right bets. It also forces the team to think more MVP style when they build products.
How detailed should they be?
I’ve seen and even attempted roadmaps that are extremely detailed with dates, tasks lists, dependencies, etc. I’ve found that those tend to fall apart pretty quickly and they fail to empower the team working on them to adapt and be creative. So my personal preference is to have a more digestible and simple roadmap and leave the details of the day to day planning to the team leads. Some teams work well with detailed documentation and gantt charts. Others work more fluidly. The best way forward for me has been to work with great people, communicate the strategy and the why, and hold everyone accountable for the outcome regardless of role/title.
How should it be communicated?
I recommend a team or company wide presentation to kick off a major roadmap. It’s important for everyone to know this. In this type of meeting, try to inspire and nail the why and ideally include some wireframes or aspirational mocks that get the team excited. Leave room for feedback.
How do you build a roadmap?
Top down or bottoms up that’s the question right? Especially with consumer products, everyone has ideas. I like to do a combination. The leaders of the company should have a clear set of goals. They most likely will set the focus areas and investment priorities. For example, we’re doubling down on Android, this is the year. Or we’re investing in something new and risky. However, the key to this is that there’s good communication between the leaders and their team, so they’re getting ideas/feedback from the team continuously. Then as much as possible, leave room for the team to be creative. Have the team leads whether they’re PMs or engineers or designers lead the details of a focus area. How do you improve personalization? Let the team working on this day to day set the roadmap for a focus area. In startups the company is often small enough that this doesn’t matter. But it is something to think about as the company scales.
So be comfortable with change :).
I hope this was helpful. I have been doing some consulting and advising work with startups, so let me know if you want some help or have any feedback or questions on this post.