20 Sep 2022
Product discovery process can be simple or complex based on the type of product, industry and problem being solved.
In general, discovery has become a fairly complex process in the product development lifecycle with many different ways of conducting it. The main purpose of this complex process is for teams to continuously find value propositions in the product to build out problem solution fit followed by product market fit followed by business model fit.
Teams should ensure that the businesses they work for stay competitive and innovative and they can do this by ensuring the products they are working on stay:
If you are a product person, be it a product manager, a product designer, or a product engineer this can be quite a daunting or fun process depending on the team’s methods of carrying out discovery and the organization’s maturity in product development.
Due to the varied ways involved in the product discovery process, this guide looks at providing the key differences in traditional and modern ways of discovery.
It should serve as a baseline knowledge required to conduct & manage a discovery process across value and desirability risks.
Important note: This guide is not intended to act as a framework for carrying out discovery but rather a pattern library with a collection of methods and techniques that a team can choose to use. There are 2 parts to this guide as a series, this is part 1 to determine value and desirability. Every situation and team is unique and thus the way of no way is the best way! Please also note, this guide is not meant to be an exhaustive guide but a starting point for teams. Please add your own experiences to it and make it your own.
When a product team starts a new discovery process, it can be a challenge to figure out where to start vs what problem you are solving vs what solution to go with. The intention of this guide is to simplify the process and demystify discovery while providing key tips for managing an effective product discovery process.
What is the difference between traditional Agile product discovery and modern discovery methods, and why does it matter?
The 4 critical steps in carrying out an effective discovery process for desirability & value. How to map out what your customers really need.
Traditionally product discovery has been a “phase-based method with a set of processes” to understand the scope of the requirements to build out a product or idea or solution over a fixed set of time and cost. Typically in what most organizations call “Projects”.
The traditional way involves a business case handed to a project team - generally thrown over a fence by the HIPPO! (highest paid person opinion)
This is then followed by business and project plans.
Soon after a phase based discovery process conducted by the team where they try to identify the “Requirements” for build which then go on a “Backlog”
This process generally involves elements of design thinking methodology such as ideation and brainstorming sessions/workshops, followed by some level of feature mapping or story mapping based on feature or behavioral driven development methodology used in delivery.
Traditional discovery team profile: These teams normally consist of
Requirements discovery - product owners, business analysts, solution architects, UI/UX designers and potentially UX researchers.
Delivery - project managers, scrum masters, developers and QAs
Before we dive into this, I need to clarify there is no label such as “Agile product management”!
In the last 30 years with the rise and fall of many startups and technology first companies, the world of product development has evolved drastically. This evolution has led to the modern day product management practices that have influenced some teams and organizations resulting in pushing out “project mindsets” thus allowing for a new set of activities and ways of working.
However, we are still plagued by process people as Marty says.
These project mindsets and ways of working forced requirements into delivery to build products that had no need in the market. In fact, the famous book The Lean Startup, states that “the number one reason start-ups fail is because they bring a product to the market that no one actually wants”.
Modern day product discovery is no longer cyclic and phase based as found in “Agile projects”, instead it is continuous and sits outside a “scope of work” or “scheduled plan” or “sprint” as it helps truly determine a continuous fit for a product to a customer or market need!
These empowered product teams treat discovery as a continuous process which ties in with their delivery methodology of continuous delivery as found in DevOps. Often mistaken - DevOps is not an “Agile method or framework”.
For new products, these teams try to determine their initial product vision and product strategy using techniques such as a business model canvas or lean canvas or product vision canvases. My preference is a hybrid of the 3 where I can get the team to answer a range of questions - showcased below in section 2 which help build on a solid product strategy but also connect the dots from Strategy to Tactical.
The team then uses techniques such as “opportunity solution trees” as explained in Teressa Torres’s book - Continuous Discovery Habits to map opportunities and problems.
Once these teams prioritize which problem they want to work on, they dive into solution discovery to determine solutions using “problem solution fit” methodology. This allows them to determine the value proposition behind what they are solving and building.
While for existing products, a review of “product market fit” is also carried out continuously as this evolves to help determine the hypothesis that needs to be tested to help pivot the product to enable growth.
Modern discovery team profile These teams normally consist of
product discovery - product managers, product marketing managers, product designers, technical leads & if lucky UX researchers!
product delivery - engineering manager, engineers and product manager
An important note:
Some people in the industry mistakenly think this way of working is “Agile”.
They even call it things like “Agile Product Management”. There is no such thing, however this is what the $1000 per day Agile coaches & the Agile consultancies want people to believe. This helps them stay employed and keep earning while selling their kool aid. But it's far from it - so do not be fooled by their branding games!
Agile & scrum are cyclic in nature as they are built for projects which bring about inherent problems and behaviors in discovery.
The inherent result of applying Agile methodology only to a team is that the team becomes a feature factory. They become efficient at delivering features & products.
This is where it is important to understand that Efficiency is not the same as Effectiveness.
Effectiveness = Valuable, Viable & Desirable | Efficient = Feasibility
Melissa Perri coined the term “the build trap” in her book Escaping the build trap.
A quote from the book, “The build trap is when organizations become stuck measuring their success by outputs rather than outcomes. It's when they focus more on shipping and developing features rather than on actual value those things produce. When companies stop producing real value for users they begin to lose market share, allowing them to be disrupted.
Companies can get out of the build trap by setting themselves up to develop intentional and robust product management practices. At that point, product managers can find the opportunities to maximize business and customer value.” Here is the talk on this link by Melissa at Mind the Product.
My experience that relates to this topic
In my travels across multiple organizations and industries - B2B, B2C, D2C & B2B2C, I have found that approximately 80% of organizations still function like this using traditional ways!
This is why they struggle to become the top 20% of the world. My professional opinion is that if you want to avoid the build trap or escape it, it is important to address the causation and not the effects of them.
Causation being - Scrum and Agile!!
Modern methods of discovery must include activities such as customer interviews, opportunity solution trees mapping, business and product canvases & design sprints. These activities should be done in a continuous manner. These activities require a level of mapping & preparation to be effective.
Before going into any of the above activities, my recommendation is that the team must
map out assumptions, ideas, potential solutions and risks, using system thinking mapping techniques which then allows the team to be effective during the process and help understand the Facts, Questions, Intuition and areas they really need to discover.
Tip: Whiteboarding tools such as Miro, Figma, Mural etc. help as they have functions like sticky notes and mind maps and not to mention a community that creates templates which help carry out these activities even faster. My preferred method is to use the framework of Known Knowns, Known Unknowns, Unknown Knowns & Unknown Unknowns - This framework arguably goes back to the days of Socrates!
Known knowns Things that the team are aware of and understand. Eg:- market trends, regulations and laws, existing competition and their value proposition or features
Pro Tip: A common method of building some factual data points is to use things like google trends search console with the relevant keywords or look at analyst reports and blogs or even test out product demos of potential competitors and understand revenue points of publicly listed companies about their product’s performance. Example:
The above example shows 5 trends searched over a period of 5 years in Australia. This can be customized by various parameters.
Things that the team are aware of but don’t understand. This is the part you really want to test in customer interviews for instance. Eg:- ideas and hypotheses about the customer, potential behaviors or problems that might exist. Potentially how the competition's product is solving the customers problem. Or a complete product idea.
Pro Tip: Let your inner product evangelist out. Sketch the idea out! Sketching concepts is not only something for a product designer but for anyone involved in a discovery team - whether it be a “CEO” or product engineer. In the image, I show an example from an idea I came up with in 2021 of a superapp! I used this to evangelize an idea across a team in a startup.
Note: If you are feeling more artistic you can use Miro’s wireframes to help rationalize your sketch. For example, I have used this tool before to help map out a B2B client's new return process on their e-commerce website for their B2C customers, which I then was able to get across to my design team to help explain my concept before they took it into a discovery.
Things the team are not aware of but understand. For instance - our intuitions and prejudices. This is the part you want to explore in brainstorming sessions to iron out. Eg:- assumptions made on how you would integrate with a particular solution or product. Assumptions where the customer might like a certain type of feature or user experience flow. A classic example of what to watch out for here is the cognitive bias that product managers tend to have when they assume they are the customer! These biases can be flushed out during customer interviews.
Pro Tip: Think of the stakeholder that forced an idea down which was a really bad one - but there was no politically correct way of telling them that it was bad. This is the place you note it down and then use the customer interviews to flesh it out. This way the data from the interviews speak for itself.
Unknown unknowns Things the team are neither aware of nor understand. For instance, these are risks or dependencies that are either visible or not yet visible. Eg:- Competitors product strategy or the amount of technical debt on a platform before replatforming or the effort required to carry out certain development of features or a customer problem that is not visible.
Timestamped link to the video where Melissa Perri explains the process she uses.
In the steps below, I share a non-exhaustive list of critical steps to carry out an effective discovery process.
As part of a discovery process, a team must ask the key question of
What do we see the product as being and having achieved in the future?
This may be far-fetched and generally what is called a moonshot but it is key to help drive alignment and goals. Many startup founders generally have this type of ability to think about something others assume as unachievable, but this is what makes it unique.
An article I wrote about why vision is important can be found here, which acts as a guide on alignment, direction and product evangelism.
It is important to identify the customers but also internal and external users of the product. This allows the team to understand the level of discovery and design required when mapping out user journeys, storyboards and customer journey maps ultimately allowing a team to identify which opportunity they are targeting or problem they are solving.
Who are the target customers and users?
Which market or market segment does the product address?
When the team understands who the target group is they should map out what they assume the pains and gains are and then start their customer interviews and identify if their hypothesis about pains and gains is correct or needs to be changed. There are 2 key questions
Pains -Which problem does the product solve?
Gains -What benefit does it provide?
In part 2 of the guide, we will look at:
how to address viability further looking at costs & revenue examples along with how to address the feature strategy of your product.
Key knowledge areas to explore beyond the guides as well as key people in the industry to follow and books I highly recommend reading to enhance your knowledge and skills.
5 Nov 2021Product Management in an Agile World
20 Sep 2022Product Discovery – A Product Managers Guide on Discovery Processes in Product Development - Part 1