Essential session storage is required to sign in. Optional analytics remain off unless you allow them.
Pick a real product (or a feature of one) and write a one-page DISCOVERY BRIEF that defines the PROBLEM before any solution. Include: a sharp problem statement (who has the problem, in what context, why it matters), the target user/segment, the Job-To-Be-Done it addresses (functional/emotional/social), the riskiest assumptions behind it, and a rough opportunity size (TAM/SAM/SOM, even if estimated). Crucially, do NOT propose a solution or feature list — the deliverable proves you can resist the build trap and frame an outcome. Cite at least 2-3 user signals (interviews, reviews, support tickets, or data) you'd gather.
A real problem statement (who/context/why) tied to a JTBD; stays on the problem/outcome, does NOT jump to a solution (avoids the build trap).
Target segment is specific; cites concrete user signals/evidence (interviews, reviews, data), not assumptions.
A reasoned TAM/SAM/SOM (even estimated) and the riskiest assumptions named.
One page, crisp, decision-useful.
Use this README structure to make the work reviewable.
DevPath fetches a read-only, size-capped snapshot. Submitted code is never executed.
# A discovery brief: problem, not solution ## Goal Pick a real product (or a feature of one) and write a one-page DISCOVERY BRIEF that defines the PROBLEM before any solution. Include: a sharp problem statement (who has the problem, in what context, why it matters), the target user/segment, the Job-To-Be-Done it addresses (functional/emotional/social), the riskiest assumptions behind it, and a rough opportunity size (TAM/SAM/SOM, even if estimated). Crucially, do NOT propose a solution or feature list — the deliverable proves you can resist the build trap and frame an outcome. Cite at least 2-3 user signals (interviews, reviews, support tickets, or data) you'd gather. ## Acceptance criteria - [ ] Problem framing: A real problem statement (who/context/why) tied to a JTBD; stays on the problem/outcome, does NOT jump to a solution (avoids the build trap). - [ ] User grounding: Target segment is specific; cites concrete user signals/evidence (interviews, reviews, data), not assumptions. - [ ] Opportunity & risk: A reasoned TAM/SAM/SOM (even estimated) and the riskiest assumptions named. - [ ] Clarity: One page, crisp, decision-useful. ## Verification - [ ] Document installation and run commands. - [ ] Record automated checks and their exact commands. - [ ] Add representative output, screenshots, or a short demo where useful. - [ ] Confirm failure paths and known constraints. ## Decision log ### Decision title - Context: - Choice: - Alternatives considered: - Tradeoffs: ## Evidence - Link each rubric criterion to the file, test, or artifact that demonstrates it. ## Known limitations - List what is intentionally out of scope and what should be improved next.