I was recently chatting with other product management folks about the difficulties of implementing product discovery practices at their organisation. Often there is so much pressure from other teams/the Board to ship “things they need” that all the good intentions to talk to users can be the first thing that gets deprioritised. This can lead some Product Managers to give up entirely on doing any kind of discovery.
I could not help notice that some think of product discovery as a linear process, one where you start your journey with user interviews, record pain points on tidy opportunity maps that link to clear product and business goals, then proceed to identifying opportunities, brainstorming solutions, generating assumption maps and finally running assumption tests before development begins.
While there is nothing wrong with a linear approach, this is probably the hardest way to introduce these practices. Yes, it would be lovely if things happened in that order, and yes, companies should at least aim to run their product development processes in such a way, but there are just too many factors at play sometimes.
Another approach could be to look at product discovery as a set of tools that you can “deploy” as needed, depending on the situation you find yourself in. Let’s take a look at an example:
Someone in the C-suite has a brilliant idea, it is genuinely something good for users and the business. Their idea is grounded on user needs, and potentially could generate a significant amount of extra revenue.
You (the person in charge of Product) get quite excited as the proposal is to also use a new technology. You want to go for it. You tell your team about the possibilities and start assessing the current roadmap to make room for it.
You also have a nagging feeling that there might be a catch somewhere. Like that time where a tiny feature took six months of sweat and tears, with too many meetings in between. You also dread the idea of shipping something that could turn out to be damaging in any way. So, what do you do?
This is the kind of situation where developing an awareness of your own assumptions can be a game changer. Rather than being a killjoy and telling everyone that something could go wrong, ride the wave of enthusiasm, but do it with awareness.
This is similar to what user researchers do when they list their own biases before interviewing participants. They are so confident and aware of their own biases that they proactively try to prove themselves wrong during their research. This approach translates really well to product development.
I am not going to cover assumption mapping in detail in this blog post, there are very good sources of information out there that I recommend you read (Teresa Torres being my go-to person, although I am in no way affiliated to her work).
What I am going to show you instead is a quick approach that you can use on your own, or with your team if you have the time.
Set a timer for a short time (one hour max), grab a piece of paper and simply ask yourself: “what am I assuming for this idea to succeed?” Imagine this feature being used and paid for by happy customers. Think about the scenario in which everything goes well. What needs to be true for this to happen?
You may want to consider different types of assumptions, some more practical (e.g. I assume that we can collect money from users) some more abstract (e.g. I assume that the feature aligns with our values as a company). If you are doing this with someone else, compare notes and then think again. Find as many assumptions as you can, but stick to the timer!
Once you have your list, place a tick on the assumptions that you know are true (e.g. I assume that we can handle the technology) and see what’s left on the list that you don’t have much information about. Are there any assumptions that you deem really key to make this happen, could they hide a risk? Try to get some data for these assumptions from analytics, or user research; perhaps do a quick poll on social media, or interview someone to find out more. Only do this with the assumptions that you think might jeopardise the project. If you can’t run any tests, perhaps even just sharing your concerns with the CEO might help you minimise risk.
Assumption mapping is a simple method, it’s quick, and it doesn’t cost anything. You can even apply it to real life scenarios, such as a relationship, an event, or even cooking breakfast – indulge me for a second:
- You are hungry
- You want pancakes
- You have eggs, milk, flour and sugar
You could just mix the ingredients and start cooking, which is a completely valid approach.
Or you could take a moment to think about what you are assuming:
- I can whisk an egg (true)
- I have all the ingredients (true)
- I can flip pancakes (false, and potentially a risk)
- I have time to make pancakes (true, if all goes well)
- I have time to cleanup if my pancake lands on the floor (false, and potentially a risk)
Now you know that the worst case scenario is one where you end up cleaning the floor, hungry, and being late for a meeting; but you accept the risk willingly and decide to put your skills to the test. You learn that you can flip pancakes after all (and that you can use a spatula when you can’t take the risk)!
This is what “discovery” means, you unfold the one reality in front of you (e.g. building a feature, or making a pancake) and learn as much as you can from it. This will inform what you do next and build your confidence.
Assumption maps are not meant to stop us from doing things, or delay features that everyone wants. They are tools that help us see what we are doing more clearly, they give us awareness. You can use this approach at any point, whether you have interviewed users or not, whether you have an opportunity map or a tight roadmap in a spreadsheet.
Are you curious to learn how to apply these methods to your own product? Book a free chat with me to get started!
_____________
About the author
Roberta Cucuzza is a product management consultant with over 20 years experience in scholarly tech. She works with startups and scaleups to help them grow their product management skills.
Her services include fractional product leadership, product discovery coaching, product strategy development, hiring support, 1:1 coaching and mentoring, particularly in B2C SaaS, scholarly tech and tech-for-good.
Her style of consulting is friendly, honest, challenging and inspired, meaning that you will end your sessions with tangible outcomes and actionable insights.
RC Product 
Leave a comment