Make better product decisions with less guesswork
A structured process that uses the Socratic method to help teams separate what they know from what they assume — and test assumptions before committing.
A structured process that uses the Socratic method to help teams separate what they know from what they assume — and test assumptions before committing.
Product teams make dozens of decisions every week with incomplete information. Which feature to build. Whether to invest in a new market. How to interpret conflicting user signals. These decisions compound, and most of them are made on gut feel, the loudest voice in the room, or whatever a competitor just shipped.
The failure modes are familiar: building features nobody asked for because someone "just knew." Debating the same question for weeks without new evidence. Confusing a stakeholder's conviction for a user's need. Launching an experiment with no success criteria, then arguing about what the results mean.
The cost is real — wasted engineering cycles, shipped features that get ignored, late pivots that could have been early kills. Not because teams lack intelligence, but because the process for handling uncertainty is either too heavy (months of research) or nonexistent (vibes).
Discovery is the practice of reducing uncertainty before committing to build. It's not a phase that happens once at the start of a project — it's a continuous discipline of asking "are we solving the right problem?" and "how do we know?"
The goal isn't to eliminate uncertainty — that's impossible. The goal is to make uncertainty explicit, prioritized, and testable. To know what you're betting on, how much it matters, and what evidence would change your mind.
Good discovery separates facts from assumptions, identifies the assumptions that carry the most risk, and designs the cheapest possible tests to validate them. It's how you avoid building the wrong thing — or building the right thing for the wrong reasons.
Six steps. Use them in order, skip what you don't need, repeat as evidence comes in.
What mode are you in — Exploring (no clear problem), Framing (problem known, needs structure), or Executing (direction set, needs tactics)? How risky is this decision — Low, Medium, or High? Match your rigor to the stakes.
Force the choice into an explicit frame: "Are we choosing A vs B vs C?" Define the deadline and what "do nothing" means. If the decision is fuzzy, you're not ready to solve it.
List what you actually know (Facts, with sources), what you've concluded (Inferences), what you believe without evidence (Assumptions), and what's missing (Unknowns). This step alone changes most conversations.
Find the one assumption that, if false, would sink the entire plan. Not the most interesting assumption — the most dangerous one. This is where you focus your testing energy.
One hypothesis, one cheapest reliable experiment, one metric window, one threshold. "If we do X, then Y will happen for segment Z within T, because mechanism M."
Recap what was decided. State the next step. Define the decision rule: proceed if…, pivot if…, stop if… Include a confidence score (1-5) with rationale. No open-ended "let's keep discussing."
Facts (verified, with source) · Inferences (conclusions from facts, not yet validated) · Assumptions (beliefs without evidence) · Unknowns (missing information to collect)
The single assumption that would destroy the plan if proven false. Not the most discussed one — the most consequential one. Focus testing energy here first.
Proceed if the threshold is met. Pivot if results are partial. Stop if the kill assumption is falsified. No ambiguous "let's revisit later."
Not every decision needs full rigor. A CTA test gets 1-2 questions and a quick threshold. A pricing restructure gets triangulated evidence and explicit stop rules.
The full process covers mode detection, bias awareness, triangulation, experiment design, and convergence signals. Read the complete operating instructions.
A fitness app spent $400k building a meal planning feature. 4% adoption. 12% repeat usage. The team lead says it just needs better onboarding. Here's how the Socratic process handles it.
The messy input
"We spent 8 months building a meal planning feature. It's live for 3 months now but only 4% of users have tried it, and of those, only 12% used it more than once. Our team lead thinks we just need better onboarding. We've already invested $400k. Should we keep investing or move on?"
Separate reality
Kill assumption
"Users want meal planning help." — Sunk cost is sunk. The $400k is irrelevant to the forward-looking decision. If users don't want this feature, no amount of onboarding fixes it.
Cheapest test
Email 200 engaged users with a personal invite. Track: open, click, setup, D7 return. Interview 10 who clicked but didn't finish. Cost: ~$0. Time: 1 week.
Proceed if 40%+ complete setup AND 25%+ return D7
Pivot if setup is high but D7 return is low (feature isn't solving a real problem)
Stop if <20% of engaged, invited users complete setup (onboarding won't save it)
This scenario scored 18/20 in evaluation — strong across all 10 criteria. See more worked examples.
We tested this process against 20 realistic product scenarios spanning 8 industries, 3 discovery modes, and 7 types of cognitive traps. Each scenario was processed by the Copilot, then independently evaluated against 10 criteria.
76%
Aggregate score
305 of 400 points
1.80
Risk & Questions
out of 2.0 — strongest
11
High performers
scored 16+ out of 20
1.15
Testable Hypothesis
out of 2.0 — weakest
What works well: The process consistently calibrates depth to risk level (1.80/2), asks focused questions (1.80/2), and correctly detects the discovery mode (1.70/2). It caught solution-first thinking, confirmation bias, and HiPPO patterns perfectly across all scenarios where those traps were embedded.
Where it falls short: Testable hypothesis formation (1.15/2), confidence scoring (1.30/2), and FIAU separation (1.45/2) are the weakest areas. The process often asks the right questions but doesn't always follow through to a concrete, testable next step with explicit structured outputs.
These gaps are where v1.1 improvements will focus. Full analysis in the evaluation report.
Give your AI assistant the URL to the prompt file. It works with Claude, ChatGPT, Gemini, or any capable model. Then start a conversation about a product decision you're facing.
https://raw.githubusercontent.com/craice/socratic/main/process/socratic-1.0.md Use the cheatsheet as a mental model in your next product discussion. The 6-step loop, FIAU separation, and decision rule templates work with or without AI.
Read the full operating instructions to understand every mechanism — mode detection, bias calibration, triangulation, experiment design, threshold templates, and convergence signals.
Try it now
Open your preferred AI assistant, paste the prompt URL above, and try:
"We want to add gamification to our app. Can you help?"
Watch it rewind from solution to problem, separate assumptions from facts, and guide you toward a testable hypothesis.