Continuous discovery habits

This is the exact file agents read, including the credit header and licence notice. Save it as continuous-discovery-habits/SKILL.md.

---
name: continuous-discovery-habits
description: Set up and run a weekly product discovery rhythm instead of a one-off research sprint, following Teresa Torres and Marty Cagan. Carries the real rules: at least weekly customer touchpoints by the team building the product in service of one outcome; the product trio attends, with a fallback when there is no trio; automated recruiting with fallbacks for low-traffic and B2B contexts; interview snapshots; a current opportunity solution tree; weekly assumption tests; and a decision step that acts on what was learnt, measured by whether the cadence changes decisions. Use it when someone says continuous discovery, weekly customer interviews, set up a discovery process, product trio, keep discovery going, or tie research to the roadmap. Do NOT use it to run the interviews (see customer-interviews), to choose which opportunity to pursue (see opportunity-solution-trees), to rank or test assumptions (see assumption-mapping, concept-testing), or to run a one-off study with no ongoing cadence.
licence: CC BY 4.0. Free to use and adapt with credit to Afeez Adebayo, linking afeezadebayo.com, https://www.linkedin.com/in/afeez-adebayo/ and the skill's download page at https://afeezadebayo.com/skills-md/product-management/product-discovery/continuous-discovery-habits/.
---

# Continuous discovery habits

Most teams do discovery as a project: a burst of research at the start, a report, then months of building with no further contact until the next big study. By then the market has moved and the report is a historical document. Continuous discovery replaces that with a rhythm. The team that builds the product talks to customers every week, in small activities, in service of a clear outcome, and lets what it learns shape what it builds next. The point is not more research; it is research close enough to the decisions that it actually changes them.

The practice has a canonical source and a clear bar. Teresa Torres defines continuous discovery as, at a minimum, weekly touchpoints with customers by the team building the product, who run small research activities in pursuit of a desired product outcome. Marty Cagan puts the strongest teams at twelve to fifteen discovery iterations a week. This skill makes an AI agent set up that rhythm and keep it running: it fixes the outcome, forms the trio or a workable substitute, automates recruiting so interviews do not depend on luck, runs the weekly loop of interview, snapshot, opportunity tree and assumption test, and checks that the cadence is changing decisions rather than just filling calendars. It does not run the interviews, choose the opportunity or rank the assumptions; it hands each of those to the skill that owns it. It builds and holds the habit.

## When to use this skill, and when not to

Use it when someone wants to start continuous discovery, set up a weekly discovery process or cadence, establish a product trio, keep discovery going between big projects, fix a team that researches in bursts, or tie customer research to the roadmap so the two stop drifting apart. Use it when the problem is the operating rhythm: who talks to customers, how often, how the learning reaches decisions, and how to keep it alive when the quarter gets busy.

Do not use it to plan and run the interviews themselves, write the guide or synthesise notes; that is customer-interviews, which this skill calls each week. Do not use it to choose which opportunity to pursue from the tree; that is opportunity-solution-trees. Do not use it to rank the assumptions behind a solution or design the experiment; that is assumption-mapping and then concept-testing or usability-testing. And do not use it for a one-off study with a fixed end: if there is no ongoing cadence to build, this is the wrong skill, and a single piece of research is better served by customer-interviews alone.

## What the agent needs from you before starting

Ask for these before setting up the rhythm. Do not assume them.

1. The product outcome discovery will serve. One metric the team can influence by changing the product, stated as a behaviour change, for example "more new teams reach their second project in the first week", not "ship the new inbox". If there is no outcome, settle that first; a cadence with no outcome drifts into activity for its own sake.
2. Who will do the discovery. The product trio (product manager, designer, engineer) ideally, or whoever will act on the research if there is no full trio. Name the people, because the rule below is that the people who decide must hear customers first-hand.
3. How you can reach customers, and how often realistically. Current traffic or account base, whether you can prompt users in-product, whether sales or support can introduce customers, and any constraints (enterprise gatekeepers, regulated users, low volume).
4. The current state. Whether discovery happens now, how often, and what breaks it (no time, no recruits, research that no one acts on). This decides which habit to build first.
5. Constraints. Time per person per week, tools available, and any privacy or compliance rules on contacting customers.

If the outcome is missing or no one will own the weekly contact, stop and ask. A cadence with no owner and no outcome is the failure this skill exists to prevent.

## How to set up and run the rhythm, step by step

Build the habit one piece at a time, in this order. Do not try to start all of it in week one; Torres is explicit that the habits are adopted one at a time, and a team that attempts everything at once usually keeps none of it.

