# Solution Brief

> <!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

- Skill: `majiayu000/solution-brief` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/solution-brief`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/solution-brief/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/solution-brief

---


<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
---
name: solution-brief
description: Creates a concise one-page solution overview that communicates the proposed approach, key decisions, and trade-offs. Use when pitching solutions to stakeholders, aligning teams on approach, or documenting solution intent before detailed specification.
license: Apache-2.0
metadata:
  category: ideation
  frameworks: [triple-diamond, lean-startup, design-thinking]
  author: product-on-purpose
  version: "1.0.0"
---

# Solution Brief

A solution brief is a concise, one-page document that communicates the proposed solution to a problem. It serves as the bridge between problem understanding and detailed specification, providing enough context for stakeholders to align on the approach without getting lost in implementation details. The one-page constraint forces clarity and prioritization.

## When to Use

- Pitching a solution approach to stakeholders for buy-in
- Aligning cross-functional teams on what you're building and why
- Documenting solution intent before detailed PRD writing
- Comparing multiple solution options at a high level
- Communicating product direction to leadership

## Instructions

When asked to create a solution brief, follow these steps:

1. **Recap the Problem**
   Summarize the problem in 2-3 sentences maximum. Don't re-explain the full problem statement — reference it if needed. The reader should immediately understand what pain point this solution addresses.

2. **Describe the Proposed Solution**
   Explain what you're building in clear, non-technical language. Focus on the user experience and core value proposition. Avoid implementation details — this is about *what*, not *how*.

3. **List Key Features**
   Identify 3-5 essential features that comprise the solution. These should be the minimum set needed to solve the problem. Resist the urge to include nice-to-haves — the one-page constraint demands focus.

4. **Define Success Metrics**
   Connect the solution to measurable outcomes. How will you know if this works? Reference metrics from the problem statement and set targets.

5. **Acknowledge Trade-offs**
   Document what you're explicitly NOT doing and why. Good solution briefs are honest about scope limitations and alternatives that were considered but rejected.

6. **Identify Risks and Mitigations**
   Surface the biggest risks to success and your plan to address them. This builds stakeholder confidence and surfaces concerns early.

7. **Outline Next Steps**
   Provide 3-5 immediate actions to move the solution forward. Be specific about who does what.

## Output Format

Use the template in `references/TEMPLATE.md` to structure the output.

## Quality Checklist

Before finalizing, verify:

- [ ] Brief fits on one page when printed (approximately 500-700 words)
- [ ] Problem recap is concise (2-3 sentences maximum)
- [ ] Solution description avoids technical jargon
- [ ] Features are limited to 3-5 essential capabilities
- [ ] Trade-offs are explicitly stated
- [ ] Next steps are specific and actionable

## Examples

See `references/EXAMPLE.md` for a completed example.