Product roadmap flavours

This version is for Product Managers (PMs) to plan, play out what-if scenarios, identify and manage dependencies. The roadmap is constantly evolving, and may not always be up-to-date, as it’s often used only periodically when PMs are working closely together. It could be that some conversations that were happening, some learnings the team acquired are not added to this immediately. For this reason she suggest locking this down and not showing it to anybody outside the PMs involved.

This is for sales to use when talking to customers and prospects. It is a board without dates. It shall not include everything, only the items customers care about to save them time spent on reading. This roadmap has 5 columns as follows.

Items here help identify the direction of the product, without giving timeframes. What might be coming and what will not.

These items are ideas which are aligned with the product vision. Sales is welcome to collect feedback from customers. It is inevitable that during these conversations with customers, sales will receive new ideas from them. In order to help PMs assess these ideas better sales shall ask customers

This approach ensures that the PM understands the request the same way as the customer. Customers often suggest solutions based on their limited technology knowledge, so this question helps the PM get to the heart of the request. An example for this is when a customer was asking for a desktop application, thinking that being the only way to have offline mode.

These are the items that are prioritized to be worked on. An item lands here when designers start working on it. Engineers and PM should provide regular feedback in the design process. Instead of quarters, use seasons (spring, summer, autumn, winter) when giving timeline, as they have a fuzzier definition, which allows for more grace period to deliver. Quarters, on the other hand, have a clearer concept. Most people know it starts of the first of the month and it lasts 3 months.

When software engineers start working on an item it moves to the in progress column. By this time, estimates are in place, and they are more reliable than before. Rough dates can be provided using early, mid and late month name as deadlines, but exact dates or weeks should still not be used. This way the team has 2-3 weeks of grace period.

Items that were recently shipped appear here. Purpose of this column is to give customers confidence that the product is updated regularly.

Finally, the PM should ensure that the names of the items throughout the board make sense to customers. Avoid technical terms or internal names used to refer to the features, as they usually reflect how the feature is being built. Instead, use an external name for the features that describes the benefit customers are receiving. For example, developing “24 fps video recording” (internal) vs. “higher definition video calls” (external). If you need help, approach marketing, as they are usually pretty good at this.

When it comes to a roadmap that points the way forward, it’s crucial to empower your teams with a high level of autonomy, while retaining some level of decision making and approval at the leadership level. To do this effectively, leaders should create a roadmap that includes themes and relevant KPIs. Themes provide guidance and focus for teams, and the roadmap should define how long (in quarters) teams will work on a particular theme. It’s important to limit teams to no more than 2 themes at a time to prevent them from becoming overwhelmed and to ensure that they can focus on making meaningful progress. With a clear roadmap in place, teams can stay aligned and motivated, while leaders can keep a pulse on progress and make adjustments as needed.

A roadmap to pop

The purpose of this roadmap is to help marketing drive product and feature launches and get customers to pay attention. Marketing should align product launches with the quarterly sales process and define the timeline leading up to the launch.

The first step is to define the messaging that will best resonate with customers, which should be done 3-6 months before the launch. This should be a collaborative process between marketing, leaders, and PMs. Once the messaging is defined, brainstorm which features are needed to support it. Consider features that are already built, which can be re-launched. For example, highlighting already existing advanced searched feature. Also, look at features that are in progress or in the next bucket, as they could be useful too.

Should happen around 8-10 weeks prior to launch PM should determine which features will be part of the launch, so that marketing can move forward with their channel strategy.

Should happen 4-6 weeks before launch. PM have to deliver on the features agreed to at this point, so marketing can build their collateral (UI/UX locked at this point).

Recording of the talk