### Step 1. Fix one product outcome

Write the single outcome discovery serves this quarter. It must be a behaviour the team can move through the product, measurable, and reviewed no more than quarterly so the tree below stays stable. If the team is handed an output ("build the inbox"), translate it into the outcome it is meant to produce ("fewer client decisions lost") and confirm that with whoever owns the roadmap. Everything downstream hangs off this outcome.

### Step 2. Form the trio, or a workable substitute

The product trio is a product manager, a designer and an engineer who attend interviews together, so they build from the same evidence rather than arguing from opinion. Set that up where you can. Where you cannot, apply the rule that makes discovery stick: whoever will act on the research must hear it first-hand. For a solo PM or a two-person team, that means at least the person who decides and the person who builds join the calls, or, at the very minimum, one person runs the calls and shares the recordings and snapshots the same week. Outsourcing all interviews to a researcher who then reports back breaks this rule and is the quiet way continuous discovery dies.

### Step 3. Automate recruiting so interviews never depend on a scramble

The single most common reason weekly interviews stop is that finding someone to talk to each week is manual and slow. Remove that. Set up a standing way to recruit:

- In-product: a small prompt or pop-up that invites a slice of users to book a slot, linked to a scheduling tool with the team's real availability. This is the strongest option because it recruits people in context, continuously.
- Calendar: a recurring weekly hold the whole trio keeps, so the slot exists before the recruit does.
- A target: aim for at least one interview every week as the floor, and build towards several; treat a week with zero as an incident to fix, not a normal outcome.

Fallbacks when in-product recruiting is weak:

- Low traffic: recruit from support tickets and recent sign-ups, or run a small standing customer panel you can call on.
- B2B and enterprise: ask sales and customer success for warm introductions on a standing basis, and build a short list of friendly accounts who agree to regular short calls.
- Regulated or hard-to-reach users: use a compliant third-party panel, or shorten the ask to a fifteen-minute call so consent and scheduling are lighter.

The rule: never let "we could not find anyone" cancel the habit. Lower the bar (a shorter call, a different segment, an existing customer) before you skip a week.

### Step 4. Run the weekly interview

Each week, hold at least one customer conversation, with the trio present. Hand the guide, the screener and the conversation itself to the customer-interviews skill, which carries the method: talk about past behaviour, not hypotheticals, and open with "tell me about the last time you...". This skill's job is to make sure the conversation happens every week and that the right people are in the room, not to design the questions.

### Step 5. Write one interview snapshot

Straight after each interview, capture a one-page snapshot: who you spoke to and their context, the key quotes, what surprised you, and the opportunities (unmet needs, pains, desires) you heard. Share the snapshot with stakeholders instead of raw recordings or messy notes. The snapshot is what keeps the learning usable a month later and what lets people who were not in the room follow the reasoning.

### Step 6. Keep the opportunity solution tree current

Maintain a living opportunity solution tree: the outcome at the top, opportunities (unmet customer needs) beneath it, candidate solutions beneath those, and assumption tests beneath those. After each interview, add or adjust the opportunities you heard. The tree is how the week's conversations add up to a map of where the team could act. Deciding which opportunity to pursue is a separate skill: hand that choice to opportunity-solution-trees, which takes this tree as its input.

### Step 7. Test assumptions each week

Alongside interviewing, keep a small assumption test running on a candidate solution, so discovery evaluates solutions as well as finding opportunities. Rank the assumptions with the assumption-mapping skill, and run the chosen test with concept-testing or usability-testing. One small test a week, on the riskiest belief, is the target; this skill makes sure a test is always in flight, not which test it is.

### Step 8. Decide and show the work

Hold a short weekly trio decision: given this week's snapshots, tree changes and test results, what are we doing differently? Record the decision and the evidence behind it. Then show the work, snapshots, the tree and assumption maps, to stakeholders, so they see the reasoning and not just the conclusion. The decision step is what separates continuous discovery from a well-attended set of interviews that change nothing.

### Step 9. Measure the habit and its effect

Track two things. First, the habit itself with a maturity check (below): is the cadence actually weekly, does the trio attend, is recruiting automated, is the tree current, are assumptions being tested, do decisions follow? Second, and more important, whether the cadence is changing decisions: count opportunities added per week, assumptions tested per week, and decisions that trace to evidence rather than opinion. The rule: if the cadence runs but the roadmap still ignores it, the broken habit is the decision step in step 8, not the interview count. Fix that before adding more interviews.

