Turn matters that users cannot answer alone into a questionnaire — a Markdown document to be filled out asynchronously by someone, or together in a meeting. The Recipient possesses the knowledge that the user lacks; the questionnaire is designed to extract such knowledge.
Grill the send, not the subject. Only conduct interviews around the send that the user can always answer: who to send it to, and what needs to be returned by the other party. The questions in the Document should then target the gap between what the recipient knows and what the user needs.
-
Who to send it to? Ask about the recipient’s role, expertise, and relationship with the user in one conversation. This will determine the tone of the questionnaire and how much context needs to be included. This step is completed once you know who the recipient is and what knowledge they have that the user does not.
-
What needs to be returned? Ask about the specific decisions or facts that the user cannot resolve on their own and needs this person to provide in one conversation. This step is completed when you have a specific list that clearly defines what the user must ultimately be able to do or decide.
-
Write the questionnaire. Draft questions based on the gaps identified in steps 1–2, and follow the Document structure below. Write the file to
to-questionnaire-<slug>.md
in the current directory (the slug comes from the subject), then report the path. This step is completed when the file exists and every item listed by the user in step 2 is covered by a question.
Document structure
Position the document as a
discovery questionnaire: the user lacks context, while the recipient has it. Arrange questions in descending order of importance — asynchronous communication may only get one chance; when there are more than a few questions, group them under
headings by theme. Use the following template.
<questionnaire-template>
<Questionnaire title>
Purpose: <Why this questionnaire exists and which decision it relates to>
From: <User> — To: <Recipient> — How your answers will be used: <Where the answers will be used>
Context
Use a paragraph to help recipients who are unfamiliar with the user’s thinking establish context. Include enough content to make them take the answers seriously, but don’t write a full page.
How to answer
Specify the deadline and approximate time required. Partial answers and "I don’t know" are also valuable; if unsure, please mark it instead of skipping directly.
<Theme heading>
Use a
section for each theme, with questions arranged in descending order of importance. Each question should contain only one idea; never combine multiple questions; place an answer stub directly below. Add a line
why this matters only if the question might be misunderstood or receive a perfunctory answer.
<question-example>
### What is the expected load when the system goes live?
Why this matters: This determines whether we reserve resources for sudden traffic now or postpone the handling.
</question-example>
Anything else?
Finally, provide a catch-all question: Are there any other things we didn’t ask but should know?
</questionnaire-template>