Most research problems start before anyone talks to a user. Someone asks “can we test this?”, nobody agrees what the answer would look like, and three weeks later the findings land on a decision that was already made.
Intake is the cheapest place to fix that. For my MSc thesis I asked a twelve-person product team to design their own research request process and vote on what it should contain. Here is what they produced.
What a request should contain
Three answers tied at the top with three votes each. Together they are a decent minimum standard.
1. A hypothesis to prove or disprove. Not a feature to validate. A hypothesis forces the requester to say what they believe and what would change their mind, which is the difference between research and reassurance.
2. The outcome expected and the output required. What decision will this inform, and what do you need back: a summary, a recommendation, a set of quotes, a number?
3. The priority and the opportunity it represents. The team specifically named revenue and market retention as the kind of thing to attach. This is what lets a research backlog be prioritised against everything else the business is doing.
Then, with two votes:
4. Target groups and methods, agreed together. Who to speak to and how should be decided collaboratively between the requester and whoever will run it, aimed at the goal the requester defined.
And the rest of their list, each worth including:
5. What is already known. State what is fact, what is an assumption that needs validating, and what genuinely new insight you are after, so the research team does not spend time re-covering ground.
6. Time and cost boundaries. Research without a boundary expands to fill whatever space it is given.
7. A commitment from the requester to stay involved. Not just to receive a report at the end.
Underneath all of it: use a template, document the process, and keep the research backlog visible so anyone can see what is queued and discuss priority.
Check what you already have first
One answer from the same workshop deserves its own section, because it is the fastest win available and almost nobody does it:
Consolidate data we already have internally from product owners, the support desk, sales and elsewhere, before reaching out to users.
Your organisation is usually sitting on a lot of the answer already. Support tickets, sales call notes, analytics, app store reviews. Checking those first does two things. It stops you asking users questions you could have answered yourself, and it sharpens the questions that are genuinely worth their time.
Agree success criteria up front
The team voted for defining success criteria at the start and agreeing them with stakeholders for that specific activity. This is the same discipline that shows up in assumption testing and in avoiding confirmation bias, and it works for the same reason.
If you decide afterwards what counts as a good result, you will find one. If you decide beforehand, the research can actually tell you something you did not want to hear.
Communicate the outputs both ways
An easy one to miss. The team voted for good communication of outputs to internal teams and to the people who were interviewed.
Telling participants what happened as a result of their time is the single strongest lever on whether they take part again, which I cover in recruiting participants.
How often should this run?
I asked the same team how frequently the research process should repeat. The two top answers, tied at four votes each, were blunt:
Continuously, so we are always aware and up to date.
It is continuous. It should never stop and start.
But their qualifications matter as much as the headline. Specific pieces of research depend on timelines and budgets, even if the overall process never stops. And you have to stay conscious of cost against value, avoid inundating the same participants, and make sure you have the capacity to actually make the changes people ask for. As one person put it, customers have to see improvements or they lose faith.
That is the honest version of “always on”. The listening never stops, but each individual study still needs a boundary.
A template you can copy
Putting it together, a research request that will not waste anyone’s time answers:
- Hypothesis. What do we believe, and what would prove us wrong?
- Decision. What will this inform, and when is that decision being made?
- Opportunity. What is at stake, in business terms?
- Already known. What is fact, what is assumption, what is the gap?
- Who and how. Which users, and roughly what method?
- Boundaries. Time and budget available.
- Involvement. Who from the requesting side is joining the sessions?
Seven fields, most of them one line. It takes ten minutes to fill in and saves weeks.
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 how to structure a research insight backlog or the continuous product discovery process.
Based on my MSc thesis on continuous product discovery. The research is written up in the case study.
