product-brief

name	product-brief
description	Draft a concise business-case document covering problem statement, target users, success metrics, key risks, and high-level approach. Invoke when the user needs a structured business case before or during project initiation.

Adapted from bmad-method:bmad-product-brief (MIT, © 2025 BMad Code, LLC). See THIRD_PARTY_NOTICES.md.

When to use

Use this skill to produce a 1–3 page structured business case that frames the project before detailed planning begins. Typical triggers include:

• A sponsor or steering committee requires a written rationale for the project before approving initiation
• The team has a concept memo or brainstorming output and needs to sharpen it into a presentable brief
• A charter is being drafted and a companion problem-framing document is required
• A project review reveals that the original business case was never formally documented

Do not invoke for detailed requirements work; prefer the prd skill for that. Do not invoke to replace the project charter — the brief precedes or accompanies the charter, it does not substitute for it.

Summon the SME

Before facilitating, load the canonical business-case reference to ground the brief in established practice.

Reading the config. Check .pm-kit.config.json for the sourcesMode field:

• If sourcesMode is "online" (opt-in): fetch the URL stored at the key sources.productBrief in vendor/pm-kit/sources-index.json using your available web-fetch capability. Do not name a specific tool — use whatever your runtime provides. Ground the facilitation in what you read. Do not fabricate quotations or page numbers.
• If sourcesMode is "offline" or the field is absent (the default): rely on your general knowledge of business-case and product-brief construction, drawing on the Lean Canvas structure (problem, customer segments, solution, metrics, cost structure). Cite the canonical URL from vendor/pm-kit/sources-index.json at key sources.productBrief in the output. Do not fabricate quotations or page numbers.

In both cases, the URL to cite is https://leanstack.com/lean-canvas.

Facilitation script

Walk the user through these steps in sequence. Do not skip steps or combine them.

Step 1 — Inputs. Ask the user to share any available input: a concept memo, brainstorming outputs, an early draft, or a verbal description of the idea. Accept any format. If no inputs exist, ask the user to describe the project idea in their own words before proceeding.

Step 2 — Problem statement. Ask: "What problem does this project solve, and for whom? Describe the pain in concrete terms — what happens today without this solution?" Confirm the answer is specific and observable before moving on.

Step 3 — Target users. Ask: "Who are the primary users or beneficiaries? Describe them — their role, context, and what they care about." If secondary users exist, capture them too. Aim for brief persona sketches, not exhaustive profiles.

Step 4 — Desired outcomes and metrics. Ask: "What does success look like? What measurable change in user behavior or business outcome indicates this project worked?" Prompt for at least two concrete success metrics.

Step 5 — Key risks and unknowns. Ask: "What could prevent this project from succeeding? What assumptions are you most worried about?" Capture at least two risks and note which are verified versus assumed.

Step 6 — High-level approach. Ask: "How do you plan to address the problem? Describe the solution at a high level — not the full design, but the core approach." Capture the main bets being made.

Step 7 — Open questions. Ask: "What important questions remain unanswered at this stage?" Capture them without attempting to resolve them — they belong in the document as-is.

Step 8 — Output. Produce the completed brief using the structure in TEMPLATE.md (sibling file). Fill every section. Leave no placeholder unfilled.

Step 9 — Save the artifact. Save the filled artifact to docs/pm-kit/outputs/product-brief/<short-slug>.md. <short-slug> is a kebab-case ASCII slug (max 40 chars) derived from the project name (e.g., bookswap-campus). Confirm the final path with the user before writing. If the file exists, ask: overwrite, append a date suffix (e.g., -2026-04-20), or pick a new slug. The artifact begins with the three-line provenance header below (HTML comments, do not render):

<!-- Generated by agentic-pm-kit:product-brief on YYYY-MM-DD -->
<!-- Languages: communication=<value>, output=<value> -->
<!-- Source mode: offline | online -->

Languages

The kit separates the language used for live agent–user dialogue from the language used in the saved artifact. Both values live in .pm-kit.config.json and are free-form strings — read each value verbatim, never infer a language from the conversation, and never select from a hardcoded list.

Facilitation dialogue. Speak to the user during facilitation in the language at language.communication. Use the string verbatim.

Filled artifact (saved TEMPLATE.md output). Produce the written artifact in the language at language.output. If language.output is absent or empty, fall back to language.communication.

Example values either field might contain: "en-US", "es-MX", "Português brasileiro", "Mandarin Chinese". Accept any string as given. This bifurcation is the normative pattern for every skill in the kit.

Acceptance gate

When the brief is complete, point the user to CHECKLIST.md (sibling file) and ask them to verify each item. Remind them that the output must be marked PASS or FAIL. On FAIL, invite the user to return with specific notes so the facilitation can be resumed or corrected.