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, and I teach the modelling half of it in a recorded Business Model Canvas workshop.
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.
Decide, pay, use, absorb
On the battalion project, the officer who signed off on training changes was rarely the corpsman who had to run the revised drill under field conditions. I write these four roles down separately now for every engagement, on a single page, before I design anything. On a federal SBIR award, the program manager approving a phase transition is almost never the operator who eventually carries the resulting tool into the field. When those roles collapse onto one person, the discovery work is simple. When they do not, and in mission-driven work they usually do not, a design that only satisfies the first role produces the technically compliant outcome nobody uses.
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.
Frequently asked questions
What is beneficiary discovery?
Beneficiary discovery is a version of customer discovery I use for mission-driven work, where the person deciding, the person paying, and the person who has to live with the outcome are often different people. It combines participant observation, watching a beneficiary do the actual work rather than describing it, with the interview practices most founders already know.
How is beneficiary discovery different from customer discovery?
Customer discovery generally assumes the person you interview is the person who will use what you build. Beneficiary discovery separates those roles on purpose, because in a federal agency, a university, or a nonprofit the buyer and the end user are frequently different people with different incentives.
Do interviews still matter if I'm doing beneficiary discovery?
Yes. I do not treat observation as a replacement for interviews, I treat it as what comes before them. Watching the work first gives you specific questions instead of generic ones, and the interviews that follow are the ones that actually change your design.
How do I get access to observe a program in the field?
You need a sponsor inside the organization willing to vouch for you, which is usually the binding constraint on this method rather than the method itself. On the Marine Corps project, that access came through NSIN and the Common Mission Project, who had already built trust with the battalion before the student team arrived.
How long does beneficiary discovery take?
Long enough to see a full cycle of the work you are trying to improve, including the parts that look boring, because the failure usually hides in a handoff rather than in the headline task. That can be a single shift or several weeks depending on how often the cycle repeats.
What if the buyer and the beneficiary are the same person?
Then beneficiary discovery collapses into ordinary customer discovery and you do not need the extra step. The method earns its keep specifically in mission-driven and organizational settings where those roles split, which describes most of the federal, university, and nonprofit work I do.