How SaaS Teams Can Run Continuous User Research

What continuous user research means for a SaaS team

Product Talk defines continuous discovery as frequent customer touchpoints by the team building the product, using small research activities in pursuit of a desired outcome. The useful contrast is with isolated research projects. Continuous does not mean interviewing people all day, and a weekly touchpoint is a practical starting rhythm rather than a law for every team.

Official GOV.UK user research guidance similarly recommends small research batches in every iteration rather than large studies at development's edges. For a SaaS team, that can mean one current decision, a named research owner, and regular involvement from product, design, and engineering.

A repeatable process helps teams handle routine questions consistently, but it does not replace research expertise. Complex, sensitive, inclusive, or high-risk work may still need a specialist researcher. Palette's continuous AI user research capabilities can support the workflow while the team remains responsible for its questions, review, and decisions.

Start with a decision, not a method

Starting with a preferred method can produce interesting material that does not resolve the decision. Name the decision and the uncertainty that makes it difficult, then turn that uncertainty into a neutral question. GOV.UK's research planning guidance recommends prioritizing research questions and choosing activities that provide reliable answers with proportionate time, effort, and cost.

1. Write the decision. What will the team choose after learning?
2. Name the uncertainty. What important fact or behavior is unclear?
3. Frame a neutral question. Avoid wording that assumes the preferred solution is right.
4. Identify the relevant users. Recruit people whose role and experience match the decision.
5. Define useful evidence. Decide what could reinforce, weaken, or redirect the current view.

Suppose a team is deciding whether to remove an account requirement from checkout. Asking whether people like guest checkout points toward an answer. A better question is how the requirement affects task completion and expectations. That can guide participant selection, tasks, follow-up questions, and the final decision.

Match the method to the question

Research methods answer different kinds of questions. The Nielsen Norman Group method framework distinguishes what people say from what they do, and qualitative explanations from quantitative measurement. Using multiple methods can expose different parts of a problem, but collecting more sources does not automatically make an interpretation correct.

• Interviews. Use them to understand experiences, motivations, needs, language, and mental models. They report what participants remember and believe, so do not treat them as direct observation of usability.
• Usability studies. Use realistic tasks when the question concerns how a design performs. Observe behavior, listen for feedback, and ask neutral follow-up questions.
• Product sessions and analytics. Use behavioral data to find patterns, locate friction, and estimate magnitude. Follow with qualitative work to explore context and possible explanations.
• Microstudies. Use a narrow, contextual question inside the product when timing and product state matter.
• Support and connected tools. Treat support threads, sales notes, and other incoming feedback as signals that can generate questions, not as conclusions on their own.

Palette can bring AI-moderated interviews, usability studies, microstudies, connected feedback, and session evidence into the same research process. Teams considering automation should also understand when AI-moderated interviews produce good evidence. Method quality still depends on the question, participant fit, study design, and review of the underlying evidence.

Build participant access before you need it

Recruitment becomes a bottleneck when every study starts from an empty contact list. Build an opted-in participant pool and record only what is needed to match people to future questions. For B2B SaaS, the buyer, administrator, internal champion, and daily user may experience the same product differently.

GOV.UK recruitment guidance recommends recruiting actual or likely users, defining criteria around the question, protecting participant privacy, and avoiding repeated reliance on the same people. Its informed consent guidance also calls for participants to understand the purpose, data collected, recording, use of results, retention, and their ability to withdraw.

There is no universal sample size for every question. Choose participants, method, and depth according to the decision, the diversity of relevant users, and the consequences of being wrong.

Create a weekly research loop the team can sustain

A lightweight cadence makes research visible without turning it into a parallel bureaucracy. The exact days can move, but the handoffs should remain clear.

1. Early week: review current product decisions and select one high-priority research question.
2. Midweek: collect the smallest useful set of interviews, task observations, contextual responses, or existing signals.
3. End of week: review the sources together and decide whether to act, learn more, or hold.
4. Every few weeks: review accumulated findings for patterns, contradictions, and assumptions that have gone stale.

Give one person responsibility for the loop, but bring the people making the product into observation and analysis. A team should not learn about users only through a summary. Palette can let a team commission a study from Slack and retrieve supporting insight through a connected coding client. Those shortcuts are useful when they keep evidence close to the work, not when they hide source material.

Keep evidence traceable and reusable

A research repository is useful only if it preserves the path from source to decision. Store enough context for someone outside the original study to understand what was observed, how it was interpreted, and where the limits are.

1. Source evidence: the interview response, session event, usability recording, survey response, or support thread.
2. Observation: a factual account of what happened, kept separate from explanation.
3. Finding: an interpretation of a pattern, bounded by the participants, method, and available evidence.
4. Product decision: the choice the team made, including rationale, tradeoffs, and unresolved questions.

Keep the source, date, participant segment, research question, and important limitations with each finding. GitLab describes its research library as a central hub that makes prior research accessible, while retaining people as the final judges of what is good enough to act on.

Palette's evidence graph keeps insights connected to their sources. AI can help organize, group, and retrieve material, but people should inspect the evidence and decide what it means. The same separation matters when prioritizing customer feedback using evidence. Traceability makes a decision reviewable. It does not guarantee that the decision is right.

Connect research to what ships

Each finding should end in one of three working states: act now, learn next, or hold. This prevents a repository from becoming a collection of observations that never affect the product. It also prevents every feature request from moving directly into delivery. Research identifies problems, needs, behaviors, and constraints; the team still has to choose and shape a response.

Return to the account-gate example. Support messages and session evidence suggest friction, so the team runs a focused usability study. If the evidence supports the interpretation, the team may shape a guest-checkout proposal, record the alternatives it rejected, and test the proposed workflow. After release, it can look for new evidence about whether the original problem changed. This is an illustrative workflow, not a customer case study.

Palette is designed to carry evidence into feature proposals and turn findings into build-ready specifications, then compare user signals after a feature ships. The useful principle is broader than any tool: preserve the connection between the original question, the evidence, the decision, and the outcome, while keeping human review at the points where judgment matters.

A 30-day continuous research starter plan

1. Week 1: create a prioritized backlog of research questions, choose an owner, define the participant roles that matter, and audit research, support, and behavioral evidence you already have.
2. Week 2: run one narrow research round tied to a current decision. Keep the question neutral, recruit relevant users, and preserve consent and source context.
3. Week 3: synthesize observations into bounded findings, link each finding to its sources, and make an explicit act, learn, or hold decision. Attach that decision to the relevant product work.
4. Week 4: run a follow-up round where uncertainty remains, review what slowed the loop, and choose a cadence the team can maintain without lowering research quality.

At the end of the month, judge the practice by whether important product decisions can point to recent, relevant, traceable evidence, not by the number of sessions completed. Keep the loop small enough to survive a busy release cycle and rigorous enough to reveal when the team's preferred answer is weak.

If you want to explore a system that connects recurring research, source-backed insight, and product development, you can join the Palette waitlist. The operating principle remains the same with or without a platform: keep fresh evidence close to the decisions that shape what ships.