Handbook: add Continuous Discovery Interviews page

nuxt/content/handbook/engineering/product/discovery-interviews.md

@@ -0,0 +1,88 @@
+---
+title: "Continuous Discovery Interviews"
+---
+
+# Continuous Discovery Interviews
+
+Product and engineering should talk to customers every week, in short conversations about at least one real, recent experience to figure out answers to specific questions or hypotheses. This page covers why we do it, the two ways an interview happens, and how to run one. It is the practice behind [Gathering evidence](./methodology.md#gathering-evidence).
+
+These interviews have a separate intention from the sales [Discovery Call](/handbook/sales/meetings/discovery/), which qualifies a deal. In an interview we only learn. We do not sell, and we do not promise features.
+
+| Cadence | Length | What we collect | Formats |
+| --- | --- | --- | --- |
+| At least two a week per product team | 5 to 30 minutes | A specific, recent story | The end of a sales call, or a dedicated call |
+
+## What we aim for
+
+- **At least two interviews a week per product team.** At least one a week as the floor. A habit that runs every week is easier to keep than one that starts and stops.
+- **A specific story.** We ask "Tell me about the last time you…", never "Would you use…?". Asked what they want, people describe their ideal selves. A recent story shows what actually happened, and that is what we can design for. It is also the rung-3 evidence an opportunity needs (see [Evidence](./methodology.md#evidence-how-we-know-an-opportunity-is-real)).
+- **The need behind a request.** When a customer asks for a feature, we ask "If you had that, what would it do for you?" and capture the need.
+
+## Why it helps
+
+For product and engineering, stories show what customers do rather than what they say they would do. Regular conversations surface needs nobody thought to ask about, and keep our picture of customers current, which goes out of date the longer we go without talking to them. When our focus changes, the next interviews are already booked.
+
+For sales, a feature request usually arrives without the reason behind it. The story shows what the customer is trying to get done, and sometimes that the product already covers it, which can move a deal forward. Different customers often ask for different features that share one need, so the story can point to one solution that covers several requests. Customers tend to enjoy these conversations, since they are about their own work.
+
+## Who takes part
+
+Product teams interview together. Each person hears different things in the same story, and no one person becomes the only voice of the customer. So engineers join interviews as well as product.
+
+When we join in on sales calls for discovery we should keep the number of people from FlowFuse small, so the call stays a conversation and a sales call stays about the customer and their potential deal first:
+
+- **End of a sales call:** one person from product or engineering joins, next to the rep.
+- **Dedicated call:** at most three of us. One leads the interview, the others listen and ask follow-up questions.
+
+We rotate who joins and who leads. The rest of the team learns from the recording.
+
+## Two ways an interview happens
+
+| | End of a sales call | Dedicated call |
+| --- | --- | --- |
+| Length | 5 to 20 minutes | 20 to 30 minutes |
+| Who's there | The customer, the rep and one of us | The customer and up to three of us |
+| How it starts | The rep spots a trigger and adds us to the call | We invite the customer into our weekly slot |
+| Sales' part | Agree the order of the call with us beforehand, hand over, then listen | Not needed |
+| Our part | One story in the time we get, then the rep hears what we learned | One story |
+
+### At the end of a sales call
+
+The rep spots a trigger and adds us to the call. Calls to flag:
+
+- The customer asks for a feature or a customization.
+- They ask whether we support something specific.
+- They describe a new or unusual use case.
+- A prospect raises a need we are working on right now.
+
+We keep this list current as our focus changes.
+
+Ahead of the call, the rep and whoever joins from product or engineering agree how to run it, including when to hand over. The rep then hands over and listens. For example: "Before we wrap up, my colleague from our product team would like a few minutes to hear about the last time you ran into this." We collect one story in the time we get, and afterwards the rep hears what we learned.
+
+### A dedicated call
+
+We keep a defined weekly slot for these interviews. How we fill it is up to the team, for example through a rep or by reaching out ourselves.
+
+Over time, aim for a mix of people, such as new and long-time users, active and quiet accounts, customers who recently left, prospects, and people like our customers.
+
+## Running the interview
+
+Both formats use the same approach:
+
+1. **Ask for a story.** "Tell me about the last time you…"
+2. **Set the scene.** Where were they, and what were they trying to do?
+3. **Walk the timeline.** "What happened next?" Most of the call goes here.
+4. **Stay specific.** When we hear "usually", we go back to that one time.
+
+Let the customer talk about what matters most to them. Calls are recorded and transcribed in Fathom with the customer's consent (see [Sales Meetings](/handbook/sales/meetings/)), so the interviewer can listen instead of taking notes.
+
+## After the call
+
+- Add the story as evidence on the opportunity it supports on the [FlowFuse/product](https://github.com/FlowFuse/product) board, linking the moment in the Fathom recording.
+- When a fix ships, the customer hears about it, from their rep or from us.
+
+## Further reading
+
+- [Customer interviews: how to recruit, what to ask, and how to synthesize](https://www.producttalk.org/2022/12/customer-interviews/)
+- [Story-based customer interviews uncover much-needed context](https://www.producttalk.org/2024/04/story-based-customer-interviews/)
+- [Automate your recruiting](https://www.producttalk.org/glossary-discovery-automate-your-recruiting/)
+- [Platform teams signal work](https://sujithjay.com/inventing-work#continuous-discovery)

nuxt/content/handbook/engineering/product/index.md

@@ -39,6 +39,7 @@ The **[Product <> Leadership Sync](./methodology.md#product-meetings)** is where
 ## How product works
 
 - [Methodology](./methodology.md)
+- [Continuous Discovery Interviews](./discovery-interviews.md)
 - [Glossary](./glossary.md)
 - [Feedback](./feedback.md)
 - [Product Categories](./verticals.md)

nuxt/content/handbook/engineering/product/methodology.md

@@ -59,7 +59,7 @@ We are honest about which state an opportunity is in rather than dressing up a h
 
 We gather evidence continuously, not in a once-a-quarter research push:
 
-- **Continuous interviews, often with sales.** The strongest opportunities come from specific past stories (rung 3), and sales calls are a steady source of them. We join or review sales conversations rather than running a separate research track, and listen for the moments where a customer recounts a real problem.
+- **Continuous interviews, often with sales.** The strongest opportunities come from specific past stories (rung 3), and sales calls are a steady source of them. We join or review sales conversations rather than running a separate research track, and listen for the moments where a customer recounts a real problem. [Continuous Discovery Interviews](./discovery-interviews.md) describes how we run them.
 - **Fathom for the qualitative record.** Customer calls are recorded in Fathom; we mine the transcripts for rung-3+ stories and link the exact moment as an opportunity's evidence. See [Feedback](./feedback.md) for the full set of channels.
 - **PostHog for behavioural metrics.** What customers actually do (rung 5) comes from product analytics in PostHog: adoption, activation, and the [metrics](./metrics.md) that show whether an objective is moving.