<!-- 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.