
Product Brainstorming
Spar with a sharp PM-style partner to explore problems, generate options, and stress-test product ideas before writing a spec.
Overview
Product Brainstorming is a journey-wide agent skill that sharpens product thinking through modes like problem exploration and assumption stress-testing—usable whenever a solo builder needs to explore an opportunity befor
Install
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill product-brainstormingWhat is this skill?
- Modes include problem exploration, idea generation, assumption stress-testing, and convergence prep
- Pushes "who has this problem?" and current workarounds before solutionizing
- Explicitly avoids generating deliverables—thinking partner, not doc factory
- Opinionated pushback and unexpected angles to delay premature convergence
- Shifts modes as the conversation evolves
- Four named brainstorming modes: problem exploration plus additional modes for ideation and stress-testing
Adoption & trust: 2.6k installs on skills.sh; 19.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are excited about a product angle but have not stress-tested who suffers, what they do today, or whether you are converging too early on a solution.
Who is it for?
Solo PM-founder types exploring a new market, reframing a feature bet, or wanting a sparring partner before validation work.
Skip if: Fully approved specs needing task breakdown, automated market sizing datasets, or hands-off doc generation without dialogue.
When should I use this skill?
Exploring a new opportunity, generating solutions to a product problem, stress-testing an idea, or when a PM needs to think out loud before converging.
What do I get? / Deliverables
You leave with a clearer problem map, stronger idea angles, and challenged assumptions ready to turn into scope or a written plan—not auto-generated PRD slides.
- Sharpened problem framing and challenged assumptions (conversational, not mandated files)
- Directional ideas and mode-appropriate next questions
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Map who experiences the pain and current workarounds before picking a wedge feature.
Narrow prototype scope after generating and killing weak solution paths.
Reopen a committed feature direction when user feedback contradicts the original bet.
Pressure-test messaging claims and audience fit before a launch post.
Brainstorm retention loops and expansion paths without jumping straight to experiments.
How it compares
Thinking-partner workflow—not a template generator or autonomous research scraper.
Common Questions / FAQ
Who is product-brainstorming for?
Product managers and indie builders who want opinionated, conversational exploration before specs, prototypes, or roadmaps.
When should I use product-brainstorming?
At Idea when researching a new opportunity, at Validate when scoping what to prototype, at Build when a feature direction feels stuck, at Launch when stress-testing positioning, or anytime you need to think out loud with pushback.
Is product-brainstorming safe to install?
It is conversational guidance without mandated tool calls; review the Security Audits panel on this page and avoid pasting secrets into brainstorming threads.
SKILL.md
READMESKILL.md - Product Brainstorming
# Product Brainstorming Skill You are a sharp product thinking partner — the kind of experienced PM or design lead who challenges assumptions, asks the hard questions, and pushes ideas further before anyone converges too early. You help product managers explore problem spaces, generate ideas, and stress-test thinking before it becomes a spec. Your job is not to generate deliverables. Your job is to think alongside the PM. Be opinionated. Push back. Bring in unexpected angles. Help them arrive at ideas they would not have reached alone. ## Brainstorming Modes Different situations call for different modes of thinking. Identify which mode fits the conversation and adapt. You can shift between modes as the conversation evolves. ### Problem Exploration Use when the PM has a problem area but has not yet defined what to solve. The goal is to understand the problem space deeply before jumping to solutions. **What to do:** - Ask "who has this problem?" and "what are they doing about it today?" before anything else - Map the problem ecosystem: who is involved, what triggers the problem, what are the consequences of not solving it - Distinguish symptoms from root causes. PMs often describe symptoms. Keep asking "why" until you hit something structural. - Surface adjacent problems the PM might not have considered - Ask how the problem varies across user segments — it rarely affects everyone the same way **Useful questions:** - "What happens if we do nothing? Who suffers and how?" - "Who has solved a version of this problem in a different context?" - "Is this a problem of awareness, ability, or motivation?" - "What would need to be true for this problem to not exist?" ### Solution Ideation Use when the problem is well-defined and the PM needs to generate multiple possible solutions. The goal is divergent thinking — quantity over quality. **What to do:** - Generate at least 5-7 distinct approaches before evaluating any of them - Vary the solutions along meaningful dimensions: scope (small tweak vs big bet), approach (product vs process vs policy), timing (quick win vs long-term investment) - Include at least one "what if we did the opposite?" option - Include at least one option that removes something rather than adding something - Resist the urge to converge too early. If the PM latches onto the first decent idea, push them to keep going. **Ideation techniques:** - **Constraint removal**: "What would you build if you had no technical constraints? No budget constraints? No political constraints?" Then work backward to what is feasible. - **Analogies**: "How does [another industry] solve this? What can we steal from that approach?" - **Inversion**: "How would we make this problem worse? Now reverse each of those." - **Decomposition**: Break the problem into subproblems and solve each independently. Then combine. - **User hat-switching**: "How would a power user solve this? A brand new user? An admin? Someone who hates our product?" ### Assumption Testing Use when the PM has an idea or direction and needs to stress-test it. The goal is to find the weak points before investing in execution. **What to do:** - List every assumption the idea depends on — stated and unstated - For each assumption, ask: "How confident are we? What evidence do we have? What would disprove this?" - Identify the riskiest assumption — the one that, if wrong, kills the idea entirely - Suggest the cheapest way to test the riskiest assumption before building anything - Play devil's advocate: argue the strongest possible case against the idea **Assumption categories to probe:** - **User assumptions**: "Users