Running Continuous Discovery on a Team Too Small to Have a Research Org

Most SaaS teams that want to do continuous discovery tell themselves the same story: they will start once they hire a researcher. That hire never comes before Series B, and by then the product direction has already been set by whoever was loudest in the planning meeting. Teresa Torres, whose 2021 book Continuous Discovery Habits defined the modern practice, found in her research with hundreds of product teams that the most common barrier to weekly customer contact is not headcount — it is the belief that research requires a research organization.

It does not. The minimum viable discovery practice is one 30-minute customer conversation per week, conducted by a product trio of three people who already exist on your team. That is twelve conversations per quarter, each generating signal that improves the next decision. At a median SaaS team size of eight people (per OpenView's 2024 Product Benchmarks survey), there is enough capacity to run this cadence without a single dedicated researcher.

This post covers the specific mechanics: how to recruit participants without a CRM team, how to structure a 30-minute session so it generates insight rather than feature requests, and how to synthesize across sessions without drowning in notes.

Why "We'll Start When We Have a Researcher" Is the Wrong Frame

The assumption behind the researcher-first approach is that discovery is a specialized activity requiring training that generalist PMs, designers, and engineers do not have. This is partially true for moderated usability testing and diary studies. It is not true for the kind of exploratory interviewing that drives most product decisions.

Torres distinguishes between generative research (exploring what problems exist) and evaluative research (testing whether a solution works). Generative research — the foundation of continuous discovery — requires curiosity and structured questioning, not a research degree. The skill that takes months to develop is resisting the urge to pitch the product during the interview. That is a discipline problem, not a credentials problem.

The deeper issue is that centralizing discovery in a research function creates a translation problem. Insights travel from customer to researcher to report to PM to roadmap, losing fidelity at each handoff. When the product trio conducts the interview themselves, there is no handoff. The engineer who hears a customer describe a painful workaround understands it in a way that a research report can never convey.

A 2023 Pendo survey found that product teams who did not involve engineers or designers in customer research were 2.4x more likely to ship features that required significant post-launch rework. The cost of the translation problem is measurable.

The Minimum Viable Discovery Cadence

The cadence that works for small teams has four components:

The weekly interview is the anchor. Everything else is lightweight scaffolding that prevents the interviews from becoming isolated anecdotes.

Recruiting participants is the operational challenge most teams get wrong. The default — asking the CS team to "find someone willing to talk" — produces a biased sample of either your happiest customers (who CS is careful not to burn out) or your most vocal complainers (who CS wants to redirect). A better approach is to build a participant panel directly inside your product. A simple in-app survey triggered after a user completes a key workflow, offering a 20-minute conversation in exchange for a $25 gift card, produces a participant pool that reflects actual usage behavior.

Amplitude's 2024 Product Report found that teams with a standing participant panel recruited interview participants 68% faster than teams that relied on ad-hoc CS referrals. The panel does not need to be large — 30 to 50 opted-in users is enough to sustain a weekly cadence for six months before needing refresh.

The interview itself should follow a structured but flexible guide. The first five minutes establish context (what is the participant's role, what does a typical day look like). The middle 20 minutes explore the specific job or struggle area you are investigating. The final five minutes invite the participant to share anything you did not ask about. You are not testing a solution in this session. You are mapping the problem space.

Structuring the 30-Minute Session

A common failure mode is letting the interview drift into a feature request session. The participant starts describing what they want the product to do, the PM starts taking notes on the requests, and by the end of the session the team has a list of features rather than an understanding of the underlying need. This is what Torres calls "the interview trap" — mining for solutions when you should be mining for problems.

The framing question that prevents this is: "Tell me about the last time you needed to [task in your problem area]. Walk me through what happened." The retrospective framing — asking about something that actually occurred rather than something hypothetical — produces concrete, specific stories rather than wishful feature descriptions.

A 30-minute session structure for a team investigating, for example, why users struggle to share reports with stakeholders outside the product:

1. Context (5 min): "What's your role? How often do you interact with stakeholders who don't use [product]?"
2. Recent story (15 min): "Tell me about the last time you needed to share an update with someone outside the product. What happened from the beginning?"
3. Probe the friction (8 min): Follow the story's pain points. "What did you do when that didn't work? How much time did that take? What did you wish you could do?"
4. Open close (2 min): "Is there anything about this problem that I haven't asked about that you think I should know?"

After the session, the trio spends 15 minutes capturing: one key assumption confirmed, one assumption challenged, one new question raised, and one direct quote that captured the participant's pain most precisely. This four-field template takes less than 15 minutes and produces synthesis artifacts that are actually read.

Building an Opportunity Space Without Formal Research Ops

The output of continuous discovery is not a list of features. It is an opportunity space: a map of the customer problems and desired outcomes that exist in your domain. Torres's Opportunity-Solution Tree (OST) is the primary tool for structuring this map, and it connects directly to roadmap decisions. For a deeper walkthrough of how OSTs replace traditional feature roadmaps, see Using Opportunity-Solution Trees to Replace the Feature-Request Roadmap.

For a small team, the opportunity space lives in a lightweight shared document rather than a dedicated research repository. The document has three layers:

• Level 1 — Desired outcomes: The metrics or states that customers want to achieve (e.g., "send a polished update to my board in under 10 minutes")
• Level 2 — Opportunities: The obstacles that prevent those outcomes ("can't include data from third-party tools without exporting to CSV")
• Level 3 — Evidence: The specific interview quotes and observations that support each opportunity

The key discipline is not adding to Level 3 without first asking: does this quote support an existing opportunity, or does it suggest a new one? This prevents the document from becoming a raw quote dump.

After three to four weeks of weekly interviews, patterns typically emerge. Two or three opportunities will appear in multiple sessions. These become the inputs to the Opportunity-Solution Tree for your roadmap, connecting discovery directly to delivery.

The Synthesis Rhythm That Prevents Insight Debt

The biggest failure mode in small-team continuous discovery is not insufficient interviews — it is insufficient synthesis. Teams conduct weekly sessions but never accumulate the insights across weeks, so each interview exists in isolation. After a month, the team has four separate interview notes that nobody connects. This is what researchers call "insight debt" — the accumulated cost of unprocessed observations.

The synthesis rhythm that prevents this is a monthly assumption audit. At the start of each month, the trio reviews the past four weeks of synthesis notes and asks three questions:

1. Which assumptions about the customer's problem have been confirmed, challenged, or invalidated?
2. Which opportunities have appeared in multiple sessions (signal) versus only once (noise)?
3. What has changed in how we would describe the problem space compared to 30 days ago?

The assumption audit should take 45 minutes. Its output is a single updated assumption map — not a presentation, not a report, just a living document that tracks what the team believes about the customer and how confident they are in each belief.

For teams that want a more structured synthesis system, the customer interview synthesis pattern library approach builds on this foundation with a reusable tagging taxonomy.

Connecting Discovery to Sprint Work Without Losing Cadence

The practical challenge is that discovery sessions must coexist with delivery sprints. On a team of five, there is limited slack. The most common collapse pattern is: sprint pressure increases, the weekly interview gets bumped, and by the time the pressure eases, the discovery habit has broken.

Two structural decisions protect the cadence:

Time-box ruthlessly. The interview is 30 minutes, not 60. The synthesis is 15 minutes, not 90. If sessions start running long, cut the post-close section before the retrospective story section. The story is the data. The close is optional.

Treat the interview as a delivery task. Put it on the sprint board with a ticket, not on a separate research calendar. When capacity is allocated explicitly, the interview competes on equal footing with development work. When it lives on a separate track, it is the first thing to be deprioritized.

Teams that maintain this cadence consistently for one quarter typically report what Torres documents in her case studies: the ratio of "features we built that customers didn't use" drops sharply in the second and third quarters, because the team is no longer building from assumption — they are building from evidence accumulated week over week.

For teams in the founder-PM phase, the discovery-to-delivery handoff post covers how to maintain this cadence when the person doing discovery is also the person writing code.

Conclusion

Continuous discovery does not require a research organization. It requires a product trio with 45 minutes per week, a standing participant panel, and the discipline to write synthesis notes before the next sprint planning session. The teams that get this right are not the ones with the most research tooling — they are the ones that treat customer contact as a recurring delivery commitment rather than a project milestone.

The SaasDash experiment sizing and roadmap tools assume that discovery is happening continuously. If your team is not yet running weekly customer interviews, that is the first lever to pull before any experiment or prioritization framework will work as intended. Start with one session next week. Keep it to 30 minutes. Write the four synthesis fields before you close your laptop. Repeat.