Explores goals, constraints, risks, and design options before committing to a specific implementation path. This technique is most valuable when facing product or UX decisions where the wrong choice is expensive to reverse—new features with uncertain user value, architectural pivots, or cross-functional dependencies where each team has a different mental model of the problem.
Use cases
- Starting a new feature where the product intent is clear but multiple technical approaches are viable
- A cross-functional meeting where each stakeholder describes the problem differently and priorities conflict
- Evaluating a third-party service or API for a new integration where lock-in and cost are unknowns
- Deciding between building a feature in-house versus using an existing SaaS solution
- Planning a significant UX change where user research data is ambiguous or sparse
Key features
- Capture all context: stated goals, non-goals, known constraints, and the questions that, if answered, would change the decision most
- Narrow the problem space in stages—first identify what you are not solving for, then rank the remaining options by risk and impact
- For each promising direction, explicitly list the trade-offs: what you gain, what you give up, and what assumptions must hold true
- Converge on a concrete direction with a short rationale that includes the alternatives considered and why they were set aside
- Document the decision and its conditions so future information can be compared against the original assumptions
When to Use This Skill
- When a feature or architectural decision has multiple viable approaches and the trade-offs are not obvious
- When stakeholders have conflicting priorities and a structured discussion is needed to find consensus
- When the cost of reversing the decision is high and premature commitment is a risk
Expected Output
A decision record containing the chosen direction, alternatives considered, trade-offs, key assumptions, and conditions that would invalidate the choice.
Frequently Asked Questions
- How do I keep brainstorming sessions from turning into open-ended discussions with no conclusion?
- Set a time box and a specific output before the session starts. End with a decision or a clearly scoped follow-up question, not a list of 'things to think about.'
- What is the difference between brainstorming and a design review?
- Brainstorming happens before a decision is made and explores options. A design review evaluates a specific proposal against criteria. Use brainstorming to narrow the solution space, then a design review to vet the finalist.
- How do I handle a brainstorming session where participants are not aligned on basic facts?
- Pause the design discussion and spend 10 minutes establishing shared facts first. Misalignment on constraints or user behavior is the most common source of wasted brainstorming sessions.
Related
Related
3 Indexed items
Prompt engineering
Crafts prompts with explicit task framing, role definition, output constraints, citation requirements, and few-shot examples so model responses are consistent, grounded in evidence, and actionable for downstream tasks. Prompt engineering reduces the variability and hallucination risk that comes from under-specified prompts.
Source verification
Checks whether a claim is backed by a primary source, a current official page, or a reputable secondary source before that claim becomes published copy. This skill is essential for AI tool directories, MCP server listings, and news summaries where accuracy and trustworthiness directly affect reader decisions and SEO credibility.
Threat modeling
Systematically identifies threats to a system by mapping data flows, defining trust boundaries, and enumerating adversaries and misuse cases before shipping. This produces a security-focused diagram and prioritized mitigation list that makes subsequent security reviews faster and more substantive than starting from a generic checklist.