Thirty minutes every two weeks – just three person hours – can save you two weeks of wasted time, which amounts to thousands of dollars in salary and participant compensation.
Why it matters: Last week you wrote five strong hypotheses worth testing, but this puts you in a bind: each of your teammates has a slightly different take on what information matters most. The discussion about validity will happen regardless, so we front-load and harness that energy to create a stronger study.
Rolling research is fast and consistent on purpose. Fast means there is no room to restart, and consistent means we keep the scope crisp. The kickoff meeting is where we put a blowtorch to those hypotheses, leading to actionable crispy creme-brulee'd insights.
The kickoff is a group stakeholder interview.
Not a presentation. A lightweight interview and planning meeting, where the researcher facilitates a set of activities and questions to understand the scope of the project. This goes beyond the hypotheses, learning about the session stimulus, keywords and terminology, participant profiles, and other important types of information to look for in sessions.
The intake form is the backbone of the discussion. The raw request details are captured: questions, profiles, stimulus, and timeline. The kickoff validates that with teammates who have important differences in perspective. By getting these different perspectives in the room, our research is far richer, probing into topics the researcher might miss on their own.
Who's in the room: the Product Manager, Designer, Engineer, and anyone else who will be building the thing. The people with the strongly held opinions are excellent participants, as they often uncover interesting topics to explore during testing.
What are we aligning on?
The research question. Your hypotheses inform our research questions, and team input rounds out our viewpoint with detailed questions. Has the team contemplated new ways to launch a feature? Test it. Is there a bit of jargon that keeps popping up in support? Dig into that! While we remain hyper-focused, we do not leave insights on the table. And most importantly, we gain agreement on what we are learning, and what we are not.
The user participant. "Small business owner" may be a user, but they should not be a participant you recruit. The researcher leads the team in a discussion of key psychographics to understand the behaviors and attitudes we're trying to learn about. Participant definition gives the team input into the type of lived experiences, product experience, and demographics we are aiming to recruit, and precise participants produce findings you can build on.
The stimulus matters. What are we showing participants, and at what fidelity? A lower-fidelity wireframe gets different feedback from a working prototype in staging. Discussing the benefits and drawbacks of testing with different participants, at different stages, is key to setting up a study that gets results. The stimulus can also change across a session, from prototype to co-design activity, to interview. A team discussion ensures we maximize participant face time.
The decision. What will we do if we learn what we hope to? Who will make the go/no-go call? Is there any data blocking our decision? Again, such a critical moment to involve the team, who may have vastly different ideas of what a "successful" test looks like. Getting crisp on the contingencies, writing them in a scope document, and holding the team to them is critical. Skipping this step just delays a debate about what to do about what we find.
Yes, your AI needs this meeting too.
Well, Flash Findings – the atomic output of every study – land in your knowledge base. What we don't capture as a field, can't be filtered on later. Six months from now, the assistant needs to be able to differentiate between participant types, stimulus, methodology, date, and all this needs to be structured from the start. During kickoff, we define the key attributes to collect and index within your product and business ecosystem.
Without setting this up at the start, it's incredibly tedious – nigh impossible – to backfill information not indexed from the start.
So, the kickoff is where the team agrees on the scope of the testing, the stimulus, what key retrieval mechanisms need to be in place.
Yes, but – I already know what we need to test.
You probably do! The question is whether the rest of the team knows. Does the Product Manager reviewing the roadmap for next sprint have a similar picture as the engineer and designer?
The kickoff isn't just for the researcher, it's also for the team! By the time the meeting starts, the researcher has read the intake, considered study design, and prepared the study in the research tool of choice. The kickoff is for the primary stakeholder and for everyone else: getting the people who receive the findings and who will have to take action on them. Getting them aligned before the study means the readout is a decision, and motion is built in. Insights are not a negotiation on what to do – they are a clear direction based on what the study was supposed to answer.
The bottom line: Thirty minutes now. Two weeks you don't run twice.
I'd encourage you to run a solo kickoff first. It's harder than it looks! Take your strongest hypothesis from last week and define the question, user, stimulus, and decision.
Be specific enough so a stranger could recruit based on your user description and a designer could create the stimulus without a lot of follow-up questions. Socialize it with 3-5 of your team. Share your answers, watch where the team pushes back. This pushback is the scope problem you just solved before it cost you two weeks.
Next week: how recruiting actually works – and why the participant you think you need is usually not the one you should be talking to.