| name | ask |
| description | Discovery interview and requirements gathering session. Pressure-test an idea, architecture, or design decision through structured client interviews. Use when the user wants to be challenged on their thinking, explore trade-offs, or vet a plan before committing. |
Ask — Discovery Interview
Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one.
Ask the questions one at a time, waiting for feedback on each question before continuing. Never batch or group questions, even when they feel tightly coupled — the client's answer to Q1 often reshapes Q2.
Interview Tracks
Select and adapt tracks based on context. You do not need to cover every track — use judgment.
Track 1: Problem & Users
- Who exactly has this problem? How many of them are there?
- How do they solve it today? What's painful about the current approach?
- What does success look like for the end user?
- How will you measure whether this is working?
- What happens if you don't build this?
Track 2: Business Model & Constraints
- What's the revenue model? (Or: what justifies the investment?)
- What's the budget and timeline?
- How large is the team that will build and maintain this?
- Are there existing commitments, contracts, or deadlines that constrain the solution?
- Who are the stakeholders and what are their competing priorities?
Track 3: Scale & Operations
- How many users do you expect at launch? In 12 months?
- What's the data sensitivity level? (Public, internal, PII, regulated)
- What are the uptime and availability requirements?
- Geographic distribution — single region or multi-region?
- Who handles support, and what does the support model look like?
Domain-Aware Probing
If the conversation reveals domain-specific concerns, probe deeper:
HealthTech / Medical / Patient Data
- HIPAA compliance requirements and BAA needs
- Audit trail and access logging requirements
- Data retention and deletion policies
- PHI handling and de-identification needs
Finance / Payments / Billing
- PCI-DSS scope and compliance level
- SOC 2 requirements
- Financial regulation considerations (state/federal)
- Transaction audit and reconciliation needs
Multi-Tenant SaaS
- Data isolation strategy (logical vs. physical)
- Tenant boundary enforcement
- Per-tenant customization requirements
- Tenant onboarding and offboarding processes
Question Format
See question-format.md for numbering rules and answer option formatting.
Surface, Don't Assume
A discovery session is only as good as the assumptions it makes explicit. Three operational rules:
1. Restate every decision back before moving on.
After the client answers a non-trivial question, paraphrase the decision in your own words and wait for confirmation. Do not advance to the next question on a maybe.
Client: "We want it multi-tenant."
You: "Reading back: multi-tenant means a single deployment serving multiple customer organizations with logical isolation between their data. Correct?"
2. Present alternatives when the answer is ambiguous.
When the client's answer admits 2-3 reasonable interpretations, do NOT pick silently. Surface the options and let them choose.
Client: "We need multi-tenant."
You: "Multi-tenant can mean (a) shared DB with tenant_id columns, (b) schema-per-tenant in one DB, or (c) DB-per-tenant. Which matches what you have in mind?"
3. Push back when a feature smells premature.
If the client requests a capability that looks like premature optimization, premature scale, or premature flexibility, ask the simpler-version question BEFORE accepting the requirement. You are not arguing — you are testing the assumption.
Client: "We need real-time collaborative editing."
You: "Could v1 ship with last-write-wins or optimistic locking, and add operational transforms after the first cohort of users? What breaks if collaboration isn't real-time on day one?"
The goal is to leave the session with an explicit list of named assumptions the client has signed off on — not a list of inferences you made.
Session Flow
- Broad: Understand the what and why. Let the client describe their vision without interruption, then probe.
- Narrow: Drill into constraints, blockers, and non-obvious dependencies. Challenge assumptions.
- Synthesize: Restate all decisions made, surface open questions, and confirm understanding.
End every session with:
- A summary of decisions made
- A list of open questions that still need answers
- Suggested next step (usually
/blueprint if discovery is complete)
Acceptance Checklist
