Discovery

Discovery is the English word for “finding out” and in the tech industry refers to a phase of exploration. A team first clarifies which problem real users actually have. Only afterward does it decide whether and what to build. The opposite of this is the implementation phase, in which coding has already begun. But the term has a second, entirely different meaning: in US courts, discovery refers to the obligation of both parties in a dispute to show each other all relevant documents. Both meanings appear regularly in tech news, which is why this entry covers both.

Why teams search first and build second

The most expensive way to develop software is to build a perfect solution for a problem nobody has. Product development studies have for years estimated that a significant share of all built features is barely used. Every such feature costs development time and then has to be maintained for years afterward. Discovery is meant to catch these misguided investments early.

The basic idea is simple: a mistake discovered in a conversation costs an hour. The same mistake discovered after a year of development costs millions. That’s why teams try to test assumptions as early and as cheaply as possible. This is also called pulling risk forward.

For AI products, discovery has become especially important. Language models can do a lot, but not everything reliably. Whether an idea is even technically viable often only becomes clear after a few attempts. A customer service chatbot may seem impressive and still make something up in one out of every twenty cases. Whether that’s acceptable depends on the use case – and that’s exactly what discovery is meant to clarify.

Interviews, prototypes, and discarded ideas

It usually starts with conversations. A team talks to people who will later use the product and asks about their everyday work. One important rule here: ask about the past, not about wishes. “How did you handle this the last time?” yields better answers than “Would you use this?”. People almost always politely say yes to the second question.

Small tests follow next. A prototype is a rough mock-up of the product, often just clickable screens with no real technology behind them. It’s shown to a handful of test subjects while observing where they get stuck. Sometimes even a landing page – a single web page advertising a product that doesn’t exist yet – is enough to measure whether anyone clicks at all.

A good discovery outcome can also be: we’re not building this. That feels like wasted time, but it’s actually the whole point. The difference from classic market research lies in the pace. Discovery runs in weeks, not months, and the developers are involved themselves rather than just reading a report.

From product planning to the courtroom

In job postings for product managers, discovery is almost always listed as a task. Major software companies like Spotify or Zalando publicly describe their way of working in this language. Anyone who reads about continuous discovery means: the team talks to users on an ongoing basis, not just once at the start of a project.

The legal meaning comes up in business news. In the major copyright lawsuits against AI companies, the parties regularly argue over which internal emails and training data must be disclosed. Because huge amounts of data are searched in the process, there’s a dedicated market for this called e-discovery. Nowadays, software mostly does the pre-sorting there, determining which documents a lawyer even needs to read.

A third usage is purely technical: service discovery means that programs in a data center independently find out which other programs are currently running. The context usually makes it easy to tell which meaning is intended. It only gets confusing when a story touches both worlds – for instance, when an AI provider has to hand over documents from its own product development as part of a lawsuit.