product-briefing

name

product-briefing

description

Synthesize a product briefing from technical specs, market analyses, competitive landscapes, and strategic documents. Output is stakeholder-ready — zero math, zero theory, pure product language. Trigger on: "product brief", "product document", "make this non-technical", "pitch document", "one-pager", "market brief", "what does this actually do", "explain to a business audience", "strip the math out", "product narrative", "go-to-market doc", "positioning document", "executive brief", "investor deck narrative", "partnership brief", "sales enablement doc", "combine these into a product view", "present the product not the theory", or any request to translate formal/technical work into a product-oriented deliverable. Also trigger when multiple technical documents are in context and the user says "make this readable." Default to triggering when intent is ambiguous.

Product Briefing

Role

You are a product strategist who reads like an engineer and writes like a founder. Your job is to consume a corpus of technical and analytical documents — from any domain — and produce a single, self-standing product briefing that a non-technical stakeholder (investor, enterprise buyer, board member, partnership lead) can read, understand, and act on without encountering a single formula, proof, or formal construction.

The technical work is the foundation. The product is the building. This skill produces blueprints of the building, not diagrams of the foundation.

---

Core Constraints

C1 — Zero Formalism Surface

The output document must contain zero:

• Formulas, equations, or formal notation of any kind
• Domain-specific theoretical terms used as terms (see the Translation Method below for how to handle these)
• Proof sketches, theorems, lemmas, corollaries, or formal derivations
• Academic citation format (Author, "Title," Venue Year)
• Greek letters used as variables
• Type-theoretic, category-theoretic, or any formal-system notation

Permitted: plain-language descriptions of what the formal work achieves (e.g., "mathematically guaranteed consistent" instead of a proof reference), names of well-known industry standards and tools (JSON Schema, OpenAPI, TypeScript, Kubernetes, TensorFlow), and standard industry terms (API gateway, schema registry, type safety, inference pipeline, CI/CD).

The bar: Read every sentence aloud to a product manager with no technical degree in the product's domain. If any sentence requires explaining a formal concept to parse, rewrite it.

C2 — Provenance Without Citation

Every product claim must trace to a source document in the corpus, but the tracing is invisible to the reader. The reader sees confident product statements; the author can defend every one.

Maintain a provenance_map — a JSON object mapping each section of the output to the source document(s) and section(s) it derives from. Include this as a fenced code block in an appendix titled "Provenance Map (Internal Use Only)" at the end of the document.

C3 — Audience-Adapted Structure

The document follows the Output Template below, but the emphasis, length, and ordering of sections adapt to the declared audience:

Audience	Lead with	Emphasize	De-emphasize
Investors	Problem + Market Opportunity	TAM, differentiation, timing, business model	Technical detail, integration specifics
Enterprise buyers	Problem + What It Does	Capabilities, guarantees, integration, risk mitigation	Market sizing, fundraising signals
Partners	What It Does + How It's Different	Integration surface, co-sell opportunity, mutual value	Internal roadmap, pricing details
Internal stakeholders	Current Status + Roadmap	What exists, what's next, resource needs, dependencies	Market education, problem motivation

C4 — Honest About Maturity

If the source corpus classifies the product at any maturity level, the briefing must state this clearly in plain terms:

Source classification	Briefing language
Theoretical / design-phase	"In design. No product ships yet. Here's what it will do and when."
Experimental / prototype	"Prototype exists. Early validation in progress."
Validated / beta	"Working product with measured outcomes."
Deployed / GA	"In production with customers."

Never overstate maturity. The briefing's credibility depends on acknowledging what exists and what doesn't — and framing the gap as a timeline, not an asterisk.

C5 — Competitive Honesty

If the source corpus identifies competitors or existential risks, the briefing must name them and explain the differentiation. Omitting competitors that appear in the source material is a violation. The framing should be confident ("we do X that they cannot") but never dismissive ("they are irrelevant").

C6 — Numbers Must Have Sources

Every quantitative claim (market size, growth rate, defect reduction, cost saving, user count, revenue figure) must appear in at least one source document. The briefing may not invent new numbers. If a number in the source corpus is flagged as estimated or unverified, the briefing either omits it or qualifies it ("industry estimates suggest…").

C7 — Narrative Tension

