I had a product call on the calendar to spec two new features with a user. The old way to run that call is to open a doc, type questions, type answers, type follow-ups, and come out the other end with four pages of notes that you still have to translate into a spec.
The new way, which I tried this week, is a quiz.
Not a quiz in a Google Form. A single-page HTML file, four sections, thirty-one questions, every answer a tap on a chip. No open-ended “what do you think.” No “walk me through your workflow.” No note-taking. Just tap, tap, tap, done. By the end of the call, the spec writes itself, because the spec is the quiz.
If your discovery doc is a page of prose, you ran a therapy session, not a product call.
— A rule I came up with after my fourth notes-translation marathon
The shape of a question
Every question in the kit has four parts, and the parts matter. Here is the schema I wrote for the whole thing:
The q is the question. The opts are the multiple-choice chips — short enough to be tappable on a phone, specific enough that picking one is a real commitment. The why is a quoted scrap from a previous call or message that triggered the question — I’ll come back to why that line is the most important field. And the rec is my own recommended answer, pre-selected, which the user can agree with in silence or push back on in one tap.
Four fields. That’s the whole thing. There is no “describe your pain in your own words.”
Why pre-picking the answer is the move
The field that quietly makes this work is rec.
If I don’t pre-pick an answer, every chip is equally weighted and the user has to re-derive my product thinking in real time, out loud. That is slow and bad. More importantly, it hides what I actually think, which means I don’t get tested — the user just picks something plausible and we both move on with no information gained.
If I pre-pick an answer, I am declaring a hypothesis. Something like “I think tips should default to being figured on the trip price, not the trip price plus the surcharge.” That is a position. The user either confirms it in a nod, or taps a different chip, or taps the chip plus a different one and says “both — depends on the state.” All three outcomes give me more signal than any amount of “what do you think.”
The real benefit is upstream. Writing the pre-picks forced me, before the call, to decide where I had an opinion and where I didn’t. Any question with no rec was a question where I was fishing, and I had to notice that about myself before the call started.
The “why” line is the most important field
Every question has an optional why that quotes a prior message, email, or call. Not paraphrased — quoted.
“Can I add a tip to the balance at the end of the trip?”
That is a line from a message the user sent me a few weeks ago. I pasted it, verbatim, under the first tipping question. When the user got to that question on the live call, they saw their own words, in italics, under my question. They did not have to retrieve the context themselves. They did not have to wonder if I was listening the first time. The signal “I heard you” was embedded in the UI.
That is the whole trick to running these calls without burning trust. The user has been telling me things for months. If I show up to a discovery call and ask them to re-explain, I am punishing them for having talked to me earlier. The quiz is a receipt.
The structure that forced the thinking
The quiz has four sections — three feature-domain sections and one priorities section — and the sections matter more than any individual question.
The last section is the one that changes the character of the call. “Which should we build first — A, B, or both together?” “When do you need A working — this month, by Thanksgiving, before spring, or no rush?” Those are not technical questions. They are commitments. You can only ask them after the user has looked at every option in A and B and knows what they’re trading off. That is impossible to pull off in open-ended discovery — the user commits to a priority before they’ve seen the full shape of the choice.
In a chip-tap quiz, by the time they get to Priorities, they have already seen every design decision. The commitment is cheap. They tap “A, ASAP” and I know what to build on Monday.
The structural “if we only build one first”
Inside each feature section there is one question that always does more work than the rest:
If we only build ONE tip spot first, which one?
This question comes right after a question that lists every possible tip spot and asks the user to pick the ones that should exist eventually. The eventual list is almost always long — six, seven options. Then I immediately follow with “pick one.” The one they pick is V1. The ones they didn’t pick are backlog. The spec writes itself from a single-chip tap.
I steal that pattern from the Pareto principle, badly. It is less principled than that. It is just: the second you have a list, ask which one matters first, before anyone has time to get attached.
What the call actually looks like
Thirty-one questions, chip-tap only. Average tap time is maybe five seconds per question when the user already has the context from the why line and the pre-pick. Call total: about twelve minutes of actual answering, interleaved with twenty minutes of “well, except when…” which is where the real information lives.
The “except when” moments go in the optional note field under each question. Not a free-form notes doc — a note tied to the specific question that triggered it. By the end of the call, every note is already in the right section of the eventual spec.
The uncomfortable part
The uncomfortable part of this format is that it feels, writing it, like I’m leading the witness. I am. I’m declaring, in advance, where I think the answer is, and asking them to disagree or confirm. That is leading. It is also the only honest way to run a product call where I have months of context on the user and they have months of context on their business.
The alternative — “tell me your workflow from the top” — pretends neither of us has done the reading. We both have. The quiz is me putting my reading on the table and asking them to grade it.
Thirty-one taps. Twelve minutes of answers. A spec that already exists before the call ends.
I don’t think I’m going back to open-ended discovery.