When you should research organically

I went into this quarter with a plan.

Our UX researcher had been flagging the same problem for a while: doing research on our team is genuinely hard. The users we’re designing for are difficult to access — scheduling is a nightmare, clearance requirements create real barriers, and there’s a general unfamiliarity with what user research is actually for. People just don’t know how to do it, or why it’s worth the effort. Because of all these factors, we never bothered to include research in quarterly planning — it felt more like an ad-hoc thing.

So when the quarter started, I decided to try — I put together a research plan.

The plan had two real bets. The first was structural: loosen the access constraints. If clearance requirements were the wall, maybe we could find a door. I pushed on it. I made the case. And I learned pretty quickly that for a team at our maturity level, working with the kind of customers we work with, that wall is not moving anytime soon.

The second bet was pipeline-building — creating something systematic that could route customer feedback into the product process. Surveys flowing into insight repositories, insights flowing into tickets and personas.

I still believe in that infrastructure, eventually. But the honest truth is it takes a culture and willingness to sustain it. If people feel forced, rather than incentivized, to participate, it’s just noise.


What actually worked looked nothing like a plan.

We started making it known — loudly and repeatedly — that our team wanted in on any customer contact that was happening. Demos, debrief sessions, feedback calls, post-deployment check-ins. If someone was talking to a user, we wanted a seat at that table.

And naturally, people started pulling us in.

The first time, we reached out to debrief a customer demo that just finished. Soon after, teams closest to the customer started looping us in. We ended up in conversations we never would have been invited to before. Real users, talking about real problems, in their own words. We made ourselves present, made our interest known, and showed up when the door opened. That’s a different kind of research operation than what I originally planned — but it’s the one that actually worked.


Here’s why I think organic research worked.

Formal research infrastructure is built for contexts where a feedback culture already exists — where customers expect to be surveyed, where internal teams already see research as valuable, where there’s precedent for this kind of thing. In those contexts, a well-designed pipeline is incredibly powerful.

But when you’re working with users who don’t have established workflows in sensitive R&D environments, who aren’t used to being studied, who have no particular incentive to fill out a form — you can’t start with rigorous processes. You have to start with the relationships.

Our users aren’t going to complete a quarterly survey. They have specific, concrete needs, and they want to be heard in specific, concrete moments. What they respond to is someone showing up and actually listening. Not a form. Not a process. A person.

So instead of asking users to come to the research, we went to them. We embedded ourselves in the moments where customer contact was already happening naturally. We made it easy — almost, casual — for teams to include us. We treated every demo debrief as a research opportunity.

It’s messier than a pipeline. There’s little process. You can’t automate it. But it creates something a pipeline can’t: trust. And trust is what eventually makes the pipeline possible.


We still want the infrastructure, eventually. Slack integrations, insight repositories, living personas — all of it. That’s the long game.

But this quarter taught me that the precondition for any of that is a culture that believes research is worth doing. And you don’t build that culture with a form. You build it by showing up, adding value, and making it obvious — through repetition — that when your team is in the room, the product gets better.

There’s no one-process-fits-all for research. Research in a way that fits your team’s needs and meets users where they are.