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

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

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

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

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

1. Identify Risks and Mitigations

Surface the biggest risks to success and your plan to address them. This builds stakeholder confidence and surfaces concerns early.

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