---
name: tidb-product-narrative
description: >-
  Guides product managers in producing a product narrative brief — the technical
  facts layer that feeds PMM's messaging platform. Covers use case definition,
  feature framing for external communications, technical proof points, and the
  critical "what this is NOT" section that prevents overclaiming. Use before a
  product launch, feature announcement, or whenever PM needs to hand off product
  context to PMM for external communications.
---

# TiDB product narrative

**Role:** Product Narrative Author (PM). You are not writing marketing copy — you are writing a technical brief that PMM will translate into market language. Your job is precision: capabilities that are GA, limitations that are real, use cases that are validated. PMM's job is to make it compelling. Your job is to make sure it's true.

---

## The PM → PMM handoff problem

Most GTM messaging failures trace back to the PM-to-PMM handoff:
- PM hands over a feature spec → PMM writes positioning that overclaims
- PM doesn't document limitations → PMM publishes claims that engineers will disprove
- PM uses internal naming → external messaging confuses customers on product tiers

This skill structures the handoff so both sides are working from the same facts.

---

## 1. Before writing

Confirm the following:

- [ ] Feature or capability is GA (generally available), not roadmap — label clearly if in preview/beta
- [ ] TiDB version and tier (Cloud Starter / Cloud Essential / Cloud Dedicated / Self-Managed) this applies to
- [ ] At least one real customer or design partner has validated this use case
- [ ] You've checked the compatibility docs for known limitations
- [ ] Legal/security has cleared any claims you want to make externally

---

## 2. Use case definition

State the specific scenario this product capability addresses. Not the feature — the customer's situation.

**Format:**
```
Use case: [one sentence — the customer situation]
Who experiences this: [role + company type + scale context]
What they're doing today without this: [current workaround or alternative]
Why the current approach breaks down: [specific failure mode — not "it's inefficient"]
What TiDB enables: [specific outcome, not capability name]
```

**Example (vector search for AI agents):**
```
Use case: An AI agent application needs to retrieve semantically similar historical interactions while simultaneously writing new interaction records and maintaining ACID consistency.
Who experiences this: Backend engineers at AI startups building multi-step agent workflows (e.g., customer support bots, coding assistants).
What they're doing today: Running a separate vector DB (Pinecone/Chroma) alongside a relational DB (PostgreSQL/MySQL), syncing between them via a pipeline.
Why the current approach breaks down: The sync pipeline introduces latency; reads and writes are not ACID-consistent across the two systems; operational complexity of two database systems slows iteration.
What TiDB enables: A single query that retrieves semantically similar vectors AND performs a transactional write, with ACID guarantees, eliminating the sync pipeline.
```

---

## 3. Capability framing for external use

| Component | What to write | What NOT to write |
|-----------|--------------|-------------------|
| **Capability name** | The official feature name (e.g., "native vector indexing") | Internal codename or jargon |
| **What it does** | Specific, measurable outcome in one sentence | "Enables powerful AI workloads" |
| **When to use it** | Specific trigger conditions | "For all AI applications" |
| **Requirements** | Minimum version, tier, configuration | Implied universality |
| **Known limitations** | Specific boundary conditions or known gaps | Omit entirely |

---

## 4. Technical proof points

Each external claim needs a grounding proof point. Use this table:

| Claim | Proof type | Specifics | Available externally? |
|-------|-----------|----------|----------------------|
| [claim] | customer case / benchmark / design partner / internal test | [details] | Yes / No / With approval |

Proof types in order of credibility (highest to lowest):
1. Named public customer case (like Manus, Atlassian, Plaid)
2. Anonymous validated customer case (design partner approved)
3. Internal benchmark with publicly auditable methodology
4. Internal test results (reference only; don't publish without methodology)

---

## 5. The "what this is NOT" section (mandatory)

Every product narrative brief must include explicit scope limitations. This is the section PMM may not write without PM input — and the section that prevents the most expensive GTM mistakes.

**Format:**
```
This is NOT a replacement for: [specific use case or product where TiDB is not the right choice]
This does NOT mean: [common misinterpretation to head off]
This does NOT apply to: [TiDB version, tier, or configuration where this doesn't work]
Known gaps: [specific limitations engineers will discover; better to say it than have them find it]
```

**Example:**
```
This is NOT a replacement for: Pure vector search at extreme scale (billions of vectors, no OLTP requirements) — Pinecone or Milvus will outperform TiDB's vector index on narrow vector-search benchmarks.
This does NOT mean: Full MySQL compatibility — TiDB supports the MySQL protocol with documented incompatibilities. Link: [compatibility docs URL].
This does NOT apply to: TiDB Cloud Starter free tier above [resource limit]; TiDB v7.x and below.
Known gaps: [specific known limitation from engineering]
```

---

## 6. Product narrative brief output format

```markdown
## Product Narrative Brief — [Feature/Capability Name] — [Date] — [TiDB Version/Tier]

### Status
[ ] GA   [ ] Preview/Beta   [ ] Coming soon — Target: [date]

### Use case
[One sentence]

### Target user
[Role + company type + scale context]

### Current workaround and why it breaks
[2-3 sentences]

### What TiDB enables
[1-2 sentences, specific outcome]

### Capability framing
| Capability | What it does | When to use | Requirements | Limitations |
|-----------|-------------|------------|-------------|------------|

### Proof points
| Claim | Proof | Can publish? |
|-------|-------|-------------|

### What this is NOT
- Not a replacement for: [specific]
- Does not mean: [common misinterpretation]
- Does not apply to: [version/tier/config exclusions]
- Known gaps: [engineer-validated limitations]

### Approved for PMM handoff: [Yes / No — if no, what's missing]
```

---

## Pairs with

- `tidb-messaging-platform` — this brief is the required upstream input for PMM
- `tidb-benchmark-narrative` — technical proof points in this brief may become benchmark content
- `tidb-brand-voice` — product names must match official naming throughout
- `tidb-content-review` — the "what this is NOT" section is checked during content review
- `@tidb-gtm-brain/knowledge/product.md` — official product context and terminology reference