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!
On Why a Product Roadmap is Important
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:
- Maintaining Focus and Alignment: Ideally, your product roadmap should convey the strategic direction of your product.It should also tie back to the strategy for the company as a whole. Within that framework, of course, is the general order of what you’ll be building and when. This helps to ensure that everyone involved, from the engineers, to the product managers, to the executive team, are on the same page when it comes to what they should be working on, and how it maps to the overall goals of the company.
- Setting and Communicating Priorities: "Kevin joked that this can also be viewed as “Professional Product Conflict Resolution''. He pointed out that cross-functional teams can quickly become distracted and pulled in opposing directions as new customer requests and demands come through the door. Startups are particularly at risk of catching a case of “Next Shiny Object” syndrome and product roadmaps are an excellent way to convey, and potentially adjust, priorities as they come up.
Product Roadmaps vs other Key Product Team Documents
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:
- Roadmap vs Backlog: While both help move a product from idea to release, the roadmap communicates high-level strategic objectives and priorities while the backlog is a tactical list that tracks the day-to-day tasks needed to accomplish the plan laid out in the roadmap.
- Roadmap vs OKRs: While roadmaps are essential to prioritizing and achieving product level goals, OKRs are company-wide aspirational objectives not always tied to products. These can include revenue milestones to hit, customer close rates, and other north stars that the company is working towards. Kevin mentioned that people sometimes think as long as they achieve the components of a product roadmap that they will hit OKRs, but that is not the case. Hitting company wide OKRs is often a collaborative effort between multiple teams all rowing in the same direction.
- Roadmap vs Release Schedule: While product roadmaps are a longer-term view of the direction and strategy of the product, release schedules are zoomed in, detailed views of specific tasks to be deployed in an upcoming product release.
Bringing on the First Product Hire and how the Product Roadmap Scales with the Team
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.
How to Communicate your Product Roadmap to other Stakeholders
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.