Continuous interviewing
Run three to five story-based interviews a week, file each as a one-page snapshot, and say what forty of them can change and what they cannot prove.
On this page
Torres's floor is one customer interview a week, every week, run by the people who make the product decisions rather than commissioned from them. This course's PM runs three to five (the role table in PM and FDE: who owns what), about 40 a quarter, because an opportunity tree built on five conversations is a guess with a diagram. The interview's question is a story, never an opinion; its output is one page; and its 40-a-quarter total changes the tree every Friday without ever proving how common anything is.
Weekly, not quarterly
The quarterly version looks rigorous and is not: twenty interviews in week two, a deck in week five, and the tree frozen for the eight weeks in which the customers' situation moves. The weekly version is smaller and never stale. Three to five interviews, thirteen weeks, 40 to 65 conversations, and a tree that is updated the same Friday the fourth snapshot is filed.
The cost that stops teams is recruiting, so recruiting is automated. An in-product prompt to agents who closed 20 or more tickets this week, offering a 25-minute call, yields three or four volunteers a week at a 2% response rate across 200 active agents at a mid-sized tenant. The FDE's tenant contacts are the other channel: the forward-deployed engineer's discovery interviewing on site is the same craft with a different goal, one customer's deployment rather than the product's roadmap, and the two feed one tree.
Story-based questions
The mistake first. "Would you use a tool that drafts replies?" gets a yes, because yes is polite, free and hypothetical. "How much time would that save, about a minute a ticket?" gets "about a minute", because the number was in the question. An hour of that produces a snapshot full of validated claims and no evidence, which is the exercise the interview that proved nothing.
The fix is to ask for a story. "Tell me about the last time the queue was still full at 6." Then follow the story and nothing else: what was in the queue, what did you open first, how long did that one take, what happened at 7. The story has numbers in it because the event had numbers in it: 130 tickets, mostly refunds and password resets, three minutes on the one she remembers, two carried to the next morning because the customer was in another time zone. Those are the figures that became the job in jobs to be done; none of them came from a question with a number in it.
Four rules keep a question a story. Past tense, one specific instance, no product in the sentence, and silence after the answer until the customer fills it. A useful interview of 25 minutes has about six questions, and four of them are "and then what did you do".
The one-page snapshot
Each interview becomes one page, written within the hour, with a fixed shape: who (role, tenant, tickets a day), the story in three lines, the opportunities heard in the customer's words, one quote, and what surprised you. Keep the page to that shape, because the snapshots are filed, and filing is what turns 40 interviews into evidence rather than 40 anecdotes.
Filing means counting. When the eleventh snapshot of the month names the slow repeat reply, the opportunity on the tree reads "11 of 16", and the count is what the opportunity solution tree carries from one week to the next. A snapshot that is not filed against the tree was a pleasant conversation.
The weekly hand-off
The PM's interviews are one of three inputs that meet on Friday. The FDE sends a field report with the failures seen at a tenant that week; the PM adds those failures to the golden set and runs the eval; research says whether the failures are a capability boundary or missing context; the PM updates the tree and makes one decision. Module 0 states the cadence as one field report, one eval run, one decision, and the sequence below is what a week of it looks like.
The point of the diagram is who owns what. The FDE owns the failures and the tenant; research owns the capability boundary; the PM owns the tree, the golden set, the eval run and the decision. Nothing in the sequence waits on a quarterly deck.
What 40 interviews change, and what they cannot prove
They change the tree. A quarter ago it carried six opportunities; today four, two of them new, and the counts have reordered them. They change the words: the opportunity that was "agents are slow" is now "replies to repeat questions take as long as new ones", which is a sentence a solution can be tested against. They show which tenants share a pain, because each snapshot names its tenant.
They cannot prove prevalence. Forty volunteers from nine tenants are not a sample of 12,000 agents, so "26 of 40" is never "65% of agents". Say the count and the spread — "26 of 40, across 7 of 9 tenants" — and get the frequency from the log: 560 tickets a day at one tenant says how often a repeat question arrives, which no interview can. They cannot prove a solution works; that is the prototype and then the eval, in the one-day prototype and evals as the feature's test suite. And they cannot prove willingness to pay. "We'd pay anything for this" is a quote, filed as a hypothetical; the follow-up is "what did you last pay for, and from which budget line", and the answer to that is evidence.
The line to hold is this: interviews find the opportunities and their words; logs give the rates; prototypes and evals give the results. A tree whose rates came from interviews has the shape of evidence and none of the content.
In an interview
What is being tested is whether you can tell an interview from a survey of opinions, and whether you know what 40 interviews cannot prove. Describe the cadence with its numbers — "four a week, story questions, one-page snapshots, filed against the tree on Friday" — and then volunteer the limit: "that gives me the opportunities and the counts; the rates come from the ticket log, and the prototype tells me whether the solution works."
The mistake that loses points is quoting an interview count as a market share: "65% of agents want drafting" from 26 self-selected volunteers. The second is a question with the answer inside it, which an interviewer will spot in the first sentence of your example.
Check yourself
1. You can run three interviews this week or send a survey to 2,000 agents. Which, for a new tree?
Interviews. A survey measures what you already know to ask, and a new tree has no opportunities to ask about yet. The survey comes after the first dozen interviews, to size the top three opportunities across the 2,000: at a 10% response rate that is 200 answers, enough to rank three options, and still not enough to tell you a fourth exists.
2. Thirty-one of this quarter's forty interviews mention the escalation wait. Is that the top branch?
Not by count alone. Convert it to the outcome's unit: about 47 escalations a day at the tenant × 2 minutes saved by a drafted summary = 94 agent-minutes, against 560 for the drafted reply that 26 of 40 mentioned. The count says the pain is real and widely shared; the arithmetic puts it behind the drafted reply and behind the macro fix's 140 minutes. It stays on the tree, third.
3. The lead says "we'd pay anything for this." What goes in the snapshot?
The quote, marked as a hypothetical, and then the follow-up you asked: "What did you last buy for the team, and which budget did it come from?" If the answer is "a $3,000-a-year scheduling tool, from my own line", that is evidence about price and about who signs. The first sentence is enthusiasm; the second is a number.