Product Discovery Is A Mindset, Not A Process
“Strong discovery is key”. “Product Managers should focus more on discovery than delivery”. “Discovery should be continuous, it isn’t just a one time thing”.
All reasonable statements, aren’t they?
However, I read and hear about many organizations doing product discovery wrong. I’m referring to those companies that:
- spend a considerable amount of time documenting how teams should run their discovery
- use the word “discovery” for pretty much everything, so that it becomes an annoying buzzword quite soon (“I need a cup of coffee. Let’s do some discovery first!)
- evangelize (continuous) product discovery, without knowing what it really means in practice
In this article you will read what product discovery means to me, some common pitfalls I’ve seen or experienced in my life, and some tips on how to enhance continuous discovery in your organization.
What product discovery is
If you search “product discovery” online, you will find several definitions. Roman Pichler says “Product discovery refers to the activities required to determine if and why a product should be developed”. Tim Herbig gives the following statement: “Product Discovery describes the iterative process of reducing uncertainty around a problem or idea to make sure that the right product gets built for the right audience”. From the ProductPlan blog: “The product discovery process has two distinct parts”.
These experts are not wrong, but I’m concerned about the terminology and the risks that some terms such as “activity” and “process” can be understood and applied in some organizations.
Marty Cagan says “product discovery is about tackling risks around value, usability, feasibility, business viability (..), and ethics”, and this is the definition I evangelize the most. You can tackle those risks in so many different ways and times, that trying to define specifics or processes around discovery, will often lead to limitations, missed opportunities, and sometimes even failures.
Product discovery is mainly about answering the following questions:
- What is the biggest problem or pain point of our users?
- Will the users choose and figure out how to use a possible solution?
- Can we build this solution and does it work for our business?
Also, people think that product discovery is something new, or that it has been around as long as software. We actually need to go back years before software was even a thing. If we consider a few innovators of our history (Thomas Edison, Leonardo Da Vinci, Nikola Tesla, Galileo Galilei, and the list goes on), what did they have in common? Apart from being extraordinary individuals, I believe they had a discovery mindset.
They all found problems, needs or opportunities to be addressed, and created solutions that were valuable, usable and feasible for themselves, and others. They weren’t provided with long documents on how to find needs and develop solutions. They haven’t been told how to validate ideas and which one of them. It was all about their mind, reasoning and approach. The same characteristics you can find in nowadays innovative companies, such as Apple, Google and SpaceX.
What continuous product discovery is
Going back to modern times, continuous product discovery is maybe something new. A more recent concept for sure.
Product discovery is often seen as a one time thing: a prelude before building something, whether it is a new product, or a feature. Specialists tried to fix this by introducing the concept of continuous product discovery, explaining that discovery never ends, and that should be part of our daily routine as Product Managers. Teresa Torres is one of the main experts and advocate of this topic, and you can learn a lot from her website or book, Continuous Discovery Habits.
With continuous product discovery, you are in some sort of never ending loop between the problem and the solution space: you analyze data (qualitative and quantitative), find the right problem to solve, test ideas, and learn from the results. This is not a linear step-by-step guide: from the problem definition you might need to go back to analyze your user behaviour, sometimes you might start with an idea, and only later find out that it actually solves a problem (or does not). What matters the most is speed and frequency.
Why continuous discovery is so hard
In theory, continuous product discovery should be easier than initial product discovery. You probably have some users and, hopefully, collecting qualitative and quantitative insights. However, many companies still struggle with it.
In my (short) experience I’ve seen these recurring mistakes and wrong beliefs.
🕵️ Product Discovery = User Research
Research, and in particular, generative research, is gold for product discovery, but there is a lot more. You need to analyze behavioural data, collect market insights, frame and prioritize opportunities, generate hypotheses, run experiments and validate ideas.
If you’re a Product Manager, or you work in a product team, the absence of a UX Researcher cannot be a blocker. They bring value, empathy and knowledge, but they shouldn’t become “excuses” for not doing discovery.
If you “don’t have enough time”, it means you’re focusing on things you consider more valuable (are they?). If you need to find more time, start rejecting meetings without a clear agenda and goal, promote async communication and documentation, learn and test different techniques, tools and frameworks, and adapt daily routines to enhance product discovery.
🎯 No clear outcomes in mind
I’ve seen teams testing ideas without having defined the main assumption and the metric(s) they were trying to improve. “Let’s test this, and then see how it goes” is something that any product person I met said at least once (I must admit, I’m guilty of this myself). I try to avoid this by making sure that any idea has clear answers for the following questions:
- Which user/customer problem, need or desire are we trying to address?
- How do we measure success?
In my opinion, it is ok to consider more than one metric that you expect to improve, however it’s better to define which one is the success metric, and consider the others as secondary and/or monitoring metrics.
⌛ Product discovery takes too much time
This happens when you approach product discovery as a process. While defining a goal is critical, you can’t figure out all the steps in advance, and you don’t need months to find problems and possible solutions. In just a couple of hours you can:
- read your customer service tickets and find some pain points relevant to your domain
- identify a few possible solutions that might solve the biggest pain point
- interview people outside your office (or home) to understand if any of those solutions might work
You’ll be surprised to see how many “great” ideas won’t pass this third step.
👑 Someone else defines the “what” of your team’s discovery
If you want to demotivate a product team, this is how you do it. Let’s imagine ourselves working at Facebook, and Mark Zuckerberg comes to us saying “Stories are going to be the next big thing at Facebook. Try to validate this fast and get some learnings”.
While similar situations happen in any kind of organizations, and the Mark Zuckerberg of your company might be right, this is when the HiPPO is crushing any diversity of thought, strategy and vision. This person might find people with the same belief (win-win situation), or, more frequently, people with different beliefs (and maybe also evidence-driven). This brings lack of motivation, high pressure, anxiety in finding some value at any cost, and wrong decisions in the short, medium and long term.
There isn’t an easy solution for this — you need to find ways to keep those managers outside the product discovery rooms. Your best friends here are qualitative and quantitative insights and great communication skills.
🥰 Jumping too quick into solutions, and fall in love with them
Here I might sound a bit crazy, but I’m happier when an experiment I designed fails, than when it succeeds. It is like a cold shower, that brings me back to reality and reminds me that users are different individuals, with different needs and ways to solve a problem they’re facing.
However, it is really easy to fall in love with our own ideas, and look for any kind of ways to make them work. This often happens when teams don’t spend good quality time looking for the right problems to solve, and have a “one-fits-all solution” approach. Instead of thinking about the success, or failure, of an experiment, try to focus on what you learned in both scenarios:
- the experiment was successful — why? What do I need to learn next?
- the experiment failed — why? How did the user engaged with the solution? Did we target the wrong ones?
💰 Too much focus into the commercial/business value, instead of user value
This occurs when product teams prioritize opportunities (and discovery) based on the potential revenue they will bring to the company. Discovery turns into “let’s ask our customers what they want”, or “the sales department suggests X, Y, and Z, to sell more”.
Ask your customers to describe the problems they’re facing, solve them, and you will see revenues coming in. Don’t ask for solutions.
What you can do to enhance continuous discovery
It all depends on the type of company and the knowledge the product team has with this topic. Generally speaking, if you truly believe in product discovery as a lever of growth, and as the main way to succeed among competitors, this is probably what you need to start doing, or improve:
- define a dedicated and conspicuous budget for product discovery, and for each team (ie: people, tools, coupons for user interviews and user tests, etc)
- free access to data, which has to be relevant and reliable, and, if needed, external support to understand what numbers are saying
- allow PMs, and teams in general, to get in touch with users and customers on a daily base. If Product Managers have everything they need to analyze users feedback and reach out to them, you’ve already done a good job
- create a repository to collect all the learning and share the insights in dedicated bi-weekly or monthly meetings
- celebrate PMs on what they discovered, not only on what they delivered
- educate and coach people on what product discovery really is, and help them to see things from a different perspective
- last but not least, hire explorers
Final Takeaway
Product discovery is messy, never ending and the main source of learnings. Continuous product discovery doesn’t need processes, tools and documentation. It needs explorers, people with a purpose and curious about how things work. It needs leaders who aim to make the world a better place and are willing to improve people’s lives.
Tools and processes can help you to get started, but they won’t be enough. This might sound a little like unicorns and rainbows, but the reality is that you need to create, and develop, a discovery mindset.
Hope you enjoyed and found this article useful, but please don’t hesitate to give me any feedback or ask questions. It is a learning experience for me as well.
Italian version available here: Product Discovery come Mindset e non come processo.
