Product Roadmaps Relaunched: Chapter 1 summary
- A product is how you deliver value to your organization's customers. Even an experience like a Broadway play counts.
- Stakeholder refers to all the internal and external colleagues and partners who are involved with the product being developed, marketed, sold and serviced.
- The customer is the recipient of the value your product provides. If the buyer is different than the end user, the word customer refers to both of them.
A product roadmap should...
- Put the organization's plans in a strategic context
- Focus on delivering value to the customers and the organization
- Embrace learning as part of a successful product development process
- Rally the organization around a single set of priorities
- Get customers excited about the product's direction
A product roadmap should not...
- Make promises the product teams aren't confident they will deliver on
- Require a wasteful process of up-front design and estimation
- Be conflated with a project plan or release plan
A roadmap should put the organization's plans in a strategic context
Problem: Nobody understands why things are on the roadmap
Effects of the problem:
- There is no buy-in at the exec level because execs can't see how the items on your roadmap will impact the org.
- There can be no autonomy at the engineering level because people don't know how their decisions weigh into the overall strategic direction.
Solution: Tie the roadmap to a compelling vision of the future
- Why does this product exist in the first place?
- What does wild success look like for the customer?
- How does the work we do feed into the broader company vision?
A roadmap should focus on delivering value to customers and the organization
Problem: You are shipping a lot but not making progress
When items on the roadmap are not tied to metrics or customer value, the only criteria left for management to judge success is whether or not the team shipped on time.
Solution: Focus the roadmap on delivering value
Once you have the product vision down, it's tempting to make the next level down be a list of features. Instead, start with chunks of value you intend to deliver to the customer.
These chunks can be described as problems your product will solve or jobs to be done that your product will address. They can be listed without getting into the specifics of how this will be accomplished. These are Themes.
A roadmap should embrace learning
Problem: Executives and customers demand commitments
What happens when a customer says they won't sign unless you commit to a feature?
Solution: Commit to outcomes rather than output
The solution is to bring the stakeholder into your process. Ask them questions to uncover the driving force behind their requirements and commit to solving the problem for them instead of committing to building the feature they want.
A roadmap should rally the organization around a single set of priorities
Problem: Marketing and sales are not selling what you are making
Organizations that aren't tightly aligned around the vision miss market opportunities because it takes months for marketing and sales to catch up to the value the product team is putting into the world.
Solution: Align everyone around common goals and priorities
The key is to involve all groups in the decisions which will affect them. Share early and often.
A roadmap should get customers excited about the product direction
Problem: Customers aren't excited about your new features
Or even worse, don't know about them.
Solution: Use the roadmap to reality-check your direction with customer
If you've done a really great job in your customer discovery then a roadmap is merely "confirming the mutual understanding".
You have to explain to customers up front that change is inevitable.
A roadmap should not make promises a team cannot deliver on
Problem: Your stakeholders and customer expect a firm commitment on dates for your product releases
Because we now live in an agile world, dates are often missed, leaving customers and stakeholders disappointed.
Solution: Prioritization is critical to delivering on your commitments
Estimation and prioritization problems are the cause of missed commitments.
Personal note: This section confuses me. Just a few sections ago it was explained that we should not commit to dates. Now it's explained that we are missing commitments because of estimation and prioritization problems. Estimation and prioritization are intrinsically hard. This section offers no solutions.
A roadmap should not require wasteful up-front design and estimation
Problem: Time spent estimating design and development tasks takes time away from actually implementing them
Solution: Let the teams determine the solutions, and allow them to solve the problem
Do this on the release plan. Not the roadmap.
A roadmap should not be conflated with a release plan or project plan
Problem: Your team looks at the roadmap as if it were a project plan listing when features will be released.
A roadmap is a strategic artifact, whereas a release plan is a tactical artifact about execution.