Conducting Weekly Continuous Customer Interviews

Set up and run story-based customer interviews every week so your product trio always has fresh evidence for discovery decisions.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Continuous customer interviews turn customer contact from an occasional research phase into a standing weekly routine run by the people who build the product. Teresa Torres defines continuous discovery as weekly touch points with customers by the team building the product, where they conduct small research activities in pursuit of a desired outcome, and she describes the weekly rhythm as the continuous part: week over week. Interviewing is the research activity that feeds the rest of the method, so this page focuses on doing it well. For the definition, history and evidence behind the approach, see the Continuous Discovery Habits method page.

Sources differ on how many conversations a week is enough. One review summarizes the benchmark as interviewing at least one customer per week, while a book summary describes a trio that interviews three to five customers per week. A practical reading is to treat one real conversation every week as the floor and add more only when your team can still process what it hears.

The skill has four parts. The first is a fixed weekly cadence: a protected calendar slot, a booking mechanism that fills it without manual chasing, and the whole product trio in attendance. The second is story-based questioning, where you ask a customer to walk through a specific past experience rather than predict what they would do or rate an idea. Torres's teams describe this as conducting regular story-based interviews. The third is the interview snapshot, a one-page summary written right after each call that captures who you spoke with, the story they told and the opportunities it revealed. The fourth is sustaining the habit when access or time is scarce.

The output is not a research report. It is a growing collection of snapshots, each tied to the outcome you are pursuing, that your team pulls from when mapping customer opportunities. You know it is working when every member of the trio can recall a specific customer story from the past week and name a decision it influenced. You know it has gone wrong when interviews happen but nobody can point to anything that changed, or when the slot has quietly been empty for several weeks.

How It Works

The practice rests on three ideas: talk to customers often, let the builders do the talking, and ask about real past behavior.

Frequency matters because customer understanding decays. When contact happens in a separate discovery phase, the team builds for months on a snapshot of customer reality that grows staler each week. Torres frames the weekly touchpoint as the minimum that keeps decisions connected to customers, at a minimum, weekly touch points with customers. Weekly is frequent enough to accumulate evidence steadily and spaced enough to leave time for reflection between sessions. One practitioner guide treats interviews per week per trio, sustained over time as the leading indicator of a healthy practice, which is a useful framing: consistency over months matters more than a burst of interviews in one sprint.

Who interviews matters because secondhand summaries lose detail. Torres's definition puts the research in the hands of the team building the product, not a separate function that hands over findings. When the designer and engineer hear a customer struggle to describe a workaround, they carry that context into design and implementation choices in a way a written summary rarely achieves.

What you ask matters most. People are unreliable at predicting their future behavior and polite when shown an idea, so questions like "would you use this?" produce agreement and little else. A story-based interview instead opens with a prompt such as "Tell me about the last time you did X" and then helps the customer reconstruct what actually happened: the trigger, the steps, the obstacles, the workarounds and how it ended. Each point of friction or unmet desire in that story is a candidate opportunity. Because the story is anchored to a real event, you can trust it more than a generalization.

The interview snapshot closes the loop. Writing a one-page summary within the same day forces the trio to agree on what they heard while memory is fresh, and it turns a conversation into a reusable artifact. A good snapshot names the participant and their context, includes a memorable quote, sketches the story, lists the opportunities heard in the customer's own framing and notes anything worth following up. Over weeks, a stack of snapshots lets you spot patterns that no single interview reveals.

The habit is harder in some settings. One review argues that weekly interviewing can be difficult in regulated industries, enterprise B2B settings with limited user access and organizations under intense delivery pressure. In those contexts the principles hold but the tactics change: shorter conversations, internal proxies who work directly with users, account teams who can open doors, and a willingness to count a genuine story-based conversation as the week's touchpoint even if it is not a formal interview.

Step-by-Step Guide

Step 1: Anchor Interviews to One Outcome

Before recruiting anyone, write down the product outcome your team is currently pursuing and keep it visible to the whole trio. The outcome decides who you talk to, which stories you ask about and how you judge whether an interview was useful. Without it, interviews produce interesting anecdotes that point in every direction. If your team has no clear outcome yet, work through defining product outcomes over outputs first.

Then list the customer behaviors most closely tied to that outcome, because those behaviors become your story prompts.

Pro tip: If several outcomes compete, pick the one where the team has the least evidence about what blocks progress. That is where interviews pay back fastest.

Step 2: Lock a Weekly Slot and Automate Booking

Choose a recurring day and time and block it on the calendars of the product manager, designer and engineer. Treat the slot like any other standing team commitment, so the weekly question becomes who you are talking to, not whether you are talking to anyone. Set up a booking mechanism that fills the slot without someone chasing participants by hand, such as an in-product prompt, a triggered email to customers who just completed a relevant action, or a list of customers who opted in to research. Keep a few backup contacts for no-shows.

The detailed pipeline design lives on automating participant recruitment.

Pro tip: Check on the last working day of each week whether next week's slot already has a confirmed participant. If someone had to scramble to fill it, the booking step is not yet automated.

Step 3: Write Story-Based Questions

Draft a short guide built around one opening prompt: "Tell me about the last time you" followed by the behavior tied to your outcome. Add follow-up prompts that help the customer reconstruct the story, such as what prompted it, what they did first, where they got stuck and what happened next. Leave out questions about the future, ratings of ideas and descriptions of your roadmap. Keep the guide to one page so you can glance at it without breaking eye contact.

Revise it as stories on one topic start repeating and your outcome evolves.

Pro tip: Write prompts in the customer's words, not internal jargon. "How do you hand off work to a teammate?" beats "How do you manage cross-functional workflow allocation?"

Step 4: Run the Interview with the Trio