### Step 10. Add one habit at a time

Sequence the build so the team keeps it: weekly interview first, then the snapshot, then the tree, then the weekly assumption test, then the decision ritual. Add the next habit only once the previous one is sticking. A team doing one real interview a week with a snapshot and a decision beats a team that drew a beautiful tree once and never interviewed again.

## Worked example

A two-person team, a product manager and a designer with no dedicated engineer, wants to start continuous discovery for the outcome "more new teams reach their second project in their first week".

Week one: the agent helps them fix the outcome and set up recruiting. It drafts an in-product prompt that invites new teams to book a fifteen-minute call, wires it to a scheduling link, and puts a recurring Thursday hold on both calendars. Because there is no engineer, it applies the substitute rule: both of them, the decider and the builder of the design, join every call, and they agree to loop their lead engineer in with the snapshot each week.

Week two: they run their first interview (handed to customer-interviews for the guide), and the agent produces the snapshot template and the opportunity solution tree skeleton with the outcome at the top. Two opportunities go on the tree from the first call.

Weeks three and four: a second and third interview happen, the tree grows, and the agent helps them pick the riskiest assumption behind their first candidate solution (ranked with assumption-mapping) and run a small test (handed to concept-testing). At the Thursday decision, they drop one opportunity that no one actually raised and reshape the onboarding checklist around the one they heard twice. The agent runs the maturity check: cadence weekly, recruiting automated, trio substitute in place, tree current, one test in flight, decisions recorded. The habit is holding, and the agent notes the next habit to add is a lighter weekly assumption test, not more interviews.

## Templates you can use verbatim

Weekly discovery cadence (one week):

```
Mon  Confirm this week's interview is booked (recruiting prompt live, slot held)
Tue  Prep: hand the guide to customer-interviews; trio confirms who attends
Wed  Interview (trio present) -> write the snapshot same day
Thu  Trio decision (30 min): snapshots + tree changes + test result -> what changes?
      Update the opportunity solution tree; start/continue one assumption test
Fri  Share snapshots + tree with stakeholders; check next week's recruit is in the pipe
Floor: at least 1 interview and 1 assumption test in flight every week. A zero week is an incident.
```

Interview snapshot (one page per interview):

```
Who / context: <role, segment, situation; anonymised label>
Date / who attended: <date; which trio members>
Key quotes: <3-5 verbatim quotes, each tied to a behaviour>
Surprises: <what you did not expect>
Opportunities heard: <unmet needs / pains / desires -> add to the tree>
Open questions: <what to probe next time>
```

Opportunity solution tree skeleton:

```
OUTCOME  (the behaviour change this quarter)
  |-- Opportunity (unmet need heard in interviews)
  |      |-- Candidate solution
  |      |      |-- Assumption to test (rank with assumption-mapping)
  |-- Opportunity ...
Rule: opportunities come from interviews; choosing which to pursue = opportunity-solution-trees.
```

Recruiting prompt (in-product, adapt the copy):

```
"Got 15 minutes to help shape <product>? We're talking to a few customers this week.
Pick a time: <scheduling link>." (Honest, no incentive promised you cannot keep; one segment at a time.)
```

Maturity self-check (score each yes = 1; read the bands):

```
[ ] At least one customer touchpoint happened every week this month
[ ] The people who decide and build attended, not only a researcher
[ ] Recruiting is automated (no weekly manual scramble)
[ ] A snapshot exists for each interview and is shared
[ ] The opportunity solution tree is current
[ ] At least one assumption test is in flight
[ ] A weekly decision records what changed and why
Bands: 6-7 continuous; 3-5 ad hoc, fix the weakest habit next; 0-2 project-based, start with the weekly interview.
```

## Common mistakes and how to avoid them

1. Treating discovery as a project, not a habit. A big research sprint, then months of silence. Spot it when the last customer conversation was weeks ago. Fix by booking a standing weekly slot and automating recruiting so the next conversation is always in the pipe.
2. The deciders never hear customers. Interviews are outsourced to a researcher who reports back, so the people who build act on second-hand summaries. Spot it when the PM or engineer cannot recall a recent call. Fix by putting the trio, or the decider and builder, in the room every week.
3. Batching instead of flowing. Ten interviews in one week, then nothing for a month. Spot it in the calendar. Fix by spreading contact to a steady weekly minimum, which keeps learning close to decisions.
4. Insight with no decision cadence. Snapshots and a tree pile up, but the roadmap ignores them. Spot it when nothing on the roadmap traces to a recent interview. Fix by holding the weekly trio decision and recording what changed because of what was learnt.
5. Vanity cadence. Interviews happen every week, but nothing changes, so the ritual becomes theatre. Spot it when the maturity check is green but decisions still come from opinion. Fix by measuring decisions that trace to evidence, and by repairing the decision step before adding more interviews.

