Product Roadmaps Relaunched: Chapter 3 summary

Before you make the roadmap, you must collect all of the relevant information and context that you need to make good product decisions. Only then can you put things on the roadmap.

The 5 phases of a product's lifecycle

1. New Product. In this phase, your roadmap should be used to outline and drive the creation of the first version of your product.
2. Growth. Here you are getting your product to as many people as possible. This is post-product-market fit. In this phase, roadmapping helps to focus the team to address operation at scale. Product discovery is relatively smooth in this phase since both the product and market are known.
3. Expansion. Here we are expanding the core product into new areas in order to unlock new growth.
4. Harvesting. Here we have a "cash cow product" which simply needs maintenance. Google AdWords for example. The product team can make extensive use of customer feedback to drive evolution.
5. End of life. Roadmaps can be used to carefully and delicately wind-down a product when that makes sense.

Gathering input from your market

Before starting on your roadmap, you should at least be able to fill out a Lean Canvas which explains all of the intricacies of how the product will work.

Once you have a good understanding of the problem, you should try to figure out what outcomes you expect to see in the world if you solve the problem well.

The best way to find that outcome is to understand your customer. Often, the problem the customer has is just a symptom of a much larger problem.

Gathering input from your customer

If your product exists to solve a problem for someone then you have to intimately know that "person" in order to address their needs. Understanding your customer base helps you envision their needs and ultimately helps you address them.

Customer roles

There are often multiple roles involved in a transaction. Any two-sided marketplace has a buyer and a seller. It's important to deeply understand both roles.

User types

The user type refers to how a user will interact with your product. For example, there might be an end user and an administrator and they may be different people.

Users vs. Buyers

The VP of sales might purchase a subscription to Salesforce but most of the users that Salesforce encounter will be the end users below who weren't part of the purchase. In this case, the buyer and user are mostly different people.

Roles vs. Personas

A persona is a representation of a user (or buyer) that embodies the characteristics, feelings, and preferences of the user. Roles help us categorize and then personas help us take our understanding to a deeper level. There is more room for empathy in personas.

Gathering input from your stakeholders

Your stakeholders can include representatives from many of the following groups:

• Customers who provide feedback
• Executives who provide strategic context
• Sales who help you understand why prospects buy
• Marketing and PR who help your product get attention
• Customer support
• Research
• Designers
• Engineers
• Other product teams
• Operations, Purchasing, HR, Finance, Partners, Vendors etc. etc. etc

In the beginning, you should at least be able to identify your stakeholders. At different points, they will be more or less involved, depending on needs.