Give each trio member a role: one leads the conversation, one takes notes and one observes and jots follow-up questions. Rotate roles over time so everyone builds interviewing skill. Get consent to record at the start so the note-taker can focus on observations rather than transcription. Resist pitching solutions or explaining how the product works, because the moment you do, the customer shifts from telling their story to reacting to yours.

End on the time you promised, since running over makes future invitations harder to accept.

Pro tip: If one member cannot attend, have them watch the recording before the snapshot is finalized and add what they notice.

Step 5: Excavate the Story

Once the customer starts a story, your job is to keep them in that specific event rather than drifting into generalizations like "usually I just". When they generalize, gently bring them back: "In that last time, what did you do?" Probe emotions and workarounds, because frustration and improvised fixes often mark the most valuable opportunities. Ask what happened before and after the moment they describe to widen the story.

Note the exact words customers use, since that language helps you frame opportunities from their perspective later.

Step 6: Write the Interview Snapshot

Immediately after the call, the trio spends a short debrief building a one-page snapshot together. Capture the participant's context, a memorable quote, a quick sketch of the story's key steps, the opportunities you heard framed as customer needs or pains, and open questions for future interviews. Write specific observations such as "exported the report to a spreadsheet because the view hid last week's totals" rather than vague impressions such as "reporting is confusing". Store every snapshot in one shared place, tagged with the participant's segment.

These snapshots are the raw material for building opportunity solution trees.

Pro tip: Have each person write their top observations independently before discussing. The engineer often catches something the product manager missed.

Step 7: Sustain the Habit When Access Is Hard

Review the health of the practice regularly: are slots filling, are the right segments represented and are snapshots feeding decisions? If you work in a regulated or enterprise setting where direct access is limited, look for alternate routes such as customer-facing colleagues who can introduce you, user groups, or internal staff who do the same job as your users. Under delivery pressure, shorten the session rather than cancel it, and send one trio member rather than skipping the week. Deliberately rotate segments so you hear from customers who struggled or left, not only the happiest users.

Retire questions that keep yielding the same story and replace them with prompts that dig into the opportunities you have found.

Pro tip: Keep a one-line log per interview: who you talked to, the biggest surprise, and which opportunity it affected. Skimming it monthly shows whether the habit is still producing learning.

Best Practices

• Automate booking so the weekly slot never depends on someone remembering to send invitations. Manual recruiting competes with every urgent task on the calendar and usually loses. The test is simple: next week's slot is filled without anyone on the team doing extra work this week.
• Keep sessions short and focused on one outcome, for example half an hour. Shorter asks are easier for busy customers to accept and force the interviewer to spend time only on the story that matters. Long sessions tend to erode both recruiting and the team's willingness to keep going.
• Have the whole product trio attend whenever possible. Secondhand summaries strip out tone, exact phrasing and the small asides where insights hide. If scheduling is hard, rotate attendance rather than letting interviews become a product-manager-only activity.
• Separate listening from interpreting. During the interview, stay inside the customer's story; save pattern-matching and solution ideas for the snapshot debrief. Mixing the two leads interviewers to steer customers toward existing hypotheses.
• Record observations as specific behavior, not conclusions. Behavioral evidence can be reinterpreted as your understanding grows, while conclusions lock in your current mental model.
• Make the cadence visible, for example a short weekly note to stakeholders naming the segment you talked to and one key story. Visibility builds credibility for the practice and makes it harder to cancel during crunch time.
• Keep discovery interviews separate from sales calls, support sessions and usability tests. Each has a different purpose and conversational stance, and combining them muddies the evidence you collect.

Common Mistakes

• Treating interviews as a project with an end date: Teams run a burst of interviews during a discovery sprint, feel confident and stop, then make months of decisions on aging evidence. Keep the weekly slot on the calendar permanently and let only the questions change as your outcome shifts. If someone says "we already did our interviews", the habit has not formed.
• Asking leading or future-oriented questions: Questions like "Would a dashboard for this help you?" produce polite agreement and no evidence about real behavior. The usual cause is excitement about a solution the team already favors. Rewrite every question to ask about a specific past experience, such as "Tell me about the last time you needed to check this. What did you do?"
• Skipping the snapshot and relying on recordings: Recordings pile up unwatched and notes get filed where nobody reads them. The snapshot debrief is where the trio makes sense of what it heard while memory is fresh. If interviews keep happening but nothing in your opportunity map changes, the missing snapshot is usually the broken link.
• Recruiting only engaged, happy customers: Easy recruiting channels surface people for whom the product already works, which hides the reasons others struggle or leave. Deliberately reserve some slots for churned users, lapsed accounts and prospects who chose something else. Those conversations are harder to book but reveal opportunities your happy users never mention.
• Letting the cadence collapse during busy periods: When a deadline looms, the interview slot feels like the least urgent item and gets dropped. Yet just before shipping is when a customer story is most likely to expose a blind spot. Shorten the session or send one person instead of cancelling, because skipped weeks quickly turn into a dropped habit.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Continuous Discovery Habits

Related Skills

• Building Opportunity Solution Trees
• Defining Product Outcomes Over Outputs
• Mapping and Prioritizing Customer Opportunities
• Running Assumption Tests
• Story Mapping Customer Experiences
• Automating Continuous Research Recruitment
• Comparing Solutions with Compare-and-Contrast Decisions

Sources

• Everyone Can Do Continuous Discovery - Even You!
• Y Oslo 2024: When It Comes to Discovery, Something is
• Continuous Discovery | Definition and Overview
• Leading the Change: How Ellen Juhlin Introduced Discovery Habits
• Continuous Discovery Habits: Discover Products that Create
• Continuous Discovery Habits in 2026: Operationalizing Teresa
• Continuous Discovery Habits by Teresa Torres - Cliff Notes

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.