Whether building a new product or extending what you already have, there is a ton of risk inherent in building products. By definition, unlike mass producing widgets, there are a lot of unknowns when you build software.
Tackling these unknowns incrementally is why Agile and Lean exist in modern software development. Many product teams claim to have read and understand these concepts, I frequently get the same question: Where do we begin?
Where do we begin?
I believe that a roadmap should be comprised steps taken to validate various assumptions in your product plan with each incrementally moving you toward desired outcomes.
There is a tendency in many tasks to start with the things you know well in order to start making quick progress out of the gate. This is a major anti-pattern for most software products. Instead it is much better to tackle your riskiest assumptions first.
Why? You may find some of your assumptions are wrong and you need to pivot or kill your plans altogether. If you build with assumptions and don’t validate them, you are likely to build waste. The only question is how much waste will you build?
There are two basic steps to prepare a set of prioritized assumptions for your roadmap.
-
Identify your assumptions.
-
Categorize them for prioritization.
1. Identify your Assumptions
Of course you can just start by thinking through all the assumptions that are inherent in your idea but often putting some structure to guide this activity can help. I suggest thinking though assumptions by revisiting your planning canvas such as Business Model Canvas, Lean Canvas, or Product Vision Board as a start.
Within each area of the canvas consider what possible assumptions you are making about the current situation or future state.
You should have a solid idea of your key assumptions now but to be sure, I recommend considering it from a separate perspective. A good second perspective is to evaluate each common risk type.
I like to use Marty Cagan’s 4 Four Big Risks.
-
Value – If you build it will customers buy it?
-
Usable – Can customers/users understand how to use it?
-
Feasible – Is it possible to build with your skills and current state of tech?
-
Viable – Can your business profit or achieve other goals with the product?
For example: Feasibility risk.
-
Assumption: We assume we can develop the NLP necessary to read meaning out of user comments to 95% accuracy.
-
Assumption: We assume we can integrate with the third party data provider to interpret adverse media news on stock tickers.
-
Assumption: We assume all message processing and media alerts can happen in less than 50ms.
The two perspectives should yield some overlap but potentially uncover additional assumptions in your plans. Key is to get your entire product team on-board with a set of clear assumptions.
2. Categorize Assumptions for Prioritization
It may be possible to simply stack rank your list of assumptions. You can use a canvas like this one created by DesignaBetterBusiness.com to better visualize and do this as a team exercise.
However, this approach fails to make clear which assumptions are more or less important. I prefer the tool promoted by David Bland (@davidjbland) of Precoil that he refers to as Assumptions Mapping.
Assumption Tower
Assumption Map
This 2×2 matrix is quite straightforward. Along the x-axis we have a continuum we have assumptions that range from very certain to very unknown. Assumptions that are well-known may not be proven exactly but you have very high confidence in their correctness.
On the y-axis, we have a range of importance in getting them right. Place assumptions high on the importance scale if getting it wrong would mean a significant obstacle to product success.
Now, work through each of the assumptions with the product team placing them on the board. Once done, the team will have shared understanding of the assumptions built into the product planning.
Priority 1: More importantly, this tool now gives the team some areas to prioritize their immediate validation efforts. Specifically, focusing on those assumptions that are Unknown and Important would be the best place to start.
Priority 2: Second priority items are to assess those in the lower right quadrant considered Unimportant and Unknown. You will want to do minimally sufficient work on these assumptions to validate they are not immediately important.
Priority 3: Third priority will be those items found in the upper left quadrant rated as Important and Known. These are the items that you will want to move toward execution mode quickly after the top right corner are validated. Given their high level of importance they need to be tackled with an emphasis on quality of execution. Since they are considered well understood assumptions, it is not necessary to deliver these until after other necessary assumptions have been validated.
Priority 4: Finally, the lowest priority assumptions would be those that are fairly well-known and generally unimportant to success. You may want to re-evaluate if these assumptions and features they result in, should be delivered at all.
Conclusion
When you are next faced with the nagging question of where to begin, begin by thinking about your riskiest assumptions. Focus on tackling the most important (aka riskiest) assumptions that come with maximum uncertainty as your highest priority.
By tackling these first, you will reduce the risk of delivering wasteful products.
Additional References
-
Assumptions Mapping webinar by David Bland (@davidjbland) and Mural. David uses three types of risk (Desirable, Feasible, and Viable) instead of the four categories I use. He also goes into some example tests that you can do to validate your assumptions in each category.
-
Riskiest Assumptions Canvas by designabetterbusiness.com. They provide some downloadable tools and step-by-step instructions for running an assumption workshop. I think their model over-simplifies the ranking but it can be useful for a quicker review of assumptions and provides a nice Jenga-like mental model.
-
The Only Proven Method To Identify Your Riskiest Assumption is a medium article by Sam McAfee (@sammcafee). Sam focuses on providing a more objective mathematical way to assess your riskiest assumption. I have a fundamental belief that exact math is not needed here but relative risk assessments. That said, for those working on evolving an existing product with some historical data to make mathematical predictions from, Sam’s approach may be for you.