vignesh2027 Overview
Most ideas arrive as fuzzy intuitions. This skill converts them into crisp, buildable proposals with clear scope, constraints, and success criteria — before anyone writes a spec or a line of code.
When to Use
- Before writing a spec for something you've only talked about
- When a request feels vague or underspecified
- When you're unsure if you're solving the right problem
- Before a technical design discussion
Process
Step 1: State the problem, not the solution
Write one sentence describing the problem being solved. Not the feature — the problem. Example: "Users can't find past orders because search only covers the last 30 days."
Step 2: Identify who has the problem
Name the specific user persona or system component affected. Vague problems have vague solutions.
Step 3: Measure the current pain
Quantify where possible: "affects 20% of active users," "adds 3 minutes to the workflow," "causes 12 support tickets/week." If you can't measure it, question whether it's a real problem.
Step 4: List candidate solutions
Write 3 different ways to solve the problem at different points on the effort/impact curve. This prevents anchoring on the first idea.
Step 5: Score and select
For each solution: estimate effort (S/M/L), impact (low/medium/high), and risk (low/medium/high). Select the option with the best ratio for the current context.
Step 6: Define the out-of-scope boundary
Explicitly state what this proposal does NOT include. Scope creep starts here if you don't.
Step 7: State the success metric
One measurable outcome that proves the problem is solved. Not "users like it" — "search result relevance score improves by 15% on the benchmark dataset."
Anti-Rationalizations
"We know what we want to build — let's just build it" The thing you want to build is a solution. Before committing to a solution, confirm you've correctly understood the problem.
"We don't have data on this yet" Absence of data is a finding. Document your assumptions and validate them in the first iteration.
Verification Requirements
- Problem statement is one sentence and problem-focused (not solution-focused)
- Affected user or system is named
- At least 2 candidate solutions were considered
- Out-of-scope items are explicitly listed
- Success metric is measurable