Recommendations the product team carries

The problem

Research gets handed over. A report on a shared drive, a deck, sometimes a readout where eleven people nod. Then the roadmap conversation happens three weeks later. You are not in it. What you found is not in it either.

Writing it better does not fix this. A report on a shared drive has never made anyone feel urgency. People argue for conclusions they helped reach. They quietly drop the ones that were handed to them.

Underneath it there is a capacity problem too. One researcher, or four, cannot sit inside every decision a product organisation makes. So teams that want to move fast start talking to customers on their own. Nobody has taught them how. What they collect cannot be trusted.

How do you get a product team to act on research, without letting them do research they are not trained to do?

What we tried

The format has two halves. Interview craft, so a team can hold a conversation without destroying the data it is trying to collect, and synthesis, so the same team can make sense of what comes back. Some clients take one half, some take both.

The examples that follow are from Fugro, because that is the run I can show you in photographs. None of it is particular to Fugro. Every room defaults the same way and gets stuck in the same three places. That is why a format works at all.

The question that gets a workshop booked. Are we actually doing customer interviews, or are we just talking to customers? Fugro asked it out loud. Most organisations building fast without a research team avoid asking it. The honest answer is usually the second one.

Interview craft, practised on me. I sat down as a participant in a practice interview run by someone on the product team. Smart, curious, genuinely trying to do a good job, and never taught how. Within five minutes I felt stupid, incompetent and mildly interrogated. Instead of asking about my experience with Teams, they told me I was using the features wrong, offered to send someone to train me, and asked why I was forcing a tool on a team that clearly struggled with it. I had to remind them, mid interview, that Teams is a company wide decision. The room lost it.

The line that did it came from a data scientist. “Well if you don’t know how to use the product, maybe you should follow the training manual.”

Then something better happened. I did not have to explain what had gone wrong. An engineer, a product manager and a developer pushed back on their own colleague. They said it was embarrassing, and that the practice interviews had gathered nothing useful. They worked out between them that setting up a good interview is genuinely difficult, that staying off your own bias is harder than it looks, and that when you built the thing you are asking about, you cannot stop yourself selling it. That last one is a sophisticated observation. Nobody in that room had ever been taught it.

By then I had stopped teaching. That is the point of running it this way. Bad questions do not just feel awkward. They make people defensive and embarrassed. A defensive participant stops giving you data. You are collecting noise at that point, and you will present it as if it were evidence. The room had just watched that happen.

Then synthesis, on the team’s own data. At Fugro that afternoon ran with a product team that had never done affinity mapping. No researchers in the room. A developer, a designer, a data scientist, a product manager and someone from innovation.

Every group defaults to type in the first ten minutes, and this one was no exception. The product manager started working through the data alone. The developers huddled together deciding what was invalid. The innovation person was already jumping to ideas. Very classic, very human. It happens in every room I have ever run this in, so the format has to survive it.

So I did not correct anyone. I asked questions. What made you put that note in the invalid pile? What does the person next to you think about that cluster? Slowly they started talking to each other. And they started listening, on the assumption that someone from a different discipline might have seen something they missed.

The design

The spine is the same everywhere. The content is always the client’s own. So it runs at an engineering firm, a bank, a veterinary software company and a university without becoming a different workshop each time. Nordhealth and ING took the synthesis half. Fugro and Ground IQ took both. I have taught the same method at HvA, the Haagse Hogeschool and Hanze University of Applied Sciences.

They get the data before I have drawn anything from it. I clean it first. Anything irrelevant to the question comes out, because a session that spends forty minutes on a quote about the car park has lost the room. Cleaning is not analysing. What is left is unsorted and uninterpreted. If a team only ever sees themes I have already named, they are still receiving research. They need to see every step between the data and the conclusion. That is what makes the conclusion theirs.

I ask questions. The move that makes the whole thing work is refusing to be the person with the answer. A group that gets corrected learns that the researcher decides. A group that gets asked what it thinks learns to decide for itself.

Cross discipline on purpose. A developer, a designer and a product manager notice different things in the same sentence. The value is that each of them watches the others find something they missed. That is what turns a finding into a shared fact.

One recommendation, agreed in the room. The group leaves with one recommendation it can defend, in a priority order they settled while they were still standing in front of the wall.

Where the line is

Democratising research means handing over the sense making. The research itself stays with a researcher.

A product team brings its assumptions and the success metrics it cares about. It can run a light interview if a researcher has trained and prepped it for that specific conversation. It does not design the study, and it does not run it. That part needs someone who was trained to do it, because everything downstream is worthless if the data is bad.

I am not a developer. If I spent an afternoon in the codebase I would break things in ways that would take somebody a week to unpick. Being keen would not help. A product owner setting up their own research is the same move in the other direction. It fails the same way. Teams trust the format because it respects the craft in both directions.

“

Yeah, I need to hire a researcher.

Outcome

What a good session produces is a team that can make its own call under pressure. At Fugro the two groups finished differently and both of them were right.

One found 100 percent of the key themes in a dataset they had never seen before, on their first attempt at affinity mapping. The other made a deliberate call: time is short, so take the strongest theme and build a recommendation we can actually defend. Which they did. They chose speed over rigour on purpose. That choice is what I want a team to be able to make without me.

The outcome that lasts is that a whole product team ends up feeling responsible for what it is building. Research stops being a report, or data, or a set of findings arriving from elsewhere. It becomes something the team carries, because they co-created the insights, the recommendations and the priority order. A developer who helped find a theme will argue for it in a roadmap meeting six weeks later. A product manager who helped write the recommendation will defend it when it gets squeezed. They do not have to be persuaded. They reached the conclusion themselves.

David Broža is the lead engineer at Ground IQ. At the end he said, “Gosh, research is actually really hard.” That is the sentence I want out of a workshop. Everybody says research is valuable. Almost nobody acts on it. What I want a team to find out is that research is a craft with a floor, and that the floor is higher than it looks.

The clearest evidence is a hiring decision. Ground IQ had a designer role already in progress. After the workshop they rewrote it to require research skills, to hold the gap until there is budget for a full researcher, and a researcher went onto the hiring plan for after their first launch. A workshop that teaches a product team to run its own synthesis ended with the head of product deciding he needed to hire someone who does it properly. That is the format working as intended. Most people expect democratisation to do the opposite.

This is the same thing I build everywhere else. The system a team works inside, so the quality of the work does not depend on me being in the room.

I gave a talk on this method for Lyssna, Research that sticks, collaborative synthesis in action.