| name | writing-product-briefs |
| description | Write Product Briefs that align teams on goals before discovery. Use when defining a new product vision, articulating problem statements, creating one-pagers, or crafting north star scenarios. Produces vision documents with thesis/antithesis, target audience, metrics, and narrative scenarios. |
Product Brief Writing
Create vision documents that get everyone aligned on goals. A Product Brief unblocks discovery by giving a clear, intuitive idea of what we're trying to accomplish—before diving into requirements or solutions.
When This Skill Applies
- Starting a new product or major initiative
- Articulating a problem statement or vision
- Creating a "one-pager" or "problem brief"
- User asks for "north star scenarios" or "product thesis"
- Need to align stakeholders before writing requirements
- Converting vague product ideas into clear direction
Quick Start
Minimum viable path:
- Ask the user about the problem, current state, and stakes.
- Draft a thesis (specific, falsifiable claims) and an antithesis (honest risks).
- Name 1-3 personas and define adoption, value, and business metrics with baselines and targets.
- Write 3-5 north star scenarios in narrative form, including at least one failure or escalation case.
- Review the brief for completeness and run a readability polish with the
writing-for-humans skill. See Phase 5 in workflow-phases.md.
- Present, iterate, and stop when the brief enables action.
Fall through to the detailed phases below for prompts, anti-patterns, and review checks.
When Invoked
This skill is auto-loaded when its description matches the user's request, can be invoked directly via the Skill tool, or is triggered indirectly when the user runs the companion /product-brief slash command.
When the skill loads without an explicit topic, ask the user what product or initiative they want to define. Accept any of:
- A problem they're trying to solve
- A product idea to explore
- An existing initiative needing clarity
Then guide them through thesis, audience, metrics, and north star scenarios using the phases below.
Core Principles
- Vision over Requirements: Describe what success looks like, not how to build it
- Narrative over Lists: Use stories (north star scenarios) to make goals intuitive
- Honest Assessment: Include antithesis/risks—what could cause this to fail
- Outcome-Focused Metrics: Track value delivered, not features shipped
- Focus over Breadth: A complete brief is one that enables action, not one that covers everything
Process Overview
┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐
│ Discovery │──▶│ Thesis │──▶│ Metrics │──▶│ Scenarios │──▶│ Review │
│ │ │ │ │ │ │ │ │ │
│ Problem & │ │ Claims & │ │ Goals & │ │ North │ │ Complete │
│ context │ │ risks │ │ tracking │ │ star │ │ & polish │
│ │ │ │ │ │ │ stories │ │ │
└───────────┘ └───────────┘ └───────────┘ └───────────┘ └───────────┘
For detailed phase instructions, see workflow-phases.md. Phase 5 uses the writing-for-humans skill for the polish step. Several phases recommend named thinking patterns (atomic-thought, tree-of-thoughts, skeleton-of-thought, chain-of-thought, graph-of-thoughts, self-consistency); see the thinking-patterns skill for pattern details.
Output Template
# Product Brief for [Product Name]
[Brief vision statement—what this product will do and why it matters.]
## Product Thesis
We make [N] basic claims:
**[Claim 1 Title]**
[Explanation of claim and why it will work]
**[Claim 2 Title]**
[Explanation of second claim]
## Antithesis/Risks
What might cause this to not work as we expect?
- [Risk 1]
- [Risk 2]
- [Risk 3]
## Target Audience
We have [N] target personas:
**[Persona Name]**
[Description of persona, their situation, and primary goal]
**[Second Persona]**
[Description]
## Product Goals
[Summary of primary goals]
**Adoption metric**
[Specific metric with baseline → target]
**Value metric**
[Outcome metric with baseline → target]
**KPI**
[Business metric and expected direction]
## North Star Scenarios
**[Scenario 1 Title]**
[Narrative story with persona, situation, interaction, resolution, value capture]
**[Scenario 2 Title]**
[Second narrative story]
**[Scenario 3 Title]**
[Third narrative story, including at least one failure/escalation case]
Example
For a complete example, see kabletown-example.md.
Key elements demonstrated:
- Two clear thesis claims (reduced frustration, lowered toil)
- Specific, falsifiable risks
- Named personas (Tinker Tia, Sad Lisa)
- Metrics with current baselines and targets
- Five scenarios covering happy paths, edge cases, and escalation
Anti-Patterns
Vague Thesis
Bad: "Our product will be better than competitors"
Bad: "Users will love it"
Good: "Users will resolve issues faster because the assistant
understands intent better, getting handoff decisions right
80% more often than the current system"
Missing Antithesis
Bad: [No risks section]
Bad: "Minor risks: timeline might slip"
Good: "The assistant might take actions it shouldn't, causing users
to be unpleasantly surprised—which would increase frustration
instead of reducing it"
Feature-as-Goal
Bad: "Launch feature X by Q2"
Bad: "Ship mobile app"
Good: "Increase fully automated support interactions from 15% to 65%"
Scenario Without Value Capture
Bad: "User does the thing and it works. The end."
Good: "Once the technician reports install complete, Helpy checks
back with her to do a survey."
Implementation in Scenario
Bad: "She clicks the blue 'Help' button which opens a modal with
a WebSocket connection to our support API..."
Good: "She sees the Helpy button and asks what's going on. Helpy
checks her address against the outage map..."
Tips for Better Briefs
- The brief is complete when it enables action, not when it's comprehensive
- Thesis claims should make you slightly nervous—if they're too safe, dig deeper
- Every scenario should reveal at least one requirement you hadn't explicitly listed
- If you can't demo a scenario, it's too abstract
- Revisit the brief when scenarios reveal gaps in thesis or metrics
