Develop Solution Brief
Scannednpx machina-cli add skill product-on-purpose/pm-skills/develop-solution-brief --openclawname: develop-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. phase: develop version: "2.0.0" updated: 2026-01-26 license: Apache-2.0 metadata: category: ideation frameworks: [triple-diamond, lean-startup, design-thinking] author: product-on-purpose
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:
-
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.
-
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.
-
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.
-
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.
-
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.
-
Identify Risks and Mitigations Surface the biggest risks to success and your plan to address them. This builds stakeholder confidence and surfaces concerns early.
-
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.
Source
git clone https://github.com/product-on-purpose/pm-skills/blob/main/skills/develop-solution-brief/SKILL.mdView on GitHub Overview
Provides a concise, stakeholder-facing overview that links problem understanding to the proposed approach. It acts as the bridge between problem framing and detailed specification, clarifying decisions and trade-offs. Used to align teams, secure buy-in, and document intent before PRD work.
How This Skill Works
Follow the structured brief: recap the problem in 2-3 sentences, describe the proposed solution in plain language, and enumerate 3-5 essential features. Then define success metrics, acknowledge trade-offs, surface risks with mitigations, and outline next steps.
When to Use It
- Pitch a solution approach to stakeholders for buy-in
- Align cross-functional teams on what you're building and why
- Document solution intent before detailed PRD writing
- Compare multiple solution options at a high level
- Communicate product direction to leadership
Quick Start
- Step 1: Recap the problem in 2-3 sentences.
- Step 2: Describe the proposed solution in clear, non-technical language and list 3-5 key features.
- Step 3: Define success metrics, state trade-offs, identify risks with mitigations, and outline 3-5 next steps.
Best Practices
- Keep the brief to one page (approximately 500-700 words)
- Recap the problem in 2-3 sentences; avoid rehashing the full problem
- Describe the solution in plain language, focused on user value
- Limit features to 3-5 essential capabilities
- Explicitly state trade-offs, risks, mitigations, and next steps
Example Use Cases
- Pitch a new feature to executives with the rationale and expected impact
- Align engineering, design, and product before drafting a detailed PRD
- Compare two architectural approaches at a high level
- Document solution intent for a major product direction shift
- Share a concise roadmap brief with leadership