Develop Solution Brief
- 507 installs
- 518 repo stars
- Updated August 4, 2026
- product-on-purpose/pm-skills
develop-solution-brief is a Claude Code product-management skill that creates a concise one-page solution overview with key features, success metrics, trade-offs, and risks for developers who need stakeholder buy-in befo
About
develop-solution-brief is a pm-skills agent skill (version 2.1.0) that generates a one-page solution document from references/TEMPLATE.md acting as the bridge between problem framing and detailed specification. The skill produces a problem recap, proposed solution in non-technical language, 3-5 essential features, success metrics, acknowledged trade-offs, risks with mitigations, and specific next steps within a 500-700 word constraint. Developers reach for develop-solution-brief when pitching an approach to stakeholders, aligning cross-functional teams, or comparing solution options at a high level before deliver-prd. It explicitly defers to define-problem-statement when the problem is not yet framed and to deliver-prd when engineering needs full specification. The output forces clarity by limiting scope and naming what the team is not building.
- develop-solution-brief
- AI & Agent Building
- AI-coding skill
Develop Solution Brief by the numbers
- 507 all-time installs (skills.sh)
- +31 installs in the week ending Aug 4, 2026 (Skillselion tracking)
- Ranked #1,755 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/product-on-purpose/pm-skills --skill develop-solution-briefAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 507 |
|---|---|
| repo stars | ★ 518 |
| Last updated | August 4, 2026 |
| Repository | product-on-purpose/pm-skills ↗ |
How do you write a one-page solution brief?
Helps with ai & agent building tasks.
Who is it for?
Engineers and product leads who need a concise stakeholder pitch before investing in a full PRD or engineering sprint.
Skip if: Teams that already have stakeholder alignment and need detailed engineering specification rather than a high-level approach summary.
When should I use this skill?
A developer needs to pitch a solution approach, align teams on what to build, or document solution intent before PRD writing.
What you get
A one-page solution brief with problem recap, proposed solution, 3-5 key features, success metrics, trade-offs, risks, mitigations, and actionable next steps.
- One-page solution brief
- Scoped feature list with trade-offs
By the numbers
- Skill version 2.1.0 targeting 500-700 words on one page
- Constrains output to 3-5 essential features per brief
Files
<!-- 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-statementfirst - You are recording a decision already made -> use
develop-adr(technical) ordevelop-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.
{
"schema": 1,
"skill": "develop-solution-brief",
"runs_per_query": 3,
"trigger_threshold": 0.5,
"queries": [
{
"q": "Write a one-page solution brief for the in-app referral program",
"expect": "trigger",
"split": "train"
},
{
"q": "I need something short that gets leadership aligned on our approach to self-serve onboarding before we write the full spec",
"expect": "trigger",
"split": "train"
},
{
"q": "Pitch the proposed fix for cart abandonment to stakeholders: the approach, key features, and what we are explicitly not doing",
"expect": "trigger",
"split": "train"
},
{
"q": "Summarize the proposed offline mode solution on one page, with success metrics and risks, ahead of the steering meeting",
"expect": "trigger",
"split": "train"
},
{
"q": "We have three candidate approaches to notification overload. Draft a brief that recommends one and shows the trade-offs.",
"expect": "trigger",
"split": "train"
},
{
"q": "Engineering and design keep describing different products. Put the intended solution on a single page so everyone aligns before PRD work starts.",
"expect": "trigger",
"split": "train"
},
{
"q": "Draft a solution overview for the AI-assisted search feature I can socialize with the VP before detailed spec work",
"expect": "trigger",
"split": "validation"
},
{
"q": "Create a concise pitch doc for replacing our CSV export with a reporting API: problem recap, approach, metrics, next steps",
"expect": "trigger",
"split": "validation"
},
{
"q": "Before we invest a quarter in the partner portal, I want a one-pager that states what we would build, why, and the biggest risks",
"expect": "trigger",
"split": "validation"
},
{
"q": "Turn this messy solution discussion thread into a tight one-page brief for stakeholder buy-in",
"expect": "trigger",
"split": "validation"
},
{
"q": "Stakeholders signed off on the approach last week. Now write the full requirements document engineering needs to build the referral program.",
"expect": "no-trigger",
"split": "train",
"near_miss_of": "deliver-prd",
"notes": "Alignment exists; the ask is the full specification"
},
{
"q": "We keep arguing about what problem the churn work is even solving. Frame the problem, the user impact, and success criteria first.",
"expect": "no-trigger",
"split": "train",
"near_miss_of": "define-problem-statement",
"notes": "Problem not yet framed; brief comes after"
},
{
"q": "Record the decision we already made to build the export pipeline on Kafka, with its consequences",
"expect": "no-trigger",
"split": "train",
"near_miss_of": "develop-adr",
"notes": "Decision already made and technical; ADR records, brief pitches"
},
{
"q": "Score these five feature ideas with RICE and ICE and tell me where the rankings disagree",
"expect": "no-trigger",
"split": "train"
},
{
"q": "Write a SQL query to find users who churned in the last 90 days",
"expect": "no-trigger",
"split": "train"
},
{
"q": "Estimate the TAM, SAM, and SOM for our scheduling tool in the European market",
"expect": "no-trigger",
"split": "train"
},
{
"q": "Compare two strategic options for the whole business side by side: problem, channels, revenue model, unfair advantage",
"expect": "no-trigger",
"split": "validation",
"near_miss_of": "foundation-lean-canvas",
"notes": "Whole-business-model comparison, beyond a solution brief"
},
{
"q": "Break the agreed solution into user stories with acceptance criteria for sprint planning",
"expect": "no-trigger",
"split": "validation"
},
{
"q": "Draft the employment contract for our new senior PM hire",
"expect": "no-trigger",
"split": "validation"
},
{
"q": "Write up what we learned from the two-day prototype spike on real-time collaboration",
"expect": "no-trigger",
"split": "validation",
"near_miss_of": "develop-spike-summary",
"notes": "Documenting exploration results, not proposing a solution"
}
]
}
develop-solution-brief - Version History
| Version | Date | Release | Effort | Type | Summary |
|---|---|---|---|---|---|
| 2.1.0 | 2026-06-10 | v2.26.0 | F-12-batch-2 | minor | Quality convergence: When NOT to Use + output-contract enumeration (F-12 Batch 2) |
| 2.0.0 | 2026-01-26 | - | - | baseline | Prior published version |
2.1.0 (2026-06-10)
Quality-convergence minor (F-12 Batch 2): added a "When NOT to Use" section with boundary pointers to neighboring skills, and the Output Format now enumerates the template sections a complete artifact fills. No template or example changes.
2.0.0 (2026-01-26)
Baseline row for the prior published version; see git history for its changes.
Solution Brief: Streamlined Mobile Checkout
Problem Recap
Mobile shoppers abandon checkout at a 73% rate, significantly higher than desktop's 45%. Users cite confusing multi-step flows, small form fields, and unexpected shipping costs as primary frustrations. This represents a $177M annual revenue opportunity.
Proposed Solution
We will redesign mobile checkout as a single-page experience with progressive disclosure. Instead of navigating through multiple screens, shoppers will complete their purchase on one streamlined page that expands sections as needed. The design prioritizes large touch targets, saved payment methods, and upfront shipping transparency.
Key Features
1. Single-Page Checkout: All checkout steps visible on one page with accordion sections that expand/collapse. Users always see their progress and can edit any section without losing data.
2. Express Payment Options: Apple Pay, Google Pay, and PayPal one-tap buttons prominently displayed at top. Returning customers can checkout in under 30 seconds.
3. Upfront Shipping Calculator: Shipping costs displayed based on cart contents before checkout begins. No surprise costs at the final step.
4. Smart Form Fields: Large, mobile-optimized input fields with auto-formatting (phone, credit card). Address autocomplete via Google Places API reduces typing by 70%.
5. Guest Checkout Persistence: Cart and partially-entered information saved for 7 days, allowing users to return and complete purchase without starting over.
Success Metrics
| Metric | Current | Target | Timeline |
|---|---|---|---|
| Mobile checkout abandonment | 73% | 60% | Q1 2026 |
| Mobile checkout completion time | 4.2 min | 2.0 min | Q1 2026 |
| Express payment adoption | 0% | 25% | Q2 2026 |
Trade-offs Considered
| What We're Not Doing | Why |
|---|---|
| Removing guest checkout | Legal requirement in EU markets; also helps first-time buyers |
| Cross-sell/upsell in checkout | User research shows this adds friction; moving to cart instead |
| Custom payment form design | Payment provider contract limits changes until March |
| Cryptocurrency payment | Low demand (<1% of requests); complexity not justified |
Risks & Mitigations
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Apple Pay integration delays | Medium | High | Parallel-path with card-only fallback; engage Apple early |
| Page load performance on single-page | Medium | Medium | Lazy-load sections; aggressive image optimization |
| User confusion with accordion UX | Low | Medium | A/B test against step-based alternative; quick iteration |
Next Steps
1. Finalize UI mockups and get stakeholder approval - Design Lead, Jan 20 2. Scope technical requirements with engineering - PM + Tech Lead, Jan 22 3. Begin Apple Pay sandbox integration - iOS Engineer, Jan 25 4. Plan A/B test framework and success criteria - PM + Data, Jan 27 5. Draft user communication for checkout change - Marketing, Feb 1
Solution Brief: [Solution Title]
Problem Recap
<!-- 2-3 sentences maximum. Reference the problem statement for details. -->
[Concise summary of the problem being solved]
Proposed Solution
<!-- Clear description of what you're building. Focus on user experience, not implementation. -->
[Solution description in plain language]
Key Features
<!-- 3-5 essential features. These are the minimum set needed to solve the problem. -->
1. [Feature Name]: [One-sentence description of what it does and why it matters]
2. [Feature Name]: [One-sentence description of what it does and why it matters]
3. [Feature Name]: [One-sentence description of what it does and why it matters]
4. [Feature Name]: [One-sentence description of what it does and why it matters]
5. [Feature Name]: [One-sentence description of what it does and why it matters]
Success Metrics
| Metric | Current | Target | Timeline |
|---|---|---|---|
| [Primary metric] | [Baseline] | [Goal] | [By when] |
| [Secondary metric] | [Baseline] | [Goal] | [By when] |
Trade-offs Considered
<!-- What are you explicitly NOT doing? What alternatives were rejected? -->
| What We're Not Doing | Why |
|---|---|
| [Scope exclusion 1] | [Rationale] |
| [Scope exclusion 2] | [Rationale] |
| [Alternative rejected] | [Why not chosen] |
Risks & Mitigations
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| [Risk 1] | High/Med/Low | High/Med/Low | [How we'll address it] |
| [Risk 2] | High/Med/Low | High/Med/Low | [How we'll address it] |
Next Steps
<!-- 3-5 immediate actions. Be specific about who does what. -->
1. [Action] - [Owner], [Timeline] 2. [Action] - [Owner], [Timeline] 3. [Action] - [Owner], [Timeline]
Related skills
Setup Matt Pocock SkillsScaffold the per-repo configuration that Matt Pocock’s engineering agent skills rely on so they understand the issue tracker, triage labels, and domain documentation la495k196k
Lark AppsConnect Claude, Cursor or custom agents directly to Lark (Feishu) for messaging, document automation, approval workflows and enterprise data access.402k
CavemanSlash token usage by roughly 75% while keeping every technical detail intact when working with Claude Code, Cursor or similar agents.391k94.7k
Lark Skill MakerQuickly turn any Lark/Feishu OpenAPI call or multi-step workflow into a reusable agent skill with its own SKILL.md.386k16k
Running Claude Code Via Litellm CopilotRun Claude Code at a fraction of the cost by routing requests through LiteLLM to the GitHub Copilot Chat API.270k72
Codex PetGenerate a complete Codex Pet spritesheet and metadata from one reference image without needing an OpenAI key or Codex Pro.246k10How it compares
Use develop-solution-brief for stakeholder alignment on approach; move to deliver-prd when engineering needs implementation-level detail.
FAQ
How long should a develop-solution-brief output be?
develop-solution-brief targets a one-page brief of approximately 500-700 words. The constraint forces focus on 3-5 essential features and explicit trade-offs rather than exhaustive specification.
When should develop-solution-brief replace a PRD?
develop-solution-brief does not replace a PRD. It aligns stakeholders on approach and scope first; use deliver-prd afterward when engineering needs full detailed specification.
What must develop-solution-brief include?
develop-solution-brief fills seven template sections: problem recap, proposed solution, key features, success metrics, trade-offs, risks and mitigations, and specific next steps with owners.