More on this book
Community
Kindle Notes & Highlights
Read between
March 29 - April 12, 2022
Slack’s Theme-based Roadmap
GOV.uk’s Gantt Chart with Benefits
If themes represent the customer’s most important needs or problems to be solved, then features (or solutions) are what you plan to build or implement in order to help users manage them.
We don’t want solutions to replace themes on the roadmap, and we don’t list features and themes side by side. Instead, we recommend adding features as subthemes so it is clear what problem they are intended to solve.
When considering whether to add features to your roadmap, ask yourself these questions: Do we have enough understanding of the need and possible solutions to feel confident in a particular solution? Do we have any validated solutions from previous release plans that did not get completed and need to be carried over? Do we have any validated infrastructure needs? Do we have any mandates from decision-making stakeholders that must be addressed? What is the likelihood that this solution will be changed, postponed, or dropped form the schedule (i.e., what is your confidence)?
On the roadmap she’d tagged each item as either “think it,” “ship it,” or “tweak it.”
Ask yourself these questions when deciding whether to include stage of development information in your roadmap: Do your themes or features go through distinct stages of development? If so, do those stages take longer than the timeframes in your roadmap? Is this level of detail helpful in managing expectations with your stakeholders? (Consider whether confidence, described next, may be sufficient.)
Figure 6-4. Predictive Index uses a decreasing gradient bar to indicate that confidence drops as timeframes grow more distant
Ask yourself these questions when deciding whether to include confidence information in your roadmap: Does your roadmap include specific timeframes—e.g., months, quarters, or years? Does your roadmap show themes or features far enough into the future that you find yourself reluctant to commit to those items? How regularly does your development team hit dates projected months in advance? Do your stakeholders tend to assume that if it’s written down, it is a promise? Have you already included stage-of-development information that might provide enough insight into confidence?
Ask yourself these questions when deciding whether to include target customers in your roadmap: Do you have distinct customer types with different needs? Is it important to achieve balance in addressing the needs of each? Conversely, are there one or two customer types that are more important? Will clarifying the customer type be helpful in guiding stakeholder conversations?
Ask yourself these questions when deciding whether to include product areas in your roadmap: Does your product have distinct areas or components that are easy to communicate? Do you have separate business objectives for individual product areas? Is it important to show that work is being done to improve all areas (or specific areas that need attention most)? Will clearly marking product areas be helpful in guiding stakeholder conversations?
Always assume you may have to stop work at any time.
Opportunity cost is when you never get the chance to do something important because you chose to work on something else instead.
Every feature you build has a carrying cost. For each new feature, you may have to: Retest (and fix if necessary) the feature with each new release and in each supported environment Document the feature Produce training material for the feature Handle support requests from customers (and train the support team to handle them) Figure out how to incorporate the feature into your pricing Figure out how to demo and sell the feature (and train the sales team) Figure out how to position and market the feature (and train the marketing and channels teams)
As you add features, you add the burden of testing not just each feature, but each feature in combination with every other feature. In software, this is commonly called regression testing, and unfortunately the size of this test matrix grows exponentially with the number of features (or modules or compatible third parties).
Features Versus Tests Figure 7-1. The size of the test matrix grows exponentially with the number of features
Prioritizing solely on your or some other executive’s gut instinct can be a killer for team productivity and morale, and it usually results in high turnover, low productivity, and subpar results.
You probably know more about your business and your customers than industry analysts do, and it seldom pays to substitute their judgment for your own.
We truly believe that outsourcing your product strategy to your customers is a mistake in nearly all situations.
The issue with that is customers can’t often articulate what they need from your product.
A roadmap made up entirely of customer requests generally results in a product with no focus, unclear market positioning, and poor usability.
“Your job is not to prioritize and document feature requests. Your job is to deliver a product that is valuable, usable, and feasible.” Similarly, asking for input from your sales team is smart—they have insight into how buyers think and what will get their attention—but prioritizing based on what will help close the deals in the pipeline this quarter is short-term thinking. It may help make the numbers once or twice, but successful product people are focused primarily on how to serve a market rather than individual customers.
The customer support team is a terrific source of insight for product people. Many can provide you with a list of common complaints or trouble spots in your product, ranked by frequency or rep time spent. This is good data for prioritizing enhancements under the general heading of usability, and it makes a lot of sense to prioritize work here if usability is one of your key goals.
The quickest way we’ve found to reduce the value of your product is to get into a tit-for-tat feature war with your competition.
Much better than trying to match the competition feature for feature is to differentiate yourself with capabilities perfectly matched to your chosen customer’s needs and which your competitors can’t or won’t match.
Kano 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.
Desirability, Feasibility, Viability While useful and popular, the critical path and Kano model by themselves are, in our view, insufficient to effectively judge the value of solving problems or of particular solutions to those problems.
ROI Scorecard The priority score was a perfect way to determine which of three potential car features to implement, but what if your feature list is dozens or hundreds of items long?
A Formula for Prioritization The full formula for prioritizing investments in your product might look something like this:
MoSCoW Whatever method you use in your prioritization process, you must communicate those priorities clearly to your development team. MoSCoW is a method for categorizing your prioritized list of requirements into unambiguous buckets, making it clear what your release criteria are.
Prioritization Frameworks Table 7-4. Priorization Frameworks overviewFramework Use To Choose When Downsides Critical Path Identify the “one thing” that will drive a customer to buy Designing an MVP or making a major expansion in product scope Does not take into account effort, risk, or business goals; does not rank needs finer than “critical” or “noncritical” Kano Model Understand how customers perceive relative value Identifying possible add-ons or enhancements Does not take into account effort, risk, or business goals Desirability, Feasibility, Viability Identify opportunities that meet all
...more
“No plan survives contact with the enemy,” said Helmuth von Moltke the Elder. We would add: “or your stakeholders.”
Unless you’re a company of one, you need your team to be on board with you.
Alignment This is a concerted effort to help people understand the issues and what their respective roles are. It means asking questions and listening to feedback both from the internal product team as well as external stakeholders. People with differing opinions can still align on their intentions. Alignment is not consensus.
Consensus In theory, this means a group of people reaching a mutually agreed-upon decision.
Shuttle diplomacy involves meeting with each party individually to reach decisions that require compromise and trade-offs. This approach can help manage and coordinate stakeholders to reach agreement on what the current and future product will be.
Why Does Shuttle Diplomacy Work? At each meeting, identifying the individual’s goals, priorities, and other considerations is the key to managing by shuttle diplomacy.
Goals What are they trying to accomplish in the next X months? Reality What’s on their plate now? What’s recent? Options What do they think will help them achieve those goals? What options have you already discussed that need to be revisited? Way forward Which of the options helps them achieve the goals they described earlier in the conversation? Which options are at the top of their list and why?
Hopes and fears is a simple exercise where each individual writes their hopes for the product’s future on one color of Post-it note or index card and then writes their fears on another color (one hope/fear per Post-it or card). The objective here is to draw out everyone’s emotional aspirations and fears
A world where the [target customer] no longer suffers from the [identified problem] because of [product differentiator] they [benefit]. And pare this down to: To [benefit realized] by [product differentiator]
Every department—from sales to marketing, from support to finance, from manufacturing to operations, from engineering to business development—will benefit from a view into what’s coming, and an opportunity to contribute.
One of the chief functions of a product roadmap (and one of the key skills of a successful product person) is to get everyone excited about the future.
In product-driven organizations, the roadmap forms, or at least informs, the planning of activities all across the organization. It tells marketing what they can announce at the next industry conference. It tells sales when they’ll have something new in their bag.
“I’m going to disappoint you by giving you exactly what we thought six months ahead of time was the best solution when it’s not, or by changing course and having lied to you.”
“The reason the product team has a roadmap is partly because it’s a sales tool, a communication tool to help customers understand what’s coming so that they can plan for it. We actually could not land contracts without some level of comfort developed in the customer around that.
Announcing future plans too early can also slow down current sales as people may decide to wait for the next version or upgrade. This is more prevalent with hard goods that can’t upgraded with a simple software update, increasing the perception that the current product will soon be obsolete. This phenomenon became known as the Osborne Effect after sales of the Osborne 1 computer fell sharply in 1983.
Samuel Clemens, VP of Product Management for InsightSquared, says, “The roadmap is never ever allowed outside the building. However staff can use the roadmap to respond to a customer that, ‘yes, something is on our short-term roadmap; or: our PMs are looking for more input on that so would you mind doing a call with one of them?’”
advice. If someone asks about, for example, support for an emerging standard, tell them, “It’s a great thing. It’s fantastic. You’ve all heard it, you’ll all love it. But let’s really look at the reality of this. Right now, the ability to use this feature is a rare occurrence. The chances of you actually being able to enjoy it are maybe 5%. Do you really want to say that that’s a must have feature just yet?”
Figure 9-1. Janna Bastow’s chart showing how much detail and which initiatives you should share, by role
Bill Allen, former product manager at Bose says, “Engineering cares about your product roadmap because, oh we’re moving into Bluetooth? We’d better do some research into Bluetooth. Oh speakerphone? We know about microphones, and we know about speakers, but we don’t really know about speakerphone or how to integrate them together in a speakerphone. There’s going to be a new disc formats? Is it going to be Blu-ray or is it going to be HD DVD? How do we decide? When do we need to make that choice? Technology roadmaps and decisions are always informed by the product roadmap.”
