More on this book
Community
Kindle Notes & Highlights
Your product roadmap is the prototype for your strategy.
Roadmaps are a powerful communication tool that benefit not just the product people and their immediate team, but the entire company and how it communicates.
Things have changed and product roadmaps haven’t caught up. They haven’t adapted to a world of lean and agile (some would even say post-agile) organizations.
Properly done, a product roadmap can steer your entire organization toward delivering on the company strategy. It is your vision for how your products will help achieve your organization’s strategic goals. A good roadmap inspires buy-in and over-delivery from your entire organization.
A good roadmap is not so much a project plan as a strategic communication tool, a statement of intent and direction.
A good roadmap is not so much a project plan as a strategic communication tool, a statement of intent and direction
It focuses on the value you propose to deliver to your customer and your organization in order to rally support and coordinate effort among stakeholders.
critical
does
This highlight has been truncated due to consecutive passage length restrictions.
Agile and lean methods have not filled the strategy gap created when roadmaps are left behind. If anything, agile teams complain they spend so much time focused on the next few weeks that they lose sight of the reasons they are doing all this work.
we recommend starting with the chunks of value you intend to deliver that will build up over time to accomplish your vision. Often this is a set of high-level customer needs, problems, or jobs to be done, which we call themes.
Ben Foster, an advisor to product-driven startups, expands on the idea that uncovering themes to deliver value is more important than simply hitting deadlines: “I prefer to keep dates as vague as possible in order to maintain flexibility. If I don’t have sufficient confidence an item on the roadmap will be delivered by a specific date then, I don’t want to commit to it. The roadmap should clarify plans, but without providing false precision that someone else might be banking on.”
In the past, roadmaps often read like a Gantt chart, with specific dates and commitments of features. However, because we now live in an agile — arguably post-agile — world, such commitments and dates are often missed, leaving customers and stakeholders disappointed.
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.
A roadmap is not a project plan.
Roadmaps come in many forms depending on the size and life cycle of the product. All, however, incorporate core concepts such as what is coming and approximately when (or at least in what order). The most effective ones provide context about why by including an explicit statement of product vision and a set of outcome-oriented themes, together with a disclaimer making it clear all of this is subject to change.
Often what a potential customer thinks is the problem is just a symptom of a much larger problem. Once the problem has been confirmed through direct interaction with your target audience, Steve’s model moves onto Customer Validation, Customer Creation, and Company Building. The Customer Validation step requires you to prove that at least some of your target audience is willing to pay for your solution. The third step, Customer Creation, is about demonstrating your early success will lead to growing demand and a more sustained sales pipeline. Finally, according to Blank, Company Building
...more
vision
company
To create a product vision we suggest starting with Geoffrey Moore’s “Value Proposition template” (also known as the “Elevator Pitch template”) from his book, Crossing the Chasm (HarperBusiness).
“When done well, the product vision is one of our most effective recruiting tools, and it serves to motivate the people on your teams to come to work every day. Strong technology people are drawn to an inspiring vision; they want to work on something meaningful.”
Often referred to as objectives and key results (OKRs) are a great way to pair your business objectives with success criteria. The premise of the OKR framework is that objectives are specific qualitative goals, and key results are quantitative measures of progress toward achieving those objectives.
One of the most important things a product pro must do before releasing a product is define how the success of that product will be measured, or its key performance indicators (KPIs). These KPIs are often the metrics you are using to measure the key results from your OKRs. They are data that give you meaningful feedback on how your product is doing.
Splitting the strategy portion of your roadmap into objectives and key results will allow you to direct your product development efforts toward measurable outcomes rather than specific outputs such as features and functions.
Identifying customer needs is the most important aspect of your roadmapping process.
Roadmaps should be about expressing those customer needs. Therefore, most items on your roadmap will derive from a job the customer needs to accomplish or a problem the customer must solve.
As we touched upon earlier, we recommend that you draw a clear distinction between the product roadmap and the release plan (see Figure 5-1). Your roadmap should be a high-level view of what needs and problems your product should solve, while also helping you confirm why. In contrast, your release plan should detail how you will solve them. The product roadmap should not be about developing solutions or defining what your product will look like. Leave that to the release plan!
If you’re looking to learn more about user journeys, we’d highly recommend James Kalbach’s book Mapping Experiences: A Complete Guide to Creating Value Through Journeys, Blueprints, and Diagrams (O’Reilly).
Some product professionals differentiate between these two types of needs by calling them functional needs (customer-focused) versus technical or nonfunctional needs (engineering-focused).
Let’s take a second to review the product roadmapping hierarchy again: I. Product vision The problem you’re solving, or the change you want to see in the world II. Objectives The high-level goals you want to accomplish in this next version of the product III. Themes and subthemes The customer needs or problems that you are addressing
User journey maps can be used to outline a user’s path through the problem space. A close inspection of those maps will help you clarify the customer’s needs. Once you’ve validated the needs, you can add them to your roadmap as key themes or subthemes to address. Those themes and subthemes can then be vetted and supported by job stories or user stories. Buttressing your themes with job stories helps you cross-check and validate their importance to the customer and the value in solving for them. Finally, make sure every theme or subtheme on your roadmap is linked to a strategic objective and
...more
During that workshop, one of Spotify’s lead product managers shared a version of her roadmap. On the roadmap she’d tagged each item as either “think it,” “ship it,” or “tweak it.”
Here we’ve described a few that we’ve found useful, including critical path analysis; Kano; desirability, feasibility, viability; and (Bruce’s favorite) the ROI scorecard. We’ll also cover a related principle called MoSCoW, which helps you categorize your priorities once you’ve set them.
The Kano model, developed by Dr. Noriaki Kano, is a way of classifying customer expectations into three broad categories: expected needs, normal needs, and exciting needs.
Fundamental to this approach is the concept of ROI, or return on investment. You can’t do everything at once, so you should do the most leveraged things first — those that have the most bang for the least buck.
Value/Effort = Priority
We created a ticket type which contained the high level requirements of the problem statement to capture the details of our objectives. We also created a new scrum board in Jira which allowed us prioritize our objectives in quarter based sprints to connect our strategy roadmap with the work for the engineering team. Each ticket was a dynamic version of a problem statement so as we continued to identify key learnings we were able to evolve our problem statement effectively around a what we were trying to measure, the measure of success, the impact of what we were doing and our expected return.
One of the chief functions of a product roadmap is to get everyone excited about the future. To accomplish that, you have to tell the story.
When a team is small and the product direction is very top-down, this phenomenon is quite common. It makes sense in theory: those who started the company and established the initial product vision lay out the roadmap for the future versions. In practice, though, those now-executive-level CEOs, CTOs, and CPOs have become more removed from the specific details and challenges of the product team, so they overestimate what can be accomplished and by when. The roadmap needs to account for this growth.
Successful companies revise their roadmaps on a regular cycle to reflect market changes and shifts in strategy or priority, while also allowing execution to proceed steadily between updates.
Many companies (especially startups) face strategic forks in the road, where they must answer questions like these: Do we grow revenue by going down market to a larger number of smaller customers, or do we differentiate further to support higher prices among our high-end customers? Do we pursue a promising but untried technology, or do we focus on unit cost reduction? Do we focus on channel partners, or sell direct?
If you’ve read this far, though, you know a roadmap can be so much more than a doomed wish list of features and dates. You’ve seen the examples of how companies like Slack, Contactually, Tesla, and Chef communicate their product vision and show clearly how they will achieve it and their business objectives by solving market problems.
We can highly recommend Design Sprint from O’Reilly, coauthored by our very own C. Todd Lombardo!
If you have a cross-functional product steering committee, you can use these regular meetings to review your progress and align on next steps. If not, perhaps establishing a regular meeting is a good idea anyway. This same team can be leveraged to review actual product results and inform roadmap planning.
