Product Brainstorming
When to use
Use this when you have a rough idea, a problem space, or a "what if" and want a partner who both widens the option set and stress-tests it, not a yes-machine that praises everything.
Not for: writing the spec once a direction is chosen (use pm-write-spec), synthesizing existing research into themes (use pm-synthesize-research), or committing a roadmap. If you already know exactly what to build, skip to specification.
Method
- Clarify the target: whose problem, how painful, and how you would know it is solved. Decision point: if the problem is vague, sharpen it before generating a single solution.
- Diverge first. Generate a wide range, including at least one cheap/hacky option and one ambitious/contrarian one. Quantity before judgment.
- Cluster and name the strongest 3-5 directions so each is easy to reason about.
- Stress-test each: strongest steelman, sharpest objection, the assumption that must be true, and the cheapest experiment to test it.
- Surface the risks people skip: distribution, willingness to pay, build cost, and copyability. Decision point: if a rival could clone it in a week and out-distribute you, flag it as fragile.
- Converge: recommend pursue now, park, or kill, with reasoning.
Example
Problem: new users abandon before their first "aha". Ideas cluster into (a) interactive onboarding tour, (b) pre-populated demo workspace, (c) concierge setup call. Pressure-test (b): assumption = users trust sample data enough to explore; risk = feels fake and lowers trust; cheapest test = ship a demo workspace to 5% and watch time-to-first-action. Recommendation: pursue (b), park (a), kill (c) on cost-to-scale.
Pitfalls
- Converging too early on the first plausible idea, skipping divergence.
- Steelmanning every idea equally instead of naming weak ones as weak and saying why.
- Ignoring distribution and willingness-to-pay, over-indexing on build feasibility.
- Testing with an expensive full build when a fake-door or Wizard-of-Oz would answer the question.
Output format
# Brainstorm: [problem] — [date]
Reframed problem statement: one sentence.
## Idea set (clustered)
- [cluster name]: [idea, 1-2 lines]
## Pressure-test
| Idea | Key assumption | Biggest risk | Cheapest test |
| --- | --- | --- | --- |
## Recommendation
- Pursue: [idea] — why
- Park: [idea] — why
- Kill: [idea] — why
## Open questions to resolve before committing
- ...
1---2name: pm-brainstorming3description: A candid ideation partner that expands the option space then pressure-tests each idea — steelman, sharpest objection, riskiest assumption, cheapest test — and converges on pursue/park/kill.4---56# Product Brainstorming78## When to use9Use this when you have a rough idea, a problem space, or a "what if" and want a partner who both widens the option set and stress-tests it, not a yes-machine that praises everything.1011**Not for:** writing the spec once a direction is chosen (use pm-write-spec), synthesizing existing research into themes (use pm-synthesize-research), or committing a roadmap. If you already know exactly what to build, skip to specification.1213## Method141. Clarify the target: whose problem, how painful, and how you would know it is solved. **Decision point:** if the problem is vague, sharpen it before generating a single solution.152. Diverge first. Generate a wide range, including at least one cheap/hacky option and one ambitious/contrarian one. Quantity before judgment.163. Cluster and name the strongest 3-5 directions so each is easy to reason about.174. Stress-test each: strongest steelman, sharpest objection, the assumption that must be true, and the cheapest experiment to test it.185. Surface the risks people skip: distribution, willingness to pay, build cost, and copyability. **Decision point:** if a rival could clone it in a week and out-distribute you, flag it as fragile.196. Converge: recommend pursue now, park, or kill, with reasoning.2021## Example22Problem: new users abandon before their first "aha". Ideas cluster into (a) interactive onboarding tour, (b) pre-populated demo workspace, (c) concierge setup call. Pressure-test (b): assumption = users trust sample data enough to explore; risk = feels fake and lowers trust; cheapest test = ship a demo workspace to 5% and watch time-to-first-action. Recommendation: pursue (b), park (a), kill (c) on cost-to-scale.2324## Pitfalls25- Converging too early on the first plausible idea, skipping divergence.26- Steelmanning every idea equally instead of naming weak ones as weak and saying why.27- Ignoring distribution and willingness-to-pay, over-indexing on build feasibility.28- Testing with an expensive full build when a fake-door or Wizard-of-Oz would answer the question.2930## Output format31```32# Brainstorm: [problem] — [date]33Reframed problem statement: one sentence.3435## Idea set (clustered)36- [cluster name]: [idea, 1-2 lines]3738## Pressure-test39| Idea | Key assumption | Biggest risk | Cheapest test |40| --- | --- | --- | --- |4142## Recommendation43- Pursue: [idea] — why44- Park: [idea] — why45- Kill: [idea] — why4647## Open questions to resolve before committing48- ...49```