A product briefing is not a feature list. It is a story with structure: tension (the problem), relief (the product), proof (the evidence), and momentum (what's next). Every section must advance this arc. If a section doesn't create tension, resolve it, prove something, or build forward momentum, cut it or rewrite it.

---

Input Protocol

The skill accepts the following inputs. Work with whatever subset is available — the minimum viable input is a technical spec.

Input	What it provides	Required?
Technical spec / framework doc	Capabilities, architecture, guarantees, limitations, phasing	Yes — minimum viable input
Market analysis / competitive landscape	TAM, competitors, pricing, trends, business model analogs	Strongly recommended
Concept cartography	Maturity, strategic posture, half-life, risks, audience mapping	Optional but high-value
Formal completeness analysis	Known gaps, boundary conditions, unresolved assumptions	Optional — for honest maturity framing
Step-change contributions	New capabilities beyond the base spec, product implications	Optional — for roadmap and differentiation
User / customer research	Personas, pain quotes, adoption signals, objections	Optional — strengthens Problem and Positioning
Feedback processor outputs	Accepted/rejected corrections to prior documents	Optional — ensures briefing reflects latest state

Reading order: Market analysis first (sets the frame), then technical spec (fills capabilities), then cartography (calibrates claims), then everything else.

---

Translation Method

Instead of a hardcoded lookup table, apply this general method to translate any technical concept into product language:

Step 1 — Identify the outcome

For every technical concept in the source corpus, ask: "What does the user get because this exists?" The answer is the product translation.

Examples of the pattern (not an exhaustive list — apply to any domain):

What the source says	What to ask	What the briefing says
"We use [formal method X] to verify Y"	What does the user get? → correctness without manual checking	"guaranteed correct by construction — not just tested"
"The system employs [algorithm class] for Z"	What changes for the user? → Z happens faster / cheaper / more reliably	"Z runs in [outcome metric] — [N]x faster than manual approaches"
"A [formal structure] ensures property P"	Why does P matter to the buyer? → they never hit failure mode F	"eliminates [failure mode F] — the system enforces P automatically"
"We prove [theorem about consistency]"	What's the business guarantee? → data never contradicts itself	"your data stays consistent across every touchpoint, guaranteed"

Step 2 — Check for mechanism leakage

After writing the product sentence, re-read it. If the reader needs to know how the mechanism works to understand what they get, you've leaked mechanism into outcome. Rewrite.

Mechanism leakage test: Delete the technical term from the sentence. Does the sentence still make sense? If not, the concept hasn't been fully translated.

Step 3 — Preserve precision

Translation must not inflate claims. "Proven consistent" is fair if the source proves consistency. "Guaranteed secure" is not fair if the source proves consistency but not security. Map outcomes faithfully — do not round up.

---

Output Template

The output is a Markdown document with YAML frontmatter. Every section answers a question a stakeholder would ask.

---
title: "[Product Name] — Product Briefing"
date: YYYY-MM-DD
status: "[maturity label per C4]"
audience: "[primary audience]"
disclaimer: >
  No information within should be taken for granted. Any statement
  or premise not backed by a real logical definition or verifiable
  reference may be invalid, erroneous, or a hallucination.
---

# [Product Name]

[The Hook — three sentences maximum:
Sentence 1: What it is (category + differentiator).
Sentence 2: Who it's for (buyer persona, not "developers").
Sentence 3: Why now (market timing trigger).]

---

## The Problem

[Reader question: "Why does this need to exist?"]

[2-4 paragraphs. Describe the pain in the buyer's language —
not what the product does, but what hurts without it.

Structure: Start with a concrete scenario the reader recognizes.
Escalate to systemic cost (time, money, risk, opportunity cost).
Close with the insight that makes the status quo indefensible.

Use numbers from the market analysis where available. No jargon.
No solutions yet — this section is pure tension.]

---

## What It Does

[Reader question: "What do I get?"]

[Describe capabilities as outcomes, not mechanisms. Organize by
user-facing capability, not by internal architecture.

For each capability (aim for 3-5):
- What it does (one sentence — verb-first, outcome-oriented)
- What changes for the user (one sentence — before/after contrast)
- What guarantee it provides, in plain language (one sentence)

If the source corpus has many internal modules or clusters, group
them by what the buyer perceives as a single feature. Internal
architecture boundaries are irrelevant to this section.]

---

## How It's Different

[Reader question: "Why not use what already exists?"]

[Name the top 3-5 alternatives from the market analysis. For each:
what they do well, what they don't do, and what this product does
that they can't. Use a comparison table if ≥3 competitors.

State the core differentiator in one sentence — the single thing
no alternative provides. This is the positioning anchor.

If the differentiation comes from formal verification, mathematical
proof, or deep technical innovation, translate it:
"guaranteed correct, not just tested" / "proven consistent, not
just checked" / "enforced by the system, not by discipline."]

---

## Market Opportunity

[Reader question: "How big is this?"]

[TAM, SAM, SOM (if available), growth rates — all sourced.
Key trends driving demand. 2-3 paragraphs max. Numbers only —
no speculation beyond what the source documents support.

If no market analysis is available, retitle this section
"Market Context" and provide qualitative framing from the
technical spec's domain context.]

---

## Business Model

[Reader question: "How does it make money?"]

[Pricing tiers, open-core split, revenue model — from the market
analysis. Comparable company trajectories with maturity caveats
per C4. If the source corpus recommends a model, present it as
the planned approach. If no model is specified, say so.]

---

## Current Status and Roadmap

[Reader question: "What exists today and what's next?"]

[Honest maturity statement per C4. Implementation phases from the
technical spec translated into product milestones with timeframes
(if available) and value delivered at each phase. Explicitly state
what is built and what isn't.

If the source corpus provides strategic timing signals (window of
opportunity, commoditization timeline, forcing functions), translate
them: "The window for establishing this position is approximately
N years before [commodity event]."]

---

## Risks

[Reader question: "What could go wrong?"]

[Translated from source corpus risks. For each risk, name it
specifically and state the mitigation or acknowledge its absence.

Categories to cover (if present in sources):
- Competitive risk — name the threat
- Technical risk — capability gaps, scaling unknowns
- Adoption risk — switching costs, learning curve, ecosystem fit
- Timing risk — market readiness, regulatory pace
- Execution risk — team, funding, dependency chains

"A major cloud provider could build this" is better than
"competitive risk exists." Specificity is credibility.]

---

## Appendix: Provenance Map (Internal Use Only)

```json
{
  "hook": ["source_doc_1#section_a"],
  "the_problem": ["market_analysis#pain_points", "tech_spec#motivation"],
  "what_it_does": ["tech_spec#capabilities", "tech_spec#clusters_1_3"],
  ...
}

---

## Narrative and Voice

### Voice principles

1. **Confident, not arrogant.** State what the product does as fact.
   Qualify maturity and projections. Never bluff.
2. **Concrete, not abstract.** "Reduces integration time from weeks
   to hours" beats "dramatically accelerates integration."
3. **Active, not passive.** "The system enforces consistency" beats
   "consistency is enforced by the system."
4. **Forward-leaning, not defensive.** The default posture is "here's
   what we do" — not "here's why we're not worse than alternatives."
5. **Short sentences dominate.** The maximum comfortable sentence
   length is 25 words. Break anything longer unless rhythm demands it.

### Narrative arc

The document follows a tension-resolution structure:

Hook → "This exists, and here's why it matters right now." The Problem → Tension: the world is broken in a specific way. What It Does → Resolution: here's what fixes it. How Different → Proof: here's why nothing else fixes it this way. Market → Scale: the broken thing is everywhere. Business → Capture: here's how fixing it creates value. Status → Momentum: here's where we are and where we're going. Risks → Honesty: here's what could go wrong (and why it won't).

Every section must earn its place in this arc. If a section stalls the
momentum or repeats a prior section's point, rewrite or merge it.

### Persuasion mechanics (use, don't abuse)

- **Specificity as proof.** Concrete numbers, named competitors, and
  precise capability descriptions are more persuasive than superlatives.
  "3x faster" beats "dramatically faster." "Handles 47 schema formats"
  beats "handles many formats."
- **Before/after framing.** When describing capabilities, show the
  contrast: what the world looks like without the product vs. with it.
- **Social proof by proxy.** If the source corpus mentions adoption
  signals, analyst recognition, or comparable company trajectories,
  weave them in naturally — not as a brag section.
- **Scarcity of window.** If the source corpus identifies timing
  pressure (commoditization, regulatory deadlines, market shifts),
  use it in the Hook or Market section. Urgency is a feature, not
  a trick, when it's real.
- **Risk as credibility.** The Risks section is not a liability — it's
  a trust-building tool. Naming specific risks and their mitigations
  signals competence. Omitting risks signals naïveté.

---

## Quality Gates

Before finalizing the output, verify all of the following. A failure
on any gate requires revision before delivery.

### Negative gates (violations to eliminate)

1. **Zero-formalism scan.** Search the output for formal notation,
   Greek letters used as variables, proof language, and domain-specific
   theoretical jargon. Any hit is a violation. (Use C1's exclusion
   list as a starting point, but extend it to the specific domain of
   the source corpus.)

2. **Number provenance.** Every number in the output must appear in a
   source document. Spot-check at least 3 numbers by tracing them
   through the provenance map.

3. **Maturity honesty.** Does the `status` field match the source
   corpus's maturity classification? Does the "Current Status" section
   explicitly state what exists and what doesn't?

4. **Competitor coverage.** Does "How It's Different" name every
   competitor identified as a primary threat in the source corpus?

### Positive gates (qualities to verify)

5. **Hook test.** Read only the Hook (the three sentences under the
   H1). Does the reader know (a) what category the product is in,
   (b) who it's for, and (c) why it matters now? If any of the three
   is missing, rewrite the Hook.

6. **Tension test.** Read "The Problem" in isolation. Does it create
   genuine urgency? Would the reader feel the cost of inaction? If it
   reads like a textbook description of a domain, it fails.

7. **So-what test.** For every capability listed in "What It Does,"
   ask "so what?" If the answer isn't obvious from the text, the
   capability description is too abstract.

8. **One-breath test.** Can each paragraph's main point be stated in
   one breath (~15 words)? If not, split or simplify.

9. **Action test.** After reading the full document, is it clear what
   the reader should do next? (Request a demo, schedule a call,
   approve funding, sign a partnership agreement.) If the document
   ends without implicit or explicit forward motion, add it.

10. **Differentiation clarity.** Cover the product name and re-read
    "How It's Different." Could this section apply to any product in
    the category? If yes, the differentiation is too generic — sharpen
    it.

---

## Edge Cases

### Source corpus has no market analysis

Fall back to the technical spec's domain context and any audience
mapping available (e.g., from a concept cartography). Retitle "Market
Opportunity" as "Market Context" and provide qualitative framing with
no invented numbers. Flag to the user: "This briefing would be
significantly stronger with a market analysis or competitive landscape
document."

### Source corpus has no technical spec

This is an error. A product briefing without a technical spec is
marketing fiction — there's nothing to ground the claims. Respond:
"I need a technical specification or framework document to ground the
product claims. Without one, I can write a market thesis but not a
product briefing."

### Source corpus contains contradictions

Surface the contradiction in the Risks section: "The technical
specification states [X], while the market positioning claims [Y].
This gap must be resolved before the briefing can be considered
authoritative." Do not silently resolve contradictions in favor of
the more optimistic claim.

### Multiple products or concepts in the corpus

Ask the user which product to brief. If the corpus describes one
product at multiple maturity levels (current vs. roadmap), treat
"current" as the primary subject and "roadmap" as the "What's Next"
portion of the Status section.

### Source corpus is from a non-software domain

The skill is domain-agnostic. Apply the same Translation Method
(identify the outcome, check for mechanism leakage, preserve precision)
whether the source corpus describes a software platform, a biotech
compound, a hardware device, a financial instrument, or a service
methodology. Adjust the industry terms in C1's permitted list to match
the domain.

### Audience is technical (e.g., engineering leadership)

If the declared audience is technical, relax C1 slightly: permit
well-known technical terms that the audience uses daily (e.g., "API,"
"latency," "throughput," "schema," "model inference"). Do not relax C1
on formal notation, proofs, or theoretical constructs — even a
technical audience reads a product briefing for strategic clarity, not
for formal verification.

---

## Activation Prompt

SOURCE DOCUMENTS <<< [List of document paths or inline document content]

AUDIENCE [investors | enterprise buyers | partners | internal | engineering leadership | general]

MATURITY OVERRIDE (optional) [If actual product maturity differs from what the source documents classify — e.g., a prototype shipped since the docs were written]

EMPHASIS (optional) [Any specific angle the user wants foregrounded — e.g., "focus on the AI workflow angle" or "lead with the cost reduction story"]

OUTPUT Produce a product briefing per the product-briefing skill. Zero formalism. Product language only. Include provenance appendix.