Product discovery refers to the process of eliminating ambiguities and reducing risks before actually building software. This includes a joint workshop of all participants, qualitative user research through interviews and observations as well as creative methods for finding solutions. Early paper prototypes allow for quick feedback before a single line of code is written.
Key Takeaways
- Product Discovery reduces the risk of building the wrong software by clarifying ambiguities and blind spots before a single line of code is written.
- User research uncovers details that no stakeholder workshop can provide: Gloves on touch surfaces, cramped workspaces or noisy environments that simply make certain forms of interaction impossible.
- What users say they do and what they actually do regularly differ because routine actions have become so commonplace that they are no longer even mentioned in the interview.
- The Crazy 8 creative method forces eight ideas on a folded sheet of paper by imposing an extreme time limit, thus preventing teams from committing to a single solution too early.
- Click prototypes enable real user feedback before development costs are incurred and turn a discovery phase of two to three months into a risk minimization measure instead of a cost factor.
What Product Discovery does
Product discovery clarifies at an early stage whether a planned product solves the right problem for the right people. Software is expensive, and no one just gets started without knowing the goals, budget and target group.
This phase removes uncertainties. Anything that is unclear is clarified as far as possible before the first line of code is written. The goal: as few mistakes as possible.
Curie Kure, user experience designer, describes discovery as a way of preventing failure. Instead of building on assumptions, we check what is actually needed. This puts the focus early on where it ends up too late in many projects: on the user’s perspective.
There is no fixed procedure, but there is a tried and tested process
Product Discovery does not follow a fixed scheme, but it does follow a tried and tested pattern. Product coaches have used their experience to work out procedures that usually work.
A typical process consists of several steps:
- Start workshop: All existing knowledge is collected and sorted.
- User research: The real processes of future users are examined.
- Problem definition: The concrete problem is formulated from the findings.
- Ideation: Ideas for solutions are developed in the team, roughly as a UI on paper.
- Prototype and test: A simple click prototype is put to the test to get quick feedback.
The appeal of this process lies in the speed. Even before any development, it is possible to check whether an idea will work at all.
The start-up workshop separates safe knowledge from risky assumptions
In the first workshop, what is known is collected and then sorted: What is valid knowledge, what is risky to believe in? It is precisely this distinction that makes the blind spots visible.
As far as possible, everyone involved in the product comes together for this. This includes UX, developers, product owners and other stakeholders, sometimes the management. User-oriented roles from support, feedback teams or sales are particularly valuable because they have customer contact. Testers also belong in this group.
A mapping of the user process serves as a method. Using documentation software as an example, the participants go through what the person who is supposed to document actually does. Each perspective in the room adds a part. The end result is a user journey, a timeline of what this person actually does.
Technical and regulatory framework conditions are part of this early on. A large factory hall without stable internet changes the solution just as much as a medical application requiring approval with regulatory requirements.
The result is recorded in a whiteboard tool such as Miro. Workshops are held in person wherever possible, after which the participants continue to work collaboratively on the digital result.
Why the kick-off workshop triggers user research
As soon as the workshop is about what exactly the user does, gaps appear. Everyone has a different view and suddenly there are no answers. It is precisely these unanswered questions that trigger user research.
A practical example: with a touch interface, the question arose as to when users put on and take off their gloves. Nobody knew exactly, but this is an important detail if you don’t want to force people to constantly change their gloves.
Similar to a machine with physical buttons that is to be digitized. What is each button for and in what order is it operated? Many people in IT have a rough idea of the process, but not every single action. However, it is precisely this level of detail that counts for the software.
How user research works
User research learns from the people who do a job how exactly they do it so that the software can map it correctly. If little is known, observations and open interviews are particularly helpful.
A guideline is created in advance from the user journey that has already been mapped out. It identifies the blind spots that need to be clarified and returns the appropriate answers.
Qualitative studies are often carried out by specially trained people, for example in psychology or ethnology. But this is not witchcraft. More important than perfection is that it takes place at all.
It’s better if someone does it than if it doesn’t exist at all.
- Curie Kure
Every insight gained is worth more than the knowledge before it. You don’t have to die in perfection. Every input takes you further, especially with digitalization, where the question arises as to whether anyone really needs to print, scan and upload anything.
Research is not a one-off act, but is carried out regularly
Nobody finds the truth at the beginning and surveys all future users. You only ever capture an excerpt and take it with you. That is why research is continued on a regular basis.
This attitude fits in with agile working. You learn, develop further, look again and approach the goal in stages.
Observation often beats pure questioning. For many people, their job has become so ingrained that they no longer even mention obvious steps. What people say and what they do regularly diverge.
That’s why it’s worth taking a look at the workplace. Is the space tight, are the distances long, is it noisy? Voice recording is difficult in a noisy environment. You can only get to know such conditions on site, and they should influence the solution without anyone feeling observed or controlled.
Sharpen the problem first, then find solutions
After the research, the findings are evaluated together and the user journey is enriched. From this, the area that the software should map is determined and the problem is formulated as specifically as possible.
This sharpening is the point at which many projects stumble. The urge to build something new and to add functionality supplants the question of which problem is actually to be solved. This can also be seen in AI workshops, where the technology is set before it is clear what it is for.
An online store does not solve the problem of someone not being able to buy clothes. It solves smaller sub-problems. It is precisely these that need to be worked out before the brainstorming begins.
Crazy 8 forces breadth instead of the first idea
Creative methods are used in ideation. One well-known and easy-to-try method is Crazy 8.
You fold an A4 sheet of paper into eight boxes and are timeboxed hard. You scribble one idea per box in a very short time. The time pressure means that you have to get ideas onto the page quickly instead of thinking too long.
The goal is breadth. Eight possible solutions emerge instead of settling on a single one early on. If you get mentally tangled up in an idea and force new requirements into it, you lose time without knowing whether the idea was a good one in the first place.
Moderation helps here. Trigger questions such as “why don’t you think in a completely different direction” guide the participants without the spinning around turning into getting stuck. The team then decides together which approaches are promising.
Prototypes provide feedback before code is created
The developed idea is turned into a prototype that is tested. In simple cases, the paper prototype directly from the drawn sketches is sufficient; in more complex cases, a digital click prototype is sufficient.
The customer is usually part of the process. You take the prototype to the users and validate whether your assumptions are correct or whether you are wrong.
The advantage lies in the timing. The feedback comes early, with an artifact that does not yet contain a line of code. This allows the course to be corrected before it goes in the wrong direction. Many projects take two years to build and only show the result when the user no longer knows what to do with it.
How to enforce discovery with the boss
If the boss says no, the first question worth asking is why. When it comes to time and money, the strongest argument is risk minimization.
Discovery obtains feedback on things that have not yet been programmed at a very early stage. The design team works with developers to ensure their assessment and a common understanding, but nothing is written yet. This is precisely where the leverage lies: course correction before the effort is wasted.
The return on investment of UX is difficult to calculate because no one can say how expensive an avoided error would actually have been. But a discovery phase of two to three months, kept small, with some research and a minimum of validation, is worthwhile.
This also works on a lightweight basis. Sometimes it is enough for someone to go to the user, look at their work and bring information with them. That can make a big difference.
