| name | idea-shaping |
| description | Turns a vague idea into a clear, evaluated problem statement before any spec or code. Use when a request is a one-liner, the problem is fuzzy, you're choosing between directions, or you're not yet sure the idea is worth building. |
Idea Shaping
Before you specify what to build, decide whether the idea is worth building and clearly
understood. Most weak features trace back to a fuzzy idea nobody pressure-tested — a solution handed
as a problem, an unexamined assumption, or the first option never compared to doing less.
Shaping is cheap. Building is expensive. A sharp pursue / park / drop with reasoning is a valid
outcome; a vague "yes let's try" is not.
This skill precedes [[spec-first]] for engineering specs and [[product-brief]] when stakeholders need
alignment on a PRD or RFC. For recording a significant chosen direction, see [[decision-docs]].
When to Use
- The request is a single sentence or hand-wave ("add gamification", "we need AI here")
- The underlying problem is unclear, unstated, or disputed
- You're choosing between several possible directions
- You suspect the idea solves the wrong problem or is a vanity feature
- A stakeholder, exec, or customer proposed a solution — need to find the need underneath
- You're about to estimate or staff work and can't explain the problem in one sharp sentence
Skip when the problem is already shaped, evidenced, and agreed — go straight to [[spec-first]] or
[[product-brief]]. Skip for pure execution on a locked spec.
Not this skill alone: cross-team sign-off on a large initiative → shape first, then [[product-brief]].
Process
Work in order. Don't write requirements until the problem statement survives pressure.
1. Capture the raw input — don't adopt the solution as the problem
Write what was said verbatim, then separate layers:
Raw request: "Add a leaderboard to increase engagement"
Solution proposed: leaderboard
Problem (unknown): ??? engagement with what, for whom, why now
People hand you solutions and call them problems. Your job is to dig to the need.
Clarifying questions (ask until answers are concrete):
- Who specifically has pain or opportunity? (role, segment, not "users")
- What do they do today without this feature?
- What goes wrong or what's missing — in their words, not yours?
- How often does it happen? How painful is it (time, money, risk, frustration)?
- Why now? What changed — market, data, regulation, strategy?
- What would success look like for them, not for the dashboard?
If answers are vague ("engagement is low"), push for observable behavior ("users abandon onboarding
at step 3").
2. Write one sharp problem statement
A good problem statement has who, pain, context, and why alternatives fail — no solution baked in.
Template:
[Who] experiences [pain] when [context/situation],
because [cause or constraint].
Today they [current behavior/workaround], which [cost of workaround].
Examples:
Good: New sellers abandon listing creation after uploading photos because they don't
know if pricing is competitive; they guess or leave and never publish.
Bad: We need a pricing recommendation feature.
Solution disguised as problem — rewrite:
| Disguised | Reframed |
|---|
| "We need push notifications" | Buyers miss time-sensitive deals because they don't check email within the offer window |
| "Build a mobile app" | Field technicians can't complete jobs when offline; they paper notes and re-enter later |
| "Add AI chat" | Support can't scale; wait time is 48h and CSAT dropped — unclear if chat is the fix |
If you can't write the statement without naming your favorite solution, you haven't finished shaping.
3. Map assumptions — name what must be true
List what the idea assumes without evidence:
| Assumption | Evidence we have | Confidence |
|---|
| Sellers quit because of pricing, not photos/UX | One support ticket | Low |
| Recommendations will increase publish rate | None | Guess |
| Sellers will trust algorithmic prices | Competitor survey | Medium |
Circle the riskiest assumption — if it's wrong, the whole idea fails. That's what you validate
first, cheapest.
Common hidden assumptions:
- Users want this (desire)
- Users will change behavior (adoption)
- We can build it within constraints (feasibility)
- It won't hurt another metric (strategic)
- Legal/compliance allows it (constraint)
- Data exists to power it (data)
4. Validate cheaply before building
Building is the most expensive experiment. Prefer fast learning on the riskiest assumption:
| Method | Cost | Good for |
|---|
| 5–8 user interviews | Hours | Pain real? workaround? language? |
| Data analysis | Hours–days | Drop-off funnel, cohort, support tags |
| Concierge / manual | Days | Deliver outcome by hand before automating |
| Fake door / prototype | Days | Click interest without full build |
| Survey | Days | Breadth — weak on depth; triangulate |
| Spike / technical prototype | Days | Feasibility, latency, cost — not user value alone |
Record what you learned and update assumptions. "We talked to 6 sellers; 4 cited pricing anxiety,
2 cited photo quality" beats "users want this."
If validation fails the riskiest assumption → drop or pivot before [[spec-first]].
5. Generate alternatives — including less
The first idea is rarely the best. Sketch at least three approaches:
- Proposed solution — what was handed to you
- Different approach — same problem, different mechanism
- Minimum viable — smallest change that might move the needle
- Do nothing — cost of inaction; sometimes correct choice
Problem: sellers abandon listing due to pricing uncertainty
A) ML price recommendation at upload
B) Show market range from public data (read-only, no ML)
C) Human pricing review for first 10 listings (concierge)
D) Improve copy explaining how to price (education only)
E) Do nothing — focus on photo upload UX instead (if data shows that's the drop)
Alternatives force trade-offs into the open. Skipping this step is how teams build expensive A when B
would have worked.
6. Evaluate with explicit criteria
Score or rank options against what matters for this decision — not every criterion every time.
Typical criteria:
| Criterion | Questions |
|---|
| User value | How much pain removed? For how many? |
| Evidence | What validates the riskiest assumption? |
| Effort | Build time, ongoing maintenance, ops burden |
| Risk | Technical, legal, reputational, metric cannibalization |
| Strategic fit | Aligns with company focus, moat, roadmap |
| Time | Urgency — deadline, season, competitive window |
Be honest about trade-offs:
Option B is faster but may not be enough for power sellers;
Option A is high upside but 3-month build and needs pricing data we don't have yet.
Avoid false precision — "score 7.2" without reasoning helps no one. Narrative trade-offs help.
7. Decide — pursue, park, or drop
Record a clear decision with why:
| Decision | When | Record |
|---|
| Pursue | Problem sharp, riskiest assumption validated or acceptable, best option chosen | Chosen approach + why not others |
| Park | Maybe later — missing data, dependency, strategy timing | What must change to revisit; review date |
| Drop | Wrong problem, failed validation, better alternative elsewhere | Why not — prevents relitigation |
Decision: PURSUE option B (market range display) for v1.
Why: interviews + funnel data support pricing anxiety; B ships in 2 weeks vs 3 months for ML.
Park A for Q3 if B moves publish rate +10%.
Drop C — ops cost not scalable.
"No" with reasoning is success. "Let's just try it" without criteria is not.
8. Hand off to the next artifact
| Next step | When |
|---|
| [[spec-first]] | Engineering team ready to build; problem shaped for one team |
| [[product-brief]] | Stakeholders, sign-off, cross-team initiative, PRD/RFC needed |
| [[decision-docs]] | Significant strategic choice others will question later |
| Spike ticket only | Technical feasibility unknown — time-boxed, not a feature commit |
Handoff packet (paste into spec or brief):
Problem statement:
Assumptions (validated / still open):
Chosen direction:
Alternatives rejected and why:
Success signal (how we'll know it worked):
Out of scope for this round:
Open questions for spec:
9. Scenario playbooks
Exec one-liner in Slack
Capture verbatim → problem excavation in 30 min → one-page shape → pursue/park/drop before anyone
estimates.
Engineer proposed solution
"Let's use Kafka" → what problem? at what scale? what fails today? → maybe a queue isn't the issue.
Competitive parity ("Competitor has X")
What user job does X serve for our users? Is parity strategic or anxiety? Often a smaller local
win beats feature cloning.
Internal tool / automation
Who does manual work today? How many hours? What's the error rate? Internal ROI can be clear without
user interviews — still shape the problem.
"We should add AI / LLM"
What task, what input, what output, what failure cost? ([[llm-feature-engineering]]) — AI is an
implementation option, rarely the problem statement.
Customer feature request
Thank → understand job → check if request is representative → shape for segment size, not one loud
customer.
Two good ideas, one team
Shape both lightly → compare criteria → pick one → park the other with review trigger (metric, date).
Common Rationalizations
- "The idea is obviously good." — Obvious ideas still hide wrong assumptions or better alternatives.
- "Let's just build it and see." — Building is the most expensive test; validate cheaper first.
- "There's only one way to do it." — There's always do-less and do-different; look harder.
- "We can validate after launch." — Launch without learning plan wastes the cheapest validation window.
- "The CEO asked for it." — Shape anyway; execs often want outcomes, not the first solution named.
- "We don't have time to think." — You'll spend more time rebuilding the wrong thing.
- "Data will tell us after we ship." — Define the metric before ship; else you can't interpret noise.
- "Park is the same as pursue slowly." — Park needs explicit triggers; otherwise it becomes zombie roadmap.
Red Flags
- Jumping from one-line idea to implementation or spec with no problem statement
- "Problem" statement contains the solution name ("we need a leaderboard")
- No one can name who has pain or how they'd behave differently after
- Zero alternatives considered — only the handed solution
- Riskiest assumption never named or tested
- Success metric undefined — "engagement", "better", "modern" without observable behavior
- Pursue decision with no rejected alternatives documented
- Shaping skipped because "we already built the prototype"
- Park without review date or success criteria for revisit
- Shape doc is 20 pages — nobody reads it; one page plus handoff packet is enough
Verification
