The product roadmap of an outstanding startup is a daring vision that brings the entire team together, unites them in their ambition to create something customers love, and organizes priorities into easily digestible paths forward. But while all teams generally agree that a product roadmap is important, things often tend to get mixed up when it comes to execution.
Understanding what to build, when, and how to communicate that to key stakeholders is a challenging task that, if not executed properly, can lead to misunderstood priorities and lost productivity. 645 hosted an intimate roundtable with our community to discuss best practices for creating, optimizing, and sharing product roadmaps within a startup. We were joined by Kevin Mattice, Chief Product Officer for NY-based Real Estate Data Platform Cherre, to share some of his best practices and pitfalls to avoid. We decided to condense key learnings and make them available to all founders and operators out there. We hope these are helpful to other founders seeking to build a world-class product operation!
At its most basic, the product roadmap of a startup is a high-level visual summary that maps out the vision and direction of your product offering over time. A roadmap communicates the “why” and “what” behind what you’re building. A roadmap is a guiding strategic document as well as a plan for executing product strategy. In addition, according to Kevin, there are the two mission-critical functions that a roadmap serves for a tech startup:
Kevin cautioned that he has seen some get mixed up between different product team deliverables and, even worse, begin using some of them interchangeably. He shared with us the key differences between product roadmaps and other documents like product backlogs, OKRs, and release schedules:
Kevin walked the attendees through the different stages that he experienced as Cherre has evolved and grown. Kevin joined the team as the first product hire and the 12th person overall in Cherre back in 2016. In the earliest days, Cherre’s CEO L.D. Salmanson would sit with Kevin and whiteboard what he believed to be the most impactful areas of product development. As time went by, they would trade roles and Kevin would lay out the product vision to L.D. rather than the other way around, building trust between the founding team and Kevin as the product leader.
At the time, all they needed for an impactful product roadmap was a whiteboard in the corner of their WeWork office. The engineering team could see it every day, understanding what to prioritize and systematically ticking off items as they were accomplished.
Now, the product team is made up of 12 individuals with many more on the engineering team. They use JIRA to track and distribute the product roadmap, but Kevin cautions that it is much more about people & processes than the tools themselves. Tools like Jira, productplan.com, gitlab, bitflow, etc. all have their flaws, but how you translate that to others in the organization is the difference between a successful and unsuccessful product roadmap.
In Kevin’s mind, this is the difference between a well-run product roadmapping initiative and one that falls flat. Internally, you are dealing with many different stakeholders with different priorities and needs across teams. Engineering teams need to know what to build at every given moment, the Sales Team needs to know what new features are coming in the next six months, and the Customer Success team needs to know what features are being pushed to a client in 6 days. Everyone wants a different version at a different time and the solution is simplicity.
Kevin quipped that when he first released the roadmap to the entire organization no one looked at it or paid attention. He hypothesized that this was a result of a people & process failure rather than a tool failure. At Cherre, the product team now hosts two critical meetings which have done wonders for the product engagement of internal stakeholders.
Biweekly Product Office Hours: This is an two-hour long session where the product team walks through the product roadmap as it stands and allows anyone in the org to attend and ask questions. This has been a hit amongst the Sales Team with 30-40 people attending every session. They are able to understand what is on the horizon in terms of product features and what they can sell during their calls with potential clients. At the same time, half the engineering team shows up to listen to the types of questions that the sales team is asking to understand what may be coming next.
Release Level Product Review: With each new product release, Kevin and his team also host an in-depth product review to go over all features of the upcoming release and field questions from the team. Whereas the office hours were highly adopted by the sales team, the Customer Support team prefers to attend these product review sessions, which allow them to get slightly more tactical on the nuances of a release and what they could mean for existing clients.
Finally, Kevin touched briefly on the importance of conveying your product roadmap externally. Many people fear that sharing product roadmaps with key stakeholders (customers, investors, media, etc) lock you into certain products, features, and timelines that may end up changing. While this can be true, Kevin believes that the benefits outway the drawbacks. He believes that giving clients general direction helps bring them into the agile process and provides flexibility. In addition, if you align the internal team on something that is public-facing, it creates even more focus and accountability to hit desired goals and deadlines.