Idea Refinement

Overview

Turn a vague idea into a focused, actionable direction. This skill uses structured divergent-convergent thinking: first expand possibilities, then evaluate and converge on the strongest direction, then sharpen into a one-pager ready for spec writing.

Philosophy: "Simplicity is the ultimate sophistication." Say no to 1,000 things to focus on the one that matters.

When to Use

• A feature request or product idea is unclear or overly broad
• You need to explore multiple directions before committing
• Stakeholders have different interpretations of "what we're building"
• Before writing a spec (feeds into spec-driven-development)

Skip when: The requirement is already specific and unambiguous.

Core Process

Phase 1: Understand & Expand (Divergent)

1. Restate as "How Might We" — Convert the idea into an open question
   • "Add offline support" → "How might we ensure users can accomplish core tasks without connectivity?"
2. Ask sharpening questions (answer or surface for human input):
   • Who specifically benefits? (persona, not "users")
   • What does success look like? (measurable outcome)
   • What constraints exist? (timeline, tech debt, API limitations, minSdk)
   • What has been tried before?
3. Generate 5–8 variations using these lenses:
   • Inversion: What if we solved the opposite problem?
   • Constraint removal: What if we had no legacy code / no backward compatibility?
   • Simplification: What is the absolute minimum version?
   • Combination: What if we merged this with another planned feature?
   • Analogy: How do other Android apps solve this? (study Play Store top apps)

Phase 2: Evaluate & Converge

4. Cluster into 2–3 directions — group related variations
5. Stress-test each direction:
   • Technical feasibility (existing modules, Android API levels, library support)
   • User impact (who benefits, how much)
   • Effort estimate (small / medium / large)
   • Risk profile (what could go wrong)
6. Surface hidden assumptions — list every assumption with a validation strategy
   • "Assumption: Room migrations will handle schema changes → Validate: write migration test"

Phase 3: Sharpen & Ship

7. Write a one-pager with:
   • Problem statement (1–2 sentences)
   • Recommended direction (with rationale)
   • Key assumptions (with validation plan)
   • MVP scope (what's in the first slice)
   • "Not Doing" list (explicit exclusions — critical for scope discipline)

Common Rationalizations

Red Flags

• No "Not Doing" list (scope will creep)
• Single direction explored (confirmation bias)
• Assumptions listed without validation strategies
• MVP scope includes "and also…" additions
• No measurable success criteria

Verification

Before moving to spec:

• Problem restated as "How Might We" question
• At least 5 variations generated using different lenses
• 2–3 directions evaluated with feasibility, impact, effort, risk
• All assumptions listed with validation strategies
• One-pager written with problem, direction, assumptions, MVP scope, exclusions
• Human has reviewed and approved the direction