I meet a lot of teams who believe they have done customer discovery because they have done interviews. They booked thirty calls, filled a spreadsheet, pulled out the themes. Then they built the wrong thing anyway.
Effort is not what they were missing. An interview gets you what someone can articulate about their work while sitting in a quiet room away from the work, and for a lot of problems that is close to the least useful place to ask.
The Marine Corps medical training project
The clearest example I point people to came out of a project run through the UC Berkeley Blum Center, supported by NSIN and the Common Mission Project. An interdisciplinary student team partnered with a Marine Corps battalion on a specific problem: how to optimize the battalion's medical training.
The obvious approach is to interview the people who run the training and the people who receive it, then design something better. The team went and watched first.
Unless and until you really get to know your customers, you're really just guessing. Sometimes you actually have to see them in their natural environment.
I call this beneficiary discovery. The method is not new in itself, and it borrows directly from participant observation in ethnography, where the researcher accepts that self-report and observed behavior diverge. What I added was a distinction I think matters in mission settings. A customer buys. A beneficiary lives with the outcome. In mission work those are frequently different people, and the person signing off on a requirement is usually not the person whose day gets worse when that requirement is wrong.
Why the room lies to you
Three failure modes recur in interview-only discovery, and I have only ever been able to correct them by going and looking. Each is well documented outside of startup practice, which is part of why I trust them.
People describe the process and leave out the workaround. Safety researchers distinguish work-as-imagined from work-as-done, and the gap between them is where most of the useful information sits. Ask how a task gets done and you get the documented procedure. Watch it and you find the informal fix everyone actually uses, which is usually where the real problem lives. Nobody is lying to you. The workaround has become so normal it does not register as worth mentioning.
Constraints go invisible to the people inside them. Nobody will tell you about the condition that shapes everything they do, because to them it is not a variable, it is just the weather. I have only ever caught those by being in the room.
Rank changes the answer. In a hierarchical organization, and a military unit is the clearest case I know, what someone tells you about a training program depends on who else is listening and who they report to. Watching a whole unit gave that team a picture no single conversation would have.
What this looks like in practice
I do not treat beneficiary discovery as a replacement for interviews. I treat it as a sequence.
I start in the environment. Go where the work happens before you have a hypothesis worth defending. Watch a full cycle of the thing you are trying to improve, including the boring parts, because the failure usually hides in the handoffs.
Then I separate the roles. Write down who decides, who pays, who uses, and who absorbs the consequence when it goes wrong. On mission-driven problems these are four different people surprisingly often, and a solution that serves only the first one does not get adopted.
Only then do I interview, with the specifics I have earned. Having seen the work, your questions stop being generic. You are no longer asking what would help. You are asking why the third step takes twice as long as the second, and now the answers are worth something.
Last, I test against the beneficiary rather than the buyer, because the person who signs is rarely the person who decides whether the thing gets used.
Why this shows up in federal work constantly
The pattern travels well beyond a battalion. Any organization where the person procuring a capability sits structurally apart from the person using it produces the same failure, which is a technically compliant solution that quietly never gets adopted. That describes a lot of the federal innovation work I have done, most university technology commercialization, and more enterprise rollouts than I would like.
It is also why so many pilots demo well and never scale. The demo gets built for the decision-maker while the scaling depends on the beneficiary, and nobody ever went to watch that person work. I have written separately about where federal pilots break and the structural reason pilots stall.
The honest version
Field observation costs more than a call. It needs access, and access needs a sponsor inside the organization willing to vouch for you. In my experience that is the binding constraint rather than the method itself.
The comparison worth making is observation against building the wrong thing for a year. On the Marine Corps project, going to look first is what kept the team from optimizing a training program nobody was struggling with.
If you want the interview mechanics that come after the observation, start with your first 100 customer conversations and how many interviews you actually need.