## Quality bar: check the output against this before handing it over

- There is one product outcome, stated as a behaviour change the team can influence, and the cadence serves it.
- An owner is named for the weekly customer contact, and the people who decide and build will hear customers first-hand, trio or substitute.
- Recruiting is automated with a stated weekly floor and a named fallback for the team's context (low traffic, B2B, regulated).
- The weekly loop is defined end to end: interview, snapshot, tree update, assumption test, decision.
- The interview, the opportunity choice, and the assumption ranking and test are each handed to the owning skill by name, not duplicated here.
- The habit is measured two ways: a maturity check and leading indicators that decisions trace to evidence.
- The build is sequenced one habit at a time, with the next habit named.
- Nothing is invented: no fabricated interview counts, opportunities or results; where discovery is not happening yet, the plan says where to start.

## Guardrails

- Recruiting reaches real customers. An in-product prompt, an email to a panel or a sales introduction all contact people. Produce the recruiting copy and plan as a draft and get explicit confirmation before anything goes live, and never promise an incentive the team has not agreed.
- No disguised selling. A discovery interview is for learning, not a sales call in disguise. Say so in recruiting, keep the two separate, and do not let a conversation booked as research turn into a pitch.
- Protect personal data. Snapshots, recordings and recruiting lists hold names, employers and accounts. Use anonymised labels in snapshots, keep recordings and raw notes where they already live with the customer's consent, and do not paste contact details into prompts or third-party tools.
- Mind the cost and the calendar. The cadence spends the trio's time every week and a little of customers' time. Keep interviews short, reuse one recruiting pipeline, and reserve expensive tests for important, low-evidence assumptions; the habit should be sustainable, not heroic.
- Stay in scope. This skill sets up and runs the rhythm. It does not run the interviews (customer-interviews), choose the opportunity (opportunity-solution-trees) or rank and test assumptions (assumption-mapping, concept-testing, usability-testing). It is an operating model, not a guarantee; a human owns the roadmap and every customer contact.

## Tool-specific appendix

The rhythm is tool-agnostic, but a few tools make it stick. Use a scheduling tool (Calendly, SavvyCal or similar) wired to an in-product prompt so recruiting runs itself; keep a recurring calendar hold for the trio. Keep snapshots in a shared doc or Notion, one page each, searchable later. Keep the opportunity solution tree in a whiteboard tool (Miro, FigJam) or a dedicated discovery tool so the whole trio can edit it. Store recordings and consent where your organisation already keeps customer data, not in ad hoc folders. Whatever the tools, the rules in the steps above do not change: a weekly touchpoint by the people who decide, a snapshot each, a current tree, a test in flight, and a decision that acts on what was learnt.

## Sources

- Teresa Torres, "Continuous Discovery Habits", and Product Talk, "Getting started with discovery": continuous discovery as at least weekly touchpoints with customers by the team building the product in pursuit of a desired outcome; the product trio; the opportunity solution tree; interview snapshots; automating recruiting; past-behaviour questions; and adopting the habits one at a time. Last verified 13 November 2026.
- Teresa Torres, Product Talk, "Discovering solutions": aligning on a solution before surfacing assumptions, story-mapping to find assumptions, defining success before testing, and Marty Cagan's figure that the best teams complete twelve to fifteen discovery iterations every week. Last verified 13 November 2026.
- Marty Cagan, Silicon Valley Product Group, "Product Risk Taxonomies": the four big risks (value, usability, feasibility, viability) that weekly discovery exists to address. Last verified 13 November 2026.
- Existing skills reviewed for structure and gaps: menkesu "continuous-discovery" (frameworks and triggers, but no procedural runbook, recruiting method or low-resource path), wondelai "continuous-discovery" (a strong maturity diagnostic and six components, but assumes a dedicated trio, keeps templates in linked files, and does not measure whether the cadence changes decisions). This skill adds the week-by-week runbook, the trio substitute, the recruiting fallbacks, inline templates, and the decision-impact measure. Last verified 13 November 2026.

---
1.0.0, 13 November 2026: first release. Use, adapt and share this skill under CC BY 4.0: credit Afeez Adebayo, link afeezadebayo.com and the skill's download page. This is an operating model, not a substitute for talking to your own customers.