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.

<! PM Skills https://github.com/product on purpose/pm skills Apache 2.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 When NOT to Use Stakeholders are aligned and engineering needs the full specification use deliver prd ; the brief pitches, the PRD specifies The problem is not yet framed or agreed use define problem statement first You are recording a decision already made use develop adr (technical) or develop design rationale (design) You need to compare strategic options across the whole business model use foundation lean canvas 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. A complete brief fills every template section: Problem Recap; Proposed Solution; Key Features; Success Metrics; Trade offs Considered; Risks & Mitigations; and Next Steps. 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.

develop-solution-brief