There is a strange gap in most organisations. The product team works hard to book a handful of user conversations each month, while the support desk has hundreds of them every week and nobody reads the notes.
For my MSc thesis I asked a twelve-person product team how non-product colleagues should fit into continuous discovery. Their answers were more enthusiastic, and more specific, than I expected.
Support is closest to the pain
The team’s reasoning, with three votes, was simple:
Support desks are closest to the user from a pain point perspective on a daily basis.
That is not a small point. Support hears about problems as they happen, from people who are annoyed enough to get in touch, with the exact context of what they were trying to do. It is the fastest, cheapest signal in the building.
They voted for a concrete practice too, with two votes: service desk reports should be reviewed to make sure the right areas are being focused on. Not just read once, but used as a check on whether your research is pointed at the things people actually struggle with.
Sales and pre-sales carry the cross-product view
The top answer in this whole section, with four votes, was about aligning the pre-sales and quality function more closely with research, because they hold a large amount of experience and opinion across topics, products and areas.
This is the perspective researchers most often lack. A researcher goes deep on one feature. A salesperson has had the same objection raised by forty different customers across the whole product line, and knows which of them bought anyway.
Everyone else needs awareness, not involvement
The team drew a sensible boundary. Their answers, with three votes:
All areas of the business at a minimum should be aware of the process, have the ability to request research, and be informed of research findings where necessary.
So there are three levels:
- Directly involved: the product team.
- Involved when relevant: subject matter experts, requesters, sales and marketing. Anyone who understands the service the product or research is influencing.
- Aware and able to ask: the rest of the business.
They were also clear on how the wider business should participate. With two votes: they could request research from skilled user researchers and work with them for their needs, rather than running their own studies. That keeps quality controlled while still letting anyone raise a question. It pairs neatly with having a proper research request process.
Executives and senior management sit slightly apart: aware of the process and of any large research underway, with access to the results.
Non-product colleagues have their own findings
One answer, with two votes, is worth calling out because it flips the usual framing:
Regularly, non-product members have insights and findings of their own.
Support and sales are not just a data source to be mined. They form views, spot patterns, and often know exactly what is wrong before research confirms it. Treating them as colleagues with insight, rather than as a queue of tickets to analyse, changes the relationship and the quality of what you get.
Check internal sources before you book interviews
This is the practical habit that ties it together, and it came up in the workshop as its own answer: consolidate the data you already have internally, from product owners, the support desk and sales, before reaching out to users.
The practitioners I interviewed did exactly this. Alongside interviews, they pulled signal from:
- Customer support tickets
- Sales feedback
- Real-time product analytics and user behaviour data
- Social channels and app store reviews
- Community spaces, including a Discord server for their most engaged users
Doing this first has two benefits. You stop spending user time on questions you could have answered internally, and the questions you do ask get sharper because you already know the shape of the problem.
Where it goes wrong
Two warnings from the research.
Marketing or account teams blocking access. Several practitioners described communication barriers where other teams prevented direct contact with customers. If that is your situation, the internal signal sources above become more important, not less, and the access problem needs solving at a level above the research team.
Training expectations. If you involve non-product colleagues in sessions, the same rules apply as for anyone else: give them GDPR and personal data basics, let them observe and take notes rather than lead, and make sure someone with research skill is present. I go into that in who should run continuous discovery.
The easiest place to start
Book thirty minutes with whoever runs your support desk. Ask them what the three most common complaints were last month, and what they think causes them. You will get more actionable material than most teams get from a week of interviews, and you will have started a relationship that keeps paying.
Further reading
- Teresa Torres, Product Talk. producttalk.org
- My MSc research. Eight expert interviews and a twelve-person workshop. Read the case study
Next, read the continuous product discovery process or what a good research request looks like.
Based on my MSc thesis on continuous product discovery. The research is written up in the case study.
