let’s talk about Product Roadmaps: Part II

What makes a successful Product Roadmap? Let's lay out the basic wireframe for building your roadmap. (Further thinking and documentation can be found in my complete PDLC repository HERE)

In my previous article Product Roadmap P-I, we determined IF, we need a roadmap and the basic strategy and thinking to consider before we begin work.

For the structure, simply put: A great product roadmap wireframe should clearly outline the overall strategy and goals for a product, as well as the specific features and initiatives that will be implemented to achieve those goals. It should be easy to understand and visually appealing, with a clear hierarchy of information and a consistent design. It should also be flexible and adaptable, allowing for changes and adjustments as the product development process evolves. Additionally, It should be shareable and accessible to the stakeholders, and cross-functional teams. Remember we want to remain agile, iterative, and agnostic so we can pivot when needed without emotional attachment.

The BEST PRMs should be so easy to understand key stakeholders should be able to grab it, understand it, and feel confident about where the product is at with almost no effort. PRMs should have a robust strategy and design, be implicitly realistic, and have complete buy-in from the team and key stakeholders who remain in constant alignment via regular socialization and upkeep.

here is a simple starter image of where I might begin — Roadmaps become more complicated as data, teams, and processes are added. Starting with a simple matrix: Time or phase over team and item.

Time to kick it off — let's use easy-to-consume bullet points to get us from point A to point B.

• (We should already) Understand the problem you are trying to solve from top to bottom, and have all supporting data available - having done a solid product vision statement and initial market fit, this should be no problem.
• Create your roadmap outline (Example below)
• Create and socialize a meeting agenda (Preferably recurring)
• Invite the right team members (Starting with a core team of stakeholders [which we identified, right?] and builders, expanding only when necessary)
• Ask invitees to prepare: They should come with their own insights unique to their involvement
• Input milestones and the strategies they support if you have them ready
• Milestones could/should  be pre-determined by meeting with key stakeholders 1:1 as discussed in Milestone Mapping
• Update your roadmap constantly — I prefer to have it in a well-known spot for all to access, no questions needed

But wait..."Shouldn't I have an MVP first?" Well... maybe. The decision to build a roadmap or an MVP (Minimum Viable Product) first depends on your specific project and goals. However, in general, it is recommended to start with a roadmap before building an MVP. I prefer to have both documents started in tandem. The Roadmap for a product manager is your core facilitation tool, and should be as robust and intuitive as possible.

*Meeting with key stakeholders one-on-one prior to the roadmap meeting to identify milestones is a likely approach. Here is a simple visual approach for identifying and mapping

• Assign action items and follow up as needed
• Send out the meeting: Recording or otherwise — upcycle the roadmap to appropriate parties with simple notes
• Update your roadmap constantly — I prefer to have it in a well-known spot for all to access, no questions needed

What is the appropriate output of a Roadmap kickoff?

• Roadmap approval or, if “Strawman” everyone is tasked with what needs to be different at follow up
  * strawman roadmap would be a draft version first that the team uses as an exercise before the roadmap would be communicated broadly.

Roadmap approval by the team is paramount before moving on, it shows the team is ready to begin

• Scope
• Milestones understood
• Possible estimations of effort
• vague timelines (Precision later)
• Possible defined work and owners
• Potential blockers or risks (Better yet, a risk register is started)
• Action items per team member

Once the Product Roadmap is understood and approved, you can move on to evangelizing the roadmap, perhaps through a short presentation that involves a slide deck with the strategy, milestones, and a summary or rationale to executive sponsors; if you have achieved approval from sponsors you can then socialize it broadly to the org.

Roadmaps should be liquid and open to change, it should be a living document. New information can and should change the roadmap — always try to maintain alignment and consensus among your team.

‍