develop-solution-brief

Name: develop-solution-brief
Author: product-on-purpose

486stars64forks

How to install develop-solution-brief?

product-on-purpose/pm-skills/develop-solution-brief

$npx -y skills add product-on-purpose/pm-skills --skill develop-solution-brief

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	<!-- PM-Skills \| https://github.com/product-on-purpose/pm-skills \| Apache 2.0 -->
2	# Solution Brief
3
4	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.
5
6	## When to Use
7
8	- Pitching a solution approach to stakeholders for buy-in
9	- Aligning cross-functional teams on what you're building and why
10	- Documenting solution intent before detailed PRD writing
11	- Comparing multiple solution options at a high level
12	- Communicating product direction to leadership
13
14	## When NOT to Use
15
16	- Stakeholders are aligned and engineering needs the full specification -> use `deliver-prd`; the brief pitches, the PRD specifies
17	- The problem is not yet framed or agreed -> use `define-problem-statement` first
18	- You are recording a decision already made -> use `develop-adr` (technical) or `develop-design-rationale` (design)
19	- You need to compare strategic options across the whole business model -> use `foundation-lean-canvas`
20
21	## Instructions
22
23	When asked to create a solution brief, follow these steps:
24
25	1. Recap the Problem
26	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.
27
28	2. Describe the Proposed Solution
29	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.
30
31	3. List Key Features
32	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.
33
34	4. Define Success Metrics
35	Connect the solution to measurable outcomes. How will you know if this works? Reference metrics from the problem statement and set targets.
36
37	5. Acknowledge Trade-offs
38	Document what you're explicitly NOT doing and why. Good solution briefs are honest about scope limitations and alternatives that were considered but rejected.
39
40	6. Identify Risks and Mitigations
41	Surface the biggest risks to success and your plan to address them. This builds stakeholder confidence and surfaces concerns early.
42
43	7. Outline Next Steps
44	Provide 3-5 immediate actions to move the solution forward. Be specific about who does what.
45
46	## Output Format
47
48	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.
49
50	## Quality Checklist
51
52	Before finalizing, verify:
53
54	- [ ] Brief fits on one page when printed (approximately 500-700 words)
55	- [ ] Problem recap is concise (2-3 sentences maximum)
56	- [ ] Solution description avoids technical jargon
57	- [ ] Features are limited to 3-5 essential capabilities
58	- [ ] Trade-offs are explicitly stated
59	- [ ] Next steps are specific and actionable
60
61	## Examples
62
63	See `references/EXAMPLE.md` for a completed example.

People who liked this also viewed

6 picks

Type

develop-solution-brief

486stars64forks

View on GitHub

How to install develop-solution-brief?

product-on-purpose/pm-skills/develop-solution-brief

$npx -y skills add product-on-purpose/pm-skills --skill develop-solution-brief

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	<!-- PM-Skills \| https://github.com/product-on-purpose/pm-skills \| Apache 2.0 -->
2	# Solution Brief
3
4	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.
5
6	## When to Use
7
8	- Pitching a solution approach to stakeholders for buy-in
9	- Aligning cross-functional teams on what you're building and why
10	- Documenting solution intent before detailed PRD writing
11	- Comparing multiple solution options at a high level
12	- Communicating product direction to leadership
13
14	## When NOT to Use
15
16	- Stakeholders are aligned and engineering needs the full specification -> use `deliver-prd`; the brief pitches, the PRD specifies
17	- The problem is not yet framed or agreed -> use `define-problem-statement` first
18	- You are recording a decision already made -> use `develop-adr` (technical) or `develop-design-rationale` (design)
19	- You need to compare strategic options across the whole business model -> use `foundation-lean-canvas`
20
21	## Instructions
22
23	When asked to create a solution brief, follow these steps:
24
25	1. Recap the Problem
26	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.
27
28	2. Describe the Proposed Solution
29	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.
30
31	3. List Key Features
32	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.
33
34	4. Define Success Metrics
35	Connect the solution to measurable outcomes. How will you know if this works? Reference metrics from the problem statement and set targets.
36
37	5. Acknowledge Trade-offs
38	Document what you're explicitly NOT doing and why. Good solution briefs are honest about scope limitations and alternatives that were considered but rejected.
39
40	6. Identify Risks and Mitigations
41	Surface the biggest risks to success and your plan to address them. This builds stakeholder confidence and surfaces concerns early.
42
43	7. Outline Next Steps
44	Provide 3-5 immediate actions to move the solution forward. Be specific about who does what.
45
46	## Output Format
47
48	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.
49
50	## Quality Checklist
51
52	Before finalizing, verify:
53
54	- [ ] Brief fits on one page when printed (approximately 500-700 words)
55	- [ ] Problem recap is concise (2-3 sentences maximum)
56	- [ ] Solution description avoids technical jargon
57	- [ ] Features are limited to 3-5 essential capabilities
58	- [ ] Trade-offs are explicitly stated
59	- [ ] Next steps are specific and actionable
60
61	## Examples
62
63	See `references/EXAMPLE.md` for a completed example.

People who liked this also viewed

6 picks

Type