You already have the research, it just isn't in one place

If you were to ask most early-stage teams about customer research and you are likely to get some version of the same answer. For example, "there isn't the time", "there isn't really the budget for it", etc. All of these types of answers are fair enough and mostly true, but only if the research you have in mind is the proper version; with a recruited panel, a discussion guide and someone to carry out analysis afterwards. However, this actually misses something, which is that the teams asking these things are normally sitting on a decent pile of customer evidence already. It just doesn't look like research, because none of it was originally collected as research.

Think about what a small team actually accumulates in a few months. There are the sales calls (quite possibly recorded and then never listened to again), support emails, questions that keep coming up in onboarding, and more. Then you have things like a Slack channel where one of the team pastes a screenshot of a customer complaining, the rest of the team reacts with an emoji and it is no longer thought about a day later. None of that was gathered with any intent behind it, so it sits in whatever tool it happened to originally land in and nobody thinks of it as a contributor to a body of evidence. However, in many cases it is one, and can be a better one than a survey would give you, because people tend to be more honest when they aren't aware they're being studied.

One at a time is the problem

The reason all this material doesn't turn into understanding is not really that it's scattered, even though it is, it's that each piece gets dealt with as an individual entity and then closed. For example; a support ticket comes in, someone answers it and the ticket is done. Or a sales call goes badly, and you might mention it to a colleague afterwards, and then you move on to the next one. Every single item like these examples gets handled properly on its own terms, which feels like being on top of things, and in a way it is. However, the pattern doesn't emerge from any one of them, it only exists across them, so if you only ever look at them one at a time, the pattern is genuinely invisible, no matter how attentive you or your team are.

Take a fairly ordinary example: Say your team runs ten sales calls this month, a couple of these convert, a couple were never really interested, and the other six all lose interest somewhere in the conversation. Handled one at a time, that's just six separate disappointments and you'll probably explain each one differently in your head because there's always a plausible local reason (that one wasn't the right fit, this one had no budget, etc). If you were to put the six side by side, though, and there's a reasonable chance they cooled off at more or less the same point, at the same feature, or the same moment in the demo. That correlation may be the most valuable thing your team has learned that month, and the only way to see it is to look across all six at once. Although, almost nobody does this because nothing in the way we typically work makes that the natural thing to do.

Why nobody does it

I don't think this happens through carelessness. It's mostly structural, in the sense that the tools each of these things live in are designed for handling items, not for finding patterns across them. A CRM is built specifically to assist with moving deals along and a helpdesk is built to close a ticket. Both of these tools are good at that specific function but neither is really asking what the last thirty of these had in common. What happens here is that the aggregation has to be a deliberate act by a person, and in a small team that person is likely busy doing the sales calls and answering the tickets in the first place.

There can also be a timing problem wrapped into this. The value of looking across everything goes up the more of it you have, but the moment you most need the insight is as early as possible, i.e. when you're still deciding what to build. Then the temptation is always to leave it until later when there's more to look at and a bit more breathing room, and later is unfortunately usually after you've already made the expensive decisions.

Where I'd start

If you want a version of this that fits a small team, I'd keep it to two things:

The first is to stop letting the raw material disappear. Record the sales calls if you aren't already, and keep the losses as carefully as the wins, since the ones that didn't convert are usually the more instructive half. Same with support, where the aim isn't a tidy archive so much as making sure the actual themes survive after the ticket is closed.

The second is to give the pattern-finding an actual slot, because it will never happen behind the scenes. Make one of your team sit down with the last stretch of calls and tickets and asks what these have in common rather than what needs answering is enough to surface most of it.

Or the easiest option: Use Corha to do all of this for you!

The lesson here, I suppose, is that most early-stage teams are not short of customer evidence at all. They're short of a moment where all of it gets looked at together, and that's a much smaller and cheaper problem to solve than the one they think they have.