This much we know: design thinking can help lead to better product development. We've seen it to be true in experience mapping and now we're seeing it in assumption mapping. To show you what we mean, we turned to Precoil CEO David Bland, who helps companies find their market footing by implementing design thinking and lean startup practices. Read on to learn more about how mapping assumptions can lead to the development of better products.
It was brunch time during a rainy winter day in San Francisco. I had wrapped up another advising session with a large corporation and could not stop thinking about the enormous mindset shift that takes place from requirements to hypotheses.
How can we stop treating all of our requirements as facts merely to be executed by burning down a backlog of work?
In a moment of frustration between sessions, I crafted what I believe was my first viral tweet in 2013.
Since then, I’ve been mercilessly testing ways to make that witty remark truly an actionable approach.
To get there, I’ve iterated on an approach that I call Assumptions Mapping. Only recently have I begun to think it cracks this problem in an actionable manner.
Assumptions Mapping is an exercise in which a cross-functional team can unpack risky assumptions about a new product or service.
Over the years I’ve run a countless number of these workshops around the world, both with Silicon Valley startups and Fortune 500 companies. In doing so I’ve learned quite a bit about the framing of Desirable, Viable and Feasible.
How mapping assumptions can inform better products:
Inspired by design thinking and lean startup, I use this Assumptions Mapping framework to pull out assumptions made by a cross-functional team working on a new product or service.
Desirability: Do They?
Desirability Assumptions focus in on the problem and the customer. How many IoT products did you see at CES this year that you would never buy? Designers and User Researchers bring unique insights into this theme.
Viability: Should We?
Viability Assumptions focus on the sustainability of the business model. Just because you can do it doesn’t mean that you should. How many products have you seen fail because they couldn’t generate enough revenue? Product Owners, Product Managers and Business Stakeholders can bring data to the conversation for this theme.
Feasibility: Can We?
Feasibility Assumptions focus on if it is actually possible to do. How many super cool Kickstarter projects have you funded only to see them never deliver? Engineering, Development and Legal bring valuable expertise to this team.
Mapping out Desirability, Viability and Feasibility together is crucial because without one, you will most likely fail.
Once we physically map the answers to these questions on a 2x2, the cross-functional team can see where they should focus their experimentation. It gives them a chance to speak to one another, in a structured conversation, to openly address concerns about their new initiative. They are often immediately pulled to the unknown and important assumptions. These assumptions, if proven false, could cause a failure in which they could not recover.
Obviously compiling physical maps works well with in-person teams but what about distributed teams?
Needless to say, facilitating an Assumption Mapping workshop with a geographically distributed team is slightly more difficult. And luckily for me, this is where MURAL came in.
Not only can I quickly invite team members to join the mural, but we can collaborate in real time while unpacking the risky assumptions about our initiative.
Even better than being in a physical room, it allows us to see the stickies move by each team member in real time, versus having the highest paid person monopolize control of the board.
Plus, the iterative nature of MURAL enables me to learn from each session and improve the exercise. For example, corporate innovation teams were having a difficult time with the wording of the questions. At the same time, a startup I mentor in Columbia was struggling with the exact same wording. This led me to simplify the template in a way that would have taken much longer if I had been doing this only with physical teams.
In addition, people kept asking for more guidance. It wasn’t enough to merely run experiments on leap-of-faith assumptions. What exactly were they supposed to do with the assumptions in the other quadrants?
This is the driver behind my latest iteration of the Assumptions Map template in MURAL.
Top Right: Evaluate
Assumptions in the top right quadrant (unknown + important) are statements you’ve made that need to be evaluated. This leads to more evaluative experimentation techniques where you are looking for a response to a specific value proposition, technology or revenue model:
- Google Ads
- Landing Pages
- Solution Interviews
- A/B Price Testing
- Comprehension Tests
Bottom Right: Generate
Assumptions in the bottom right quadrant (unknown + unimportant) are tricky in that you’ve agreed that you don’t even know enough about to map them out with confidence. This leads to more generative experimentation techniques where you are looking for possible meaningful problems to solve:
- Problem Interviews
- Proto Persona Testing
- Contextual Inquiry
Top Left: Plan
Assumptions in the top left quadrant (known + important) are often closer to facts than assumptions. This conversation is still valuable, especially since those facts are often unevenly distributed across the team. This leads to checking these against your existing plan:
- User Story Mapping
- Agile Release Planning
Bottom Left: Defer
Assumptions in the bottom left quadrant (known + unimportant) can be seen as distractions for your team. Lean is about deferring commitment and too often teams spend their time playing in the bottom left quadrant because it feels safe.
New product development is not about doing what feels safe.
Teams should agree not to spend their time in this bottom left quadrant at first because completed tasks here will only give the illusion of progress. You go home feeling good that you accomplished tasks, however if they aren’t related to your leap-of-faith assumptions, it all was essentially waste.
Wherever you are in your product development, beware of treating your requirements as facts. Assumptions Mapping gives your team the space to speak about their concerns openly, instead of keeping them inside. It has an added benefit of focusing your experiments on what matters, rather than what is easy.
LEARN MORE
{{figma-integration="/cta-components"}}
.webp)
