Many startups would genuinely benefit from CustDev, yet very few conduct it properly. The easy explanation is resources: no money, no time to spare, so at best, founders run the interviews themselves. That's a real constraint. But it's not the whole story: the same founders who won't hand off an interview will happily hand off other kinds of specialized work, no hesitation at all. That contrast is where this piece starts.
We delegate what we know how to verify
Watch what these founders hand off freely. One founder, asked about technical architecture decisions, said flatly: "I'm not good at this." He uses a technical advisor for hiring, stack, and cost decisions, and it works. Another founder brought in an outside team to build investor-facing financial models and packaging for a raise. Also no friction.
These tasks are perceived to have a checkable output. A system either runs or it doesn't. A model either holds up under scrutiny or it doesn't. Delegation here is easy because the founder (or anyone) can verify the result against an external standard.
It's harder to delegate when the value is in interpretation
Now watch what happens when the task is customer truth-seeking instead.
A founder scaling a parenting product into a foreign market hired a local interviewer to run that market's CustDev round. The founder's verdict: the interviews came back "practically meaningless." Pressed on why, he pointed to the interviewer's lack of personal experience in the product's domain - she could run the script, but couldn't tell a real, specific pain point from a vague, socially agreeable non-answer.
A founder at a 50-plus-person company, with an actual internal research team available to him, still conducts his own early customer interviews. He's afraid delegation will hand him back "not-quite-right" insights he can't fully trust - using the team only as informal mentors, not as executors, in part because their queue runs six months out. Arguably the most resource-agnostic of the three.
A third founder paid for three structured sessions with matched marketing mentors through a mentor-marketplace platform, selected specifically for relevant industry experience. His rating: unsatisfactory. The sessions produced answers that were, in his words, obvious things he already knew - attributed to the mentors' shallow understanding of his specific product context, despite generically relevant backgrounds.
We'd pause on case one. It's a common misconception that only lived experience qualifies someone to interview a given population. However, a professional researcher doesn't need to have personally been part of something to run a rigorous interview. The discipline has methodology precisely for building that contextual fluency without lived experience.
Three different founders, three different industries, three different flavors of the same refusal.
So the problem is trust. But how come?
If this were simply founder ego, we'd expect it to show up everywhere, including the technical and financial delegation cases above. It doesn't. As we see it, trust here rests on at least three shaky legs.
First: practical experience with research is often mixed. One time burned, next time understandably in doubt. As a result, founders over-trust their own domain fluency and under-trust a stranger's, because a bad past experience makes the next one feel riskier.
Second: a perception of what qualifications good interviewing actually requires. Founders tend to treat domain awareness ("I know my users") as if it were the main qualification for good interviewing. But domain closeness and knowing how to surface a real signal while avoiding bias are different skills. Closeness helps, but it's not the same competence. We often don't separate the two until it's gone wrong.
Third: numbers still read as objective; qualitative evidence doesn't. Boy, do we trust numbers. They're commonly treated as the symbol of objective measure, though any data analyst or economist will tell you numbers can mislead just as easily as words, given the wrong inputs or a sloppy interpretation. That reputation persists anyway. The same founder who'll take a financial model at face value will scrutinize an interview summary line by line. With non-numeric data, validation and interpretation get a level more complex, unless you already have enough domain judgment yourself to spot the difference between a real signal and a good story. That's precisely the judgment founders don't trust a stranger with on day one.
Focus on what would build trust for you
None of this makes the gap unbridgeable. But generic trust-building ("we're a rigorous, experienced team") doesn't move any of the three factors above.
If you're a founder
The useful question is: what, concretely, would make me trust this person's read on an ambiguous answer about my product? A few things that tend to move that needle, based on what separated the failures above from the delegation that actually worked elsewhere in this dataset:
- Test fluency before you test output. Before committing to anything, ask what the researcher already suspects about your users, and why. Someone who's done real homework will have a specific, checkable hypothesis. Someone who hasn't will offer you a generic framework instead.
- Hand over a slice, not the whole process. Start with a narrow, well-bounded piece - a handful of interviews against one clear hypothesis - before handing over the whole discovery mandate. Treat the first round as a trial of judgment, not a leap of faith.
- Build the discussion guide together, then step back. Shaping the questions and probes jointly, before a single interview happens, is the fastest way to see how someone thinks, and it costs nothing in the field. Resist the urge to sit in on the interviews themselves - a founder's presence tends to change the dynamic in the room and can undercut the trust the researcher is building with your customer. If the material isn't too sensitive, listen to the recordings afterward instead, and flag anything that feels off.
If you're a researcher
The equivalent question is: what can I show, early, that proves I'd catch the signals that are important to this product?
- Lead with a hypothesis, not a methodology. Nobody in this research doubted that outsourced interviewers knew how to run an interview technically. They doubted whether the interviewer would recognize a real insight when it showed up. Show up with a specific, checkable read on the founder's business before the engagement even starts.
- Make your reasoning visible, not just your conclusions. When you report back, show your work. Explain why a particular answer read as signal rather than a polite deflection. That reasoning is the actual thing a founder is trying to evaluate, and it's usually the first thing missing from a polished deliverable.
- For internal teams especially: engineer proximity, don't assume it. Organizational membership doesn't create domain fluency by itself - case two above is the clearest evidence of that in this dataset. A researcher who spends time embedded with the product team, or sits in on a founder's own early conversations for a while, earns more trust than an org chart line ever will.
Different pairs will land on different specific answers to their version of the question above, and that's the point. It gets worked out between the two people involved, not solved by a framework in the abstract. Trust here builds the way it always does: incrementally, with care and attention.