discover

discover — diagnose before you prescribe

Prescription before diagnosis is malpractice. Before you say what the engagement looks like, what tool to use, or what it costs, you have to understand the actual problem. The conversation in this skill is the work — not a preamble to the work.

Drill these four, in order

1. Outcome — what business result are they trying to produce? Not what they want to build; what they want to be true after. "More leads" is a feature; "predictable pipeline so we can hire two reps in Q3" is an outcome.
2. Impact — what does it cost them to get it wrong, or fail to get it right? Revenue lost, customers churned, time burned, optionality foreclosed. If the impact is small, the engagement should be small (or refused). If the impact is large, anchor everything else against it.
3. Constraints — what's actually fixed? Time (board meeting, regulatory deadline), budget (real ceiling vs. opening anchor), political (someone internally is invested in a particular answer), technical (must integrate with X). Constraints you don't surface become surprises later.
4. Decision-maker — who actually approves this? If you're talking to someone who has to sell it upstairs, your job in discovery is partly to arm them. If you never meet the real decider, the engagement is at risk.

Posture

Ask, don't pitch. Long pauses are fine. Take notes the client can see. When you don't know, say so — pretending to know what you don't is the fastest way to lose a peer relationship.

Reframe when the real problem isn't the stated problem

Discovery often surfaces that the stated problem isn't the real one. ("You said you need a new CRM, but it sounds like the real issue is your sales process isn't documented yet — a CRM won't fix that.") Name it back to the client. This is frequently the single most valuable thing you do for them, and it's the move that establishes you as a peer rather than an order-taker. Do it gently, do it once, and let them sit with it.

Output

A one-page diagnostic note the client can react to:

• Problem as we now understand it — one paragraph, in their language.
• Observed constraints — bullet list (time, budget, political, technical).
• 2–3 open questions — what you'd need to know before you'd be willing to propose.

End with: "If this lands, here's what a next conversation looks like." One sentence. Not a proposal yet.

Anti-patterns

• Tool-first — "You need Salesforce / Notion / a Next.js rewrite." You don't know yet.
• Scope-first — "This sounds like a 3-month project." You're sizing before you've diagnosed.
• Agreement-first — yes-ing every statement to seem helpful. Peers push back; vendors agree.
• Pretending to know — bluffing on a domain or tech you don't actually understand. Clients can tell, and it ends the relationship faster than admitting the gap would have.
• Diagnosing in one meeting — sometimes one is enough; often it isn't. Saying "I want to talk to one more person before I propose" is a sign of seriousness, not weakness.

Pair with scope (after diagnosis settles), propose (once scope is shaped), and position (when the conversation starts feeling like vendor-mode).