Product Roadmaps Relaunched: Chapter 7 Notes
January 19, 2019
Why prioritization is crucial
You cannot do everything at once so you must be sure to get the most important things done before something changes and your resources are redirected.
Shiny object syndrome
It’s tempting to try and chase many opportunities at once and in parallel but every feature has both a development and maintenance cost and reduces your ability to be agile.
Exponential test matrix growth
The more features you add, the more complex your automated testing becomes because you have to test each new feature against all the features you already added. This slows down your ability to develop and release future features which will actually move the needle.
Bad (but common) ways to prioritize
You, or someone else’s, gut
Doing this will result in high employee turnover, low productivity and subpar results. The lack of rigorous analysis means the executive team is likely to change their mind, flip-flopping from idea to idea and killing productivity as they do.
Analysts are often wrong and there is enough of them out there that you can always find one which confirms your own bias. Don’t pay attention to them.
Outsourcing your product strategy to your customers is a mistake in nearly all situations. A roadmap made up entirely of customer requests will have no focus, unclear market positioning and poor usability.
Customers will use your product in lots of ways which don’t fit perfectly with your long term goals. If you appease these customers your product will be dragged in many different directions.
Asking for input from your sales team is smart but prioritizing it based on what features will close the deals that quarter is short term thinking. Successful product managers are focussed on how to solve the needs of a market rather than individual customers. Make sure you don’t end up running a custom development shop for large customers.
The support team will provide good data to help prioritize work if usability is one of your key goals. This needs to be weighed against all of your other goals though.
Competitive me-too features
Do not get in a tit-for-tat feature war with your competitors. You will end up in a comparative race to the bottom.
It is better to differentiate yourself with capabilities which are perfectly matched to your chosen customers needs.
Luckily there are some prioritization frameworks worth trying.
The goal is to look at the user journey as they use the product and answer the question, “What is the one thing (or set of things) our solution needs to get right” in order to solve the users pain in a given moment.
Linking these key moments together into a critical path journey gives you a blueprint for creating a great product.
The Kano model is a way of classifying customer expectations into three broad categories: expected needs, normal needs, and exciting needs. By attaching value to each of these buckets we can prioritize the items in them.
The expected needs are roughly equivalent to the critical path. The customer will be dissatisfied if they are not met.
Once the expected needs are met, customers will begin to articulate normal needs. The customer will be satisfied if they are met.
The exciting needs will delight the customer when met. Make them say “wow”.
Over time, expectations rise. Needs move down the hierarchy from exciting to expected. Think about any product which is introduced to the market with fanfare and amazes customers but then over time becomes a “bog-standard” feature.
The Kano model is most useful after critical path value has been delivered. Customer perception is the key. Some customers will be delighted by a feature that others will not care about.
Desirability, Feasibility, Viability
Scoring potential solutions based on these 3 factors is a path towards prioritization.
- Desirability is the value to the customer of solving the problem.
- Feasibility indicates how easy it will be for your organization to solve the problem. Some solutions require more money, effort and time than others.
- Viability indicates how valuable the solution is for your organization, often measured in revenue or profit.
Ideas that are high in all of these categories will rise to the top of the prioritization list.
Many product people are in a situation where they have hundreds of problems they could potentially solve and many of them might appear high on the desirability, feasibility, viability scale. What then?
This method assumes that we should do the features with the highest value to effort ratio. Measured simply by dividing the value by the effort.
The value in this equation is comprised of both the value delivered to the customer and the value delivered towards the organizations goals.
The effort summarizes the difficulty developing the solution.
Be wary of adding too much complexity to your mathematical model. The need for precision is relatively low. We are just trying to prioritize various solutions against each other. A simple model is easier to use by the team and easier to explain to stakeholders.
It’s important to work closely with the engineering team when determining effort. Be sure to correctly set expectations that nobody will be held to the estimate. We are looking for rough guesses, not predictions. T-Shirt sizing can help glean estimates without getting bogged down in detail. Humans tend to be good at determining the relative size of items against each other.
Try to take account of the costs the whole company will incur. Marketing will have to develop a strategy around a new feature. Can you work this into your effort calculation?
When you’re really unsure of effort you can build a fudge factor into your estimates to indicate your confidence in them.
Putting value, effort and confidence together in a single formula would give you something like this:
((CN1 + CN2 + BO1 + BO2)/(E1+E2)) * C = P Where: - CN: Customer Need - BO: Business Opportunity - E: Effort - C: Confidence - P: Priority
There’s multiple Customer Needs and multiple Business Opportunities in the formula because the same feature might contribute to two (or more) needs or opportunities.
Feature C has a negative BO score because it negatively impacts one of our opportunities. We may still want to do it regardless because of benefits for other opportunities.
MoSCoW is a method for categorizing your prioritized list of requirements into unambiguous buckets. It’s an acronym for Must have, Should have, Could have, Won’t have.
Must haves are critical path items. Should haves are not critical but will be painful to leave out. Could haves are features that are wanted but not as important as should haves.
Won’t haves are deemed out of scope for a particular release but may be included in future releases. They are useful to prevent scope creep.
Tools versus decisions
Pros and cons of using a scoring approach for product decisions.
- Scoring lots of little features or requests could provide a false sense of confidence or progress.
- Simple scale misses finer differences.
- Keeping to a few goals misses important factors that should be considered.
- Scoring models do not include intangible factors such as generating “buzz” or level of “innovation”.
- Scoring models do not include dependencies, resource availability, or promises made to key customers or the board.
- Scoring items being considered anyway forces a discussion of the underlying problems and the value of solving them.
- Simplicity keeps teams from arguing over unimportant details.
- Forcing teams to narrow down to a few goals forces them to face the reality that they can’t do it all.
- Objective criteria supports a more rational and open discussion of trade-offs.
- Scoring models uncover where resources and promises do not align with priorities.
Dependencies, resources, and promises
Dependencies can affect prioritization. For example, work with lower priority might have to happen first because a dependency of some higher priority work is not ready.
Comparison of Frameworks
- Use to identify the one thing that will drive a customer to buy.
- Choose when designing an MVP or making a major expansion in product scope.
- Downsides: Does not take account of effort, risk or business goals. Lacks nuance.
- Use to understand how customers perceive relative value.
- Choose when identifying product additions or enhancements.
- Downsides: Does not take account of effort, risk or business goals.
Desirability, Feasibility. Viability
- Use to identify opportunities that meet all key criteria for success.
- Choose when prioritizing among a small set of solutions.
- Downsides: Categories are not clearly defined in terms of customer needs, organizational goals, effort or risk.
- Use to rank ideas according to investment criteria.
- Choose when weighing multiple factors or a long list of possible work.
- Downsides: More complex model. Outputs are only as good as the inputs.
- Use to communicate launch criteria
- Choose when feeling uncertain about what much be included in a release.
- Downsides: Does not help set priorities.
Written by David Tuite who is a product manager at Workday and used to be a software engineer. You should follow him on Twitter