Ask five Product teams how they do discovery and you may hear five different jobs.
One says weekly customer interviews. One says field observation. One says prototype testing. One says support evidence and sales calls before roadmap decisions. One says they do not have time for discovery because a facility opens in six weeks.
Then somebody decides one team has a mature discovery practice and the others do not. I think that is too easy. Discovery is the work required to reduce the uncertainty that matters before the next consequential Product decision. The purpose can stay consistent while the form changes dramatically.
Discovery is one part of the larger Product workflow
I generally think about Product work through the 5 Ds:
Discover. Define. Design. Develop. Deliver.
They are not five perfectly separated phases, and I would not use them to turn Product into a waterfall diagram. They are a useful reminder that discovery is not the whole job.
We discover to reduce uncertainty. We define the problem and the decision. We design a response. We develop the capability. We deliver it into the real world and learn what happened.
This essay is focused on the first of those because the word discovery gets used so broadly that teams can sound like they agree while talking about completely different work.
Discovery advice usually contains hidden assumptions
Continuous customer contact is a good habit. Regular learning is better than treating discovery as a phase the team finishes once before delivery begins. I am not arguing against that. I am arguing against pretending the same operating method is equally available everywhere. A lot of discovery advice quietly assumes several things:
You can reach users directly. The team stays together long enough to build a cadence. The buyer and user are identifiable. You have enough traffic or activity to see patterns quickly. The team has authority to act on what it learns. The next decision is reversible enough to test in market.
Those conditions exist in some products. They absolutely do not exist in all of them.
A startup can learn in public very quickly
In a startup, the Product team may be sitting ten feet from the founder who sold the account, the engineer who shipped the feature, and the customer who emailed five minutes ago. You can change the product tonight and see what happens tomorrow. That can create a fast learning loop. It can also create false confidence because the sample is tiny, the loudest customer is unusually close, and every piece of feedback feels existential. The discovery problem is not always access.
Sometimes it is signal quality. At TripLingo, consumer users, enterprise buyers, and white-label opportunities could all tell us something useful. They did not represent the same market, the same Product motion, or the same evidence. A promising enterprise engagement could validate that a business had a real need while also revealing that our platform and delivery model were not ready to repeat the solution efficiently. That is discovery too.
Not only:
Did the customer like it?
But:
What did the engagement teach us about the system we would need to build a business around it?
Physical operations change the clock
Now move into a supply-chain environment.
The users may work in facilities you cannot visit every week. The software may support physical work. A building opening can create a real date. The cost of failure is different. The decision may be difficult to reverse once equipment, training, process, and software start locking together.
A weekly interview habit is not enough to describe the discovery job. You may need observation in the actual workflow. You may need prototypes before the operation is live. You may need to understand throughput, constraints, and the business model before asking which interface somebody prefers. You may need to learn aggressively early because changing the system after go-live is far more expensive.
The purpose is still reducing uncertainty. The operating envelope changed.
Mature internal products create a different problem
Large internal systems can offer incredible access to repeated, longitudinal behavior.
The work happens every day. You can visit stores. You can observe associates using several systems in the same environment. You can see the digital workflow collide with customers, inventory, labor, interruptions, and physical reality.
That is rich discovery territory. But the team observing the problem may not own every system needed to fix it. Now the discovery challenge includes evidence travel. Can the team turn what it sees into something another Product owner, operational partner, or leadership group can act on? Can evidence survive the handoff between domains? Can a local observation become strong enough to influence a portfolio decision?
The research method can be good while the learning loop still breaks somewhere after the insight.
Diagnose the discovery job before importing the ritual
Before telling a team how discovery should work, I want to understand a few things. Who or what can we learn from? How often can we get useful evidence? What decision is approaching? Who has authority to act on what we find?
How reversible is the decision if we are wrong? Those questions matter more to me than whether the team uses the correct discovery vocabulary. A cheap, reversible experiment can tolerate lower confidence because the product itself becomes part of the learning system. A capital-intensive operational commitment should demand more evidence before the point of no return. A platform decision may require learning from developers, downstream teams, performance data, support patterns, and architecture constraints rather than one obvious end user.
An internal tool with mandated use may require observation of work quality rather than adoption as the primary signal. Same purpose. Different discovery job.
“It depends” is not permission to be lazy
There is a dangerous version of this argument. A team says, “Our context is different,” and uses that to justify weak customer access, no instrumentation, no field time, and no serious evidence. That is not situational adaptability. That is an excuse.
Sometimes the discovery environment is bad because the organization designed it badly. Product cannot reach customers because Sales controls every conversation. Telemetry is weak because nobody invested in it. Teams cannot act because every decision escalates.
Those are constraints worth changing. Context should shape the method. It should not lower the standard. Before the next consequential commitment, reduce the uncertainty that matters enough to make a responsible decision.
Ask what you need to learn before the decision gets expensive
I care less about whether a team says it practices continuous discovery than whether it can answer a more basic question:
What do we need to learn before the next decision becomes expensive to undo?
Then design the discovery work around that.
Maybe the answer is five customer interviews. Maybe it is a day in the field. Maybe it is a prototype in a warehouse. Maybe it is behavior from a small set of early customers. Maybe it is support evidence, operational data, and an account team before an enterprise commitment.
Do not worship the ritual. Do not abandon the discipline. Figure out what discovery has to do here.