Ten Minutes, Five Teams, One Pizza: Delivering Continuous Discovery Programs That Run like Clockwork
by Josh Morales
The ResearchOps Review is supported by User Interviews, now part of UserTesting. User Interviews makes it fast, easy, and affordable to recruit participants so you can scale research without sacrificing quality.
At the first event in Berlin, I was definitely the one breaking a sweat. It was March 2025, and I had my printed checklist in hand as I ran around the office making sure that everything was in place: the product users, my colleagues, the tables, the timer, and, of course, the pizza. Some of the users we had invited hadn’t shown up, so I sprinted into the common areas of our building and tried to recruit anyone relaxing in the corridors to take part. Most people politely declined, and I didn’t blame them. If a sweaty stranger offered me pizza in exchange for chatting to a company I’d never heard of—Miro who?—I wouldn’t have known how to respond either.
In the end, five minutes before the event started, an office manager from the same building invited me to ask around their offices: Would you like to take part in a one-hour continuous discovery session with Miro’s product builders? Right on time, I came back with two extra participants; I’ll never forget the look of relief my colleague Anthony and I shared.
In this article, I’ll share how to build the operations that make continuous discovery sessions run like clockwork, and the value these sessions can deliver. I’ll walk you through who to invite, what you need to do to create a repeatable (and sustainable) setup across locations and in remote contexts, and the small decisions that can make or break the event dynamic.
The Continuous Discovery Method
Product discovery coach Teresa Torres coined the term continuous discovery to describe the practice of building regular, structured user contact into product development so that, rather than arriving in waves through ad hoc studies done by someone else, insights flow continuously—and continuously build empathy and inform product decision-making.
Just over a year ago, when I first announced on LinkedIn that we were kickstarting a continuous discovery program in Miro’s Berlin office, someone left a comment declaring it the ultimate solution to all research problems. My reply then reflects my enduring perspective today: continuous discovery is one methodology for collecting evidence from users, but it’s not a replacement for other research approaches, such as user interviews or usability testing. Still, when done well, these in-person, pizza-fueled programs can help move the needle on customer-centricity in ways that other methods often can’t.
At a high level, continuous discovery sessions run as follows: once a month, you’ll invite five product users to your offices for one hour to take part in short, ten-minute interviews with five different product teams, each with an interviewer and a notetaker. Each team can use their ten minutes to ask questions about their product area or test designs. Every ten minutes, users rotate clockwise to the next table for a new set of questions asked by a different team. By the end of the hour, every team has spoken with every user, and every user has weighed in on five product ideas. Rather than a library or research lab atmosphere, the dynamic is social, fun (and loud at times), and it always ends with pizza.
Continuous discovery sessions are often thought of as a type of casual or informal research—less valid than, say, one-on-one interviews. Yes, by design these sessions are informal, but continuous discovery earns its place. It’s neither generative (an open exploration of hunches in the problem space) nor purely evaluative (rigorous evidence-gathering in the solution space). Instead, it sits in the middle: a bit more towards validation, where most product decisions actually live, and where uncertainty needs to be reduced quickly rather than completely. It’s not generally a good methodological choice when a deep diagnosis is needed, or when you’re dealing with sensitive topics or high-stakes validation that requires rigor. It is a good choice for early product ideas, rough prototypes, and assumption checks.
Time Constraint Is a Feature, Not a Bug
The feedback we most often receive from colleagues is that there just isn’t enough time with each user to dig in as deep as they’d like—ten minutes can feel short when you have a lot to cover. But the time limit doesn’t only facilitate getting as many users as possible in front of as many team members as possible.
An in-person continuous discovery session gets closer to ecological validity—the degree to which a study’s conditions resemble the real-world context in which the behavior normally occurs—than a controlled one-on-one study. I’ve come to believe that nobody approaches a new feature with the patience of a usability test participant. People approach an app or task the way they approach everything else: while distracted, half-committed, perhaps in a hurry. A compressed time period exploring a product mirrors how users tend to meet your product in the wild. They scan, process, and make decisions under cognitive load—in situations not unlike busy rooms with limited time to talk—and don’t necessarily give your app or their task undivided attention. How would they, with hundreds of other tabs, apps, tasks, and people claiming their attention?
The ten-minute time limit also exposes the real hierarchy of attention. Teams see firsthand which interface elements actually guide behavior versus their assumptions; that gap between the observed and the assumed is where much of continuous discovery’s value lies: the most honest findings show up when users don’t have time to be polite.
Going Deep, Not Wide
For people who do research (PWDR),1 choosing one or two questions to ask a participant and going deep rather than wide in scope can be a challenge. That’s why it’s essential to align on the study design and scope with colleagues before the session begins—it’s also reasonable to reiterate alignment goals during the event.
Even with the challenge of choosing only one or two questions, teams rarely arrive at a continuous discovery session with nothing to explore: there’s always something that they need to validate, whether a sketch, a prototype, a vibe-coded idea, or an assumption they want to test before pushing it to production or pausing to do more research. They rarely arrive needing statistical confidence; they’re seeking enough signal to make the next call—directional guidance as I like to call it. Honestly, sometimes they just need validation for their own peace of mind, or they simply want to keep improving their interviewing skills. Regardless, the format is calibrated for the specific moment when teams need to be unblocked.
While PWDRs might feel stifled by the time limit, for users it’s a feature rather than a bug; they get to spend an hour exploring a handful of new product ideas and meeting new people who want to learn from them. It’s social and fun.
Recruitment, Roles, and Responsibilities
Perhaps you’re now convinced that these sessions would be a valuable addition to your research toolkit; now you need to know how to run them. To run a continuous discovery session, you’ll need eighteen people in total: ten colleagues who will form five “teams,” each with an interviewer and a notetaker, five product users, and a support crew comprising the following:
A lead to moderate the session and present.
A support person to handle reception duties, welcome users, and back up the moderator if something goes off script.
An additional support person to run the parallel workshop when there are surplus users or to step in should anything unexpected happen.
If you can find only one other coconspirator, you can split these duties between you. It’s a little less comfortable, but it’s still doable.
Recruiting Colleagues
Product designers, product managers, engineers, and data analysts are the most natural fit for these sessions as their work tends to benefit most from short, frequent check-ins with users. But over time, colleagues with all sorts of job titles may join the sessions: customer success managers, marketing, and community professionals. Basically, everyone whose job involves thinking about users.
Key to attracting your colleagues is crafting a clear message in the most relevant communication channel that explains when the continuous discovery session will take place, what it involves, the benefits of participating, and how to sign up. For first-timers, the entire experience can feel daunting, so we also include a short set of dos and don’ts, interviewing tips, and note-taking templates on the signup page. Plus, we offer a quick preparatory call to walk them through roles and responsibilities, ask what they want to test, and explain what to do if they have questions. This information tends to settle the nerves of anyone who’s not practiced in talking to users. We also keep a waiting list, because the five spots tend to fill up fast, and occasionally folks change their minds before the event starts.
Recruiting Product Users
This is one of the rare cases where the profile of the people you recruit doesn’t really matter. You want to recruit “active users,” full stop. Here’s why: your users will be exposed to five radically different ideas in one hour, so there’s no point hunting for specific profiles. If one of the teams insists they really need a particular audience, perhaps a continuous discovery session isn’t the right approach. In which case, help them find the right method for their question.
Finally, to ensure that you don’t run short on users on the day, learn from my sweaty Berlin office sprint: over-recruit. Aim for ten confirmed users instead of five. While more than five users is never a problem, if fewer than five turn up, teams are left waiting with no one to talk to, breaking the dynamic of the session for everyone. We often confirm well past ten participants and run a parallel cocreation workshop, which one of our researchers moderates, turning the surplus into a live collaboration opportunity and inviting colleagues to get involved.
To find users, follow your standard participant recruitment process if you have one. You can also use these tactics:
When you’re recruiting people based in the city where you’re running the event, a LinkedIn post can be an effective addition.
Draft a simple message that your colleagues can share across their networks; this travels surprisingly well.
Tap into forums and user communities related to your product or service.
Consider printing and sticking QR codes up at friends’ offices.
Ask office managers to invite their staff in relevant roles.
Finally, as a last resort, don’t forget the always invaluable help of family and friends.
The most efficient way to consolidate your recruitment operations is to create a single panel for product users to sign up. Don’t overcomplicate it; a simple form requesting a name and contact details is enough. If you have access to a specialized event tool like Luma (see Figure 1), use it to do the heavy lifting on waiting lists, reminders, and cancellations. Whatever you end up using, make sure to explain in detail how to get to your offices and what to expect.
Setting Up for (Repeatable) Success
Once you’ve successfully recruited all your participants, there are a few essential things you’ll need to coordinate and source. Most can be reused from session to session and require one-time investments of time and minimal budget. Here’s a list of must-haves:
A physical room. Don’t get too picky. Make sure the room comfortably fits five tables, each with enough space to seat three people—two team members and a user. If the tables are conference-room-long, divide the groups at each end of the table. We run sessions in my office’s lunch area because there’s plenty of space and the tables move easily. Reserve the space ahead of time, and make sure a screen is available to share a slide deck.
A presentation. Create a brief slide deck that covers who you and your team are, what the agenda is, and how the dynamic works (most of which you can borrow straight from this article).
Nondisclosure agreement (NDA) forms. Print plenty of them, make sure users sign them, then forget about them. You can also send the NDAs ahead of time in recruitment, confirmation, and reminder emails, but people typically aren’t great at signing them in advance, so always keep paper copies in the office for anyone who hasn’t signed.
A Sharpie and name tags. Raid the stationery closet; having more than you need is always better.
A timer. You can use any timer, but we’re self-professed geeks, so we love Jake Knapp’s Design Sprint clock. Whatever you use, make sure it’s visible to teams so they can keep an eye on their time.
Pizza. The jewel of the crown, and the only recurring fiscal investment in the effort. After many iterations, we’ve concluded that the right amount is six large or eight small pizzas. Always include one gluten-free pizza. Toppings like pepperoni, truffle, and ricotta are extra impressive. Order in advance and schedule delivery to happen halfway through the session: you won’t have much to do by then because the rounds are running, and the pizzas will still be hot and crispy by the time the session wraps.
Feedback forms. You’ll need one feedback form for participants (include a QR code at the end of the presentation); leave it visible while everyone enjoys pizza and resend it in a thank-you message. You should also send a feedback form to your colleagues. Keeping it to a few basic questions is most effective: what to keep, what to improve, and what to add.
We don’t offer monetary incentives for taking part in a continuous discovery session. We get enough signups by letting users see what we’re working on, cocreate future solutions with us, take home some swag, get sent the event photos afterwards, and of course, network over drinks and food.
Timing Is Everything
We’ve found that Thursday at 5:00 p.m. works best: it’s a good preamble to the weekend and a strong competitor to the standard after-work get-together. We also make it look and feel like a social gathering.
Once the date is locked in, create two events in the calendar:
One for your colleagues, starting thirty minutes prior to the event start in case there are last-minute questions or help is needed with setting up the room. Also, having everyone on your team gathered in the room before users arrive is crucial: you’ll start on time, and it shows users they’ve walked into something that respects them and their time.
The second invite is for users. In the calendar invite, set the event to start fifteen minutes before the kickoff. That buffer works wonders for anyone commuting, and it protects your start time.
One hour before the start time, confirm all participants are still joining. Finalize the room setup: five tables of three chairs each, or five numbered spots distributed along longer tables (numbering the tables or spots in advance makes group assignments much easier). Place water and snacks (an optional add-on) on the tables. Test the tech and make sure your presentation and timer are visible. Order the pizza and schedule the delivery.
Thirty minutes before the start time, meet with your core event team for the day and walk through the checklist together. Once everything is in order, the support crew can head to the reception area to welcome the product users.
Designing the Doorknob Moment
At the end of the hour, when the final session is done, serving pizza is the perfect bridge for teams and users to naturally pick up conversations they didn’t have time to follow up on. It’s the equivalent of stopping the recording in a moderated interview, only to hear the user suddenly open up about something that wasn’t evident before—a trick I learned from Steve Portigal’s classic book, Interviewing Users,2 in which he wrote, “Physicians and therapists are familiar with the ‘doorknob phenomenon,’ where crucial information is revealed just as the patient is about to depart.”
So design the doorknob moment into your event intentionally. We aim to move to a narrower space so that colleagues and users have to walk through the crowd to reach the pizza, and conversations are struck up more naturally. It’s true that some folks prefer to use this time to quickly debrief and even make decisions on the spot, but we always make sure we’re the first to start conversations.
Finally, we also created a simple ritual to serve as our record of the event: a group selfie over pizza (see Figure 2). The photo is also incredibly useful for recruiting new participants through social media to join in future events.
Two Things That Should Work, but Don’t
Back to the event in Berlin, which I mentioned at the start of this article. Aside from starting late, we also decided to open with an icebreaker so everyone could introduce themselves: share your name and a superpower you’d choose, or something along those lines. We did this fifteen times (once for each colleague and product user), wasted a lot of time, and overwhelmed everyone before the event had even started. In short, cut the icebreakers and let the name tags do their job.
Also, since the product users were our guests of honor, my instinct had been to ask them to stay seated at the same table while colleagues moved to a new user. After all, I like to be accommodating. But that decision came with an unexpected cost. Moving five teams of colleagues is more disruptive than moving one user, and it only gets worse when the team has a “just one more question” look in their eyes. In contrast, when you ask a user to move, they tend not to object, and the team doesn’t complain about the move either. It works like a charm.
Turning Signal into Action
I keep telling everyone around me that if you don’t put enough effort into activating findings, it’s as if the research never happened—and the same goes for continuous discovery sessions. We have four mechanisms in place to help ensure that teams follow up on what they learned:
Light documenting. The day after the event, an automated message pops up in various chat channels, reminding colleagues to put together a top-three-learnings slide using a template we’ve prepared (see Figure 3). We include this slide in our monthly UX research newsletter.
Cross-pollination. We review the findings, distribute them across key channels, DM individuals, and often set up meetings between teams whose findings overlap. We believe that findings can act as a glue between teams and help a company focus on the user rather than its internal organizational chart.
Continuity. Sometimes teams realize that what they learned isn’t enough, or that the problem is bigger than they anticipated. When that happens, we either support them with a dedicated follow-up study or fold the question into our own research roadmap.
Praise, praise, praise. The first and second time you run a continuous discovery session, colleagues will likely join out of novelty. At some point, they’ll realize that the sessions create additional work on top of their day-to-day responsibilities, so participation might stall. To combat this natural decline, we drop colleagues’ names in relevant conversations, reinforcing that they took the time to talk to users and acknowledging the positive impact of doing so. This also sets them up as role models within the team. Finally, with their consent, we tag them in our external company social media posts, because who doesn’t like a little profile boost?
That’s as far as we go. We don’t chase people to act on findings or to explain the product decisions they made. For us, it’s more than enough if colleagues are exposed to users and have their assumptions challenged, even for an hour.
Scaling Across Locations
Kate Towsey’s book, Research That Scales,3 opens with a chapter titled “Research Does Not Scale—Systems Do,” and I couldn’t agree more. What we, the Miro UXR team, have built is exactly that: a continuous discovery research system that lets us run quick, cost-effective rounds of moderated, in-person qualitative interviews with users. Our system—the system I’ve just shared—is now so effective that once you’ve built reusable assets, you can run continuous discovery sessions across many locations. If you or your core team can’t travel to a particular location, you can easily train others to replicate the format. In our case, we started in Berlin, brought continuous discovery to Amsterdam, then we equipped people from the design team to run their own version in our Tokyo office.
Running Remote Sessions
While continuous discovery works best in person, we’ve also successfully run a remote version, though the format is obviously different. The remote version runs weekly rather than monthly, and aims to get five users in front of a single team in one day. We run it on Wednesdays, our no-meeting day at Miro, so it doesn’t conflict with anyone’s calendar. If you can find a similar opportunity in your organization’s calendar, leverage it.
In the case of remote continuous discovery, participant recruitment can be more specific. Users aren’t rotating among five teams with radically different ideas; they’re talking to just one product team. So if a team wants to meet with a particular profile, this can also be the place to do so. The rest works pretty much the same as the in-person version. You meet with the team beforehand to help shape the research plan and the discussion guide. They run the sessions using whatever moderated research tools you already have in place, and you keep an eye on your messaging app during the day in case something goes sideways.
If you can, run both in-person and remote sessions. They don’t compete. In fact, they complement each other in really nice ways. While the in-person version creates rhythm (the monthly cadence becomes a known organizational beat) and social proof (fueled by pizza), the remote version provides the opportunity to explore targeted questions. And if you want to run in-person events but don’t have a brick-and-mortar office, coworking spaces also work, as do partner organizations willing to lend you a room.
Breaking Silos, Building Empathy
Continuous discovery moves the needle in two ways that other research methodologies can’t: it breaks silos and builds empathy. Seating a customer success manager, engineer, and a product designer at adjacent tables and giving them the opportunity to listen to the same product users encourages curiosity about each other’s questions in a way that a messaging channel never could. I’ve watched more cross-team collaboration efforts start over a slice of pizza than in any alignment meeting.
Colleagues also leave continuous discovery sessions with a sharper sense of users’ needs, and with a better understanding of what the UX research team does and why it matters. That second form of empathy is the benefit that nobody plans for, and it’s the one that shifts the way the organization approaches research. Teams stop seeing research as a bottleneck and become advocates because they’ve finally had a low-stakes way to practice “customer-centricity.” Once you’ve created ease around something someone already wanted to be good at, they don’t need convincing to come back next month.
Credits
Thanks to my continuous discovery partner-in-crime, Anthony Li. Thanks, also, to Deniz Kartepe; Michael Schade; Lene Bayerlein; Gabriel Lovato; Zuza Jablonska; Bo Liu; Roman Mazur; and every PWDR and product user who has ever shown up.
The ResearchOps Review is made possible by User Interviews, now part of UserTesting. With a vast participant network, precise matching, and fraud prevention, User Interviews can reliably fill any research study. Source, screen, track and pay participants, then move seamlessly from data collection to deep analysis, all in one place. → Learn more about User Interviews for ResearchOps.
The acronym “PWDR” was coined by Kate Towsey in 2019 to describe people who are not full-time user researchers but do research as part of their role, such as designers, product managers, marketing managers, and engineers.
Portigal, Steve. 2023. Interviewing Users (2nd Edition): How to Uncover Compelling Insights. 2nd ed. Rosenfeld Media. https://rosenfeldmedia.com/books/interviewing-users-second-edition/.
Towsey, Kate. 2024. Research That Scales: The Research Operations Handbook. Rosenfeld Media. https://rosenfeldmedia.com/books/research-that-scales/.
 | A guest post by
|