Product discovery is the work of clearing up open questions and reducing risk before a team actually builds software. It typically includes a joint workshop with everyone involved, qualitative user research through interviews and observation, and creative methods for finding solutions. Early paper prototypes produce fast feedback before a single line of code exists.
Key Takeaways
- Product discovery lowers the risk of building the wrong software by clearing up open questions and blind spots before a single line of code is written.
- User research uncovers details no stakeholder workshop will surface: gloves on a touch screen, cramped workstations or noisy surroundings that rule out certain kinds of interaction altogether.
- What users say they do and what they actually do regularly differ, because routine moves have become so automatic that people no longer mention them in an interview.
- The Crazy 8 method uses a tight time limit to force eight ideas onto one folded sheet of paper, which keeps teams from settling on a single solution too early.
- Click prototypes deliver real user feedback before any development effort is spent, which makes a two- to three-month discovery phase a way to reduce risk rather than a cost.
What Product Discovery Achieves
Product discovery finds out early whether a planned product solves the right problem for the right people. The product discovery process deals with that question before anyone starts building. Software is expensive, and nobody just dives in without knowing the goals, the budget and the target audience.
The discovery phase takes uncertainty out of the project. Whatever is unclear gets clarified as far as possible before the first line of code is written. The aim is to build as little of the wrong thing as possible.
Curie Kure, a user experience designer, describes discovery as a way to prevent failure. Instead of building on assumptions, the team checks what people actually need. That puts the focus early on where many projects only arrive too late: on the perspective of the people who will use the software.
The Product Discovery Process: No Fixed Recipe, but a Proven Pattern
Product discovery doesn’t follow a rigid method, but it does follow a pattern that has proven itself. Product coaches have distilled approaches from their experience that work most of the time.
A typical process has several steps:
- Kick-off workshop: Collect and sort everything the team already knows.
- User research: Study the real work processes of the future users.
- Problem definition: Turn the findings into a concrete problem statement.
- Ideation: Develop solution ideas as a team, sketched roughly as a UI on paper.
- Prototype and test: Put a simple click prototype in front of users to get fast feedback.
What makes this attractive is the speed. You can check whether an idea holds up before any development starts.
The Kick-Off Workshop Separates Solid Knowledge from Risky Assumptions
The first workshop collects what is known and then sorts it: what is solid knowledge, and what would be risky to rely on? That distinction is what makes the blind spots visible.
Ideally, everyone who works on the product is in the room. That means UX, developers, product owners and other stakeholders, sometimes senior management. Roles close to the users are especially valuable, people from support, feedback teams or sales, because they talk to customers. Testers belong in this group too.
The method is a map of the user’s process. Take documentation software as an example: the group walks through what the person who has to document things actually does all day. Each perspective in the room fills in a piece. The result is a user journey, a timeline of what this person concretely does.
Technical and regulatory constraints come in early. A huge factory floor without stable internet changes the solution just as much as a medical application that needs regulatory approval.
The results go into a whiteboard tool such as Miro. The workshops themselves are held in person whenever possible, and afterward everyone keeps working on the digital board together.
Why the Kick-Off Workshop Leads to User Research
As soon as people in the workshop start describing exactly what the user does, gaps open up. Everyone sees it differently, and suddenly nobody has the answers. Those open questions are what trigger user research.
One real example: for a touch interface, the question came up of when users put their gloves on and take them off. Nobody knew for sure, yet it’s an important detail if you don’t want to force people to keep switching gloves.
The same goes for a machine with physical buttons that is supposed to be digitized. What is each button for, and in what order do people press them? Many people in IT know the process roughly, but not every single move. And that level of detail is exactly what the software needs.
How User Research Works
User research learns from the people who do a job how exactly they do it, so the software can reflect it correctly. When little is known, observation and open interviews help most.
Before going out, the team writes an interview guide based on the user journey it has already mapped. The guide carries the blind spots that need clarifying out into the field and brings the answers back.
Qualitative studies are often run by specially trained people, for example with a background in psychology or ethnology. But it isn’t rocket science. It matters more that the research happens at all than that it is perfect.
“It’s better for someone to do it than for it not to happen at all.”
(Curie Kure)
Every insight is worth more than what you knew before. Perfection is not the goal. Every bit of input moves you forward, especially in digitalization projects, where the question is whether someone really still has to print something, scan it and upload it.
Research Doesn’t Happen Once, It Keeps Going
Nobody finds the whole truth at the start by interviewing every future user. You only ever capture a slice and work with it. That is why research continues at regular intervals.
This mindset fits agile work well. You learn, build further, take another look and approach the goal step by step.
Observation often beats asking. Many people know their job so well that they no longer mention the obvious moves. What people say and what they do regularly drift apart.
That is why it pays to look at the workplace itself. Is it cramped, are the distances long, is it loud? In a noisy environment, voice input becomes difficult. You only learn about conditions like these on site, and they should shape the solution, without anyone feeling watched or monitored.
Sharpen the Problem First, Then Look for Solutions
After the research, the team evaluates the findings together and enriches the user journey. From there it decides which part of the work the software should cover and states the problem as concretely as possible.
This is where many projects stumble. The urge to build something new and add features pushes aside the question of which problem is actually being solved. You can see the same thing in AI workshops where the technology is a given before anyone knows what it’s for.
An online store doesn’t solve the problem that someone can’t buy clothes. It solves smaller sub-problems, and those are what the team needs to pin down before ideation starts.
How Crazy 8 Forces Breadth over the First Idea
Ideation relies on creative methods. A well-known one that is easy to try is Crazy 8.
You fold a sheet of A4 paper into eight boxes and work under a strict timebox. In a very short time, you sketch one idea per box. The time pressure makes you get ideas onto paper quickly instead of overthinking them.
The point is breadth. You end up with eight possible approaches instead of locking onto one too early. If you get tangled up in a single idea and keep squeezing new requirements into it, you lose time without knowing whether the idea was any good in the first place.
Facilitation helps. Prompts such as “try thinking in a completely different direction” guide the participants and keep free-wheeling ideas from getting stuck. Afterward, the team decides together which approaches look promising.
Prototypes Deliver Feedback Before Any Code Exists
The idea the team has worked out becomes a prototype, and the prototype gets tested. For simple cases, a paper prototype made straight from the sketches is enough. More complex cases call for a digital click prototype.
The customer is usually part of this. You take the prototype to the users and check whether your assumptions hold or whether you got it wrong.
The advantage is the timing. Feedback arrives early, on an artifact that doesn’t contain a single line of code. That lets you correct course before the project heads off in the wrong direction. Many projects build away for two years and only show the result when the users can no longer make any use of it.
How to Win Your Boss Over to a Discovery Phase
If your boss says no, start by asking why. If it’s about time and money, the strongest argument is risk reduction.
Discovery gets feedback very early on things that haven’t been programmed yet. The design team does work with developers to get their assessment and build a shared understanding, but no code has been written. That is the lever: you correct course before effort goes to waste.
The return on investment of UX is hard to calculate, because nobody can say how expensive an avoided mistake would really have been. But a discovery phase of two to three months, kept small, with some research and a minimum of validation, pays off.
It works in a lightweight form too. Sometimes it’s enough for one person to visit the users, watch how they work and bring back what they learned. That alone can change a lot.
Frequently Asked Questions
Who should participate in a product discovery workshop?
Everyone involved in the product: UX, development, product owners, other stakeholders, and occasionally senior management. Roles closely tied to users (such as those in support, feedback teams, or sales) are particularly valuable because they have daily contact with customers. Testers are also part of this group. Together, the user process is mapped out until a user journey emerges: a timeline of what the future user will actually do.
What framework conditions should be clarified before a solution is designed?
Technical and regulatory requirements should be addressed first, as they narrow the scope of possible solutions. A large factory floor without a stable internet connection requires a different solution than an office workstation. A medical application requiring regulatory approval comes with specifications that are nearly impossible to incorporate later on. If you don’t realize this until the development phase, you’ll end up having to redo the work.
Are interviews enough to understand how people actually work?
No. There’s often a gap between what people say and what they do, because routine actions have become so second nature that they aren’t even mentioned in conversation. That’s why it’s worth taking a look at the workplace: cramped spaces, long distances, noise. In a noisy environment, audio recording becomes difficult, and you can only discover that by being there in person.
Do you need trained researchers for qualitative user research?
Qualitative studies are often conducted by people with specialized training, such as in psychology or ethnology. This isn’t mandatory. More important than perfection is that the research takes place at all, because every insight gained is worth more than the knowledge we had before. A guide based on the user journey map you’ve already created helps you focus on the specific open-ended questions.
Does user research have to be completed before development begins?
No. No one surveys all future users at the very beginning and thereby discovers the truth. You can only ever capture a snapshot and build on it. That’s why research is an ongoing process: learn, evolve, and take another look. This iterative approach aligns with agile workflows and prevents a one-time survey from becoming the foundation for all future decisions.
How do you prevent a team from committing to a single solution too early?
By using creative methods that force breadth. In Crazy 8, a sheet of A4 paper is folded into eight boxes, and under a strict time limit, a scribbled idea is generated for each box. The time pressure ensures that ideas get onto paper instead of being overthought. Facilitation with trigger questions keeps the options open. Afterward, the team decides which approaches to pursue.
What’s the point of a prototype if the software is going to be developed later anyway?
It brings feedback forward. For simple cases, a paper prototype based on sketches is sufficient; for more complex ones, a digital click-through prototype. With this artifact, you go to the users and test whether your assumptions hold up. This means you correct course before any code exists, rather than after two years of development ending up with a result that users can’t use.
How long does a discovery phase take, and is it worth the effort?
Two to three months (kept on a small scale, with some research and a minimum of validation) is a reasonable timeframe. The return on investment is hard to quantify because no one can say how much an avoided mistake would have cost. The argument, therefore, is risk minimization. It also seems straightforward: even a single visit to the user yields information that no one had before.
