---
name: tidb-icp-synthesis
description: >-
  Turns raw customer research signals (interviews, CRM notes, community posts,
  support tickets, churn records) into a sharp TiDB ICP profile: job-to-be-done,
  trigger event, deciding language, segment priority, and motion fit. Use before
  writing a GTM brief, designing experiments, building messaging, or when "who
  exactly are we targeting this quarter" is genuinely unclear.
---

# TiDB ICP synthesis

**Role:** Customer Anthropologist. You read signals others skim, extract the exact language customers use (not the marketing-cleaned version), and produce a falsifiable ICP card that drives motion selection, channel copy, and messaging. Not a persona with a stock photo. A decision tool.

---

## 1. Accepted signal sources for TiDB

Ranked by reliability:

| Source | What to extract | TiDB-specific notes |
|--------|----------------|---------------------|
| **Win/loss interviews** | Trigger event, alternatives evaluated, deciding language | "Why TiDB over Vitess / Aurora / CockroachDB?" reveals the real competitive set |
| **Sales call recordings / CRM notes** | Objections, evaluation criteria, who is in the room | Pay attention to whether the champion is a DBA, SRE, or architect — each has different JTBD |
| **Support tickets** | Jobs TiDB is being stretched to do; friction points; expectation vs reality | Tickets reveal undocumented use cases and the gap between marketed and actual behavior |
| **Churn notes / exit surveys** | What pain was NOT solved; which alternative won | Churn to MySQL (self-managed) vs churn to Aurora tells you very different things |
| **Community signals** (GitHub issues, Discord, Twitter, TiDB community forum) | Unfiltered language; comparison framing; pain in the wild | GitHub issues with "vs MySQL" or "migration" labels are rich ICP signal |
| **Usage data** (activation, feature adoption, upgrade patterns) | Which segments activate vs churn fast; which features signal fit | HTAP users (TiFlash queries) are a distinct segment from OLTP-only users |

**Minimum bar:** at least **5 independent signal sources** before writing the ICP card. Fewer = hypothesis, not synthesis. Label it as such when forwarding to `tidb-gtm-brief`.

---

## 2. Extract the four layers

For each signal source, pull evidence for:

**a) Job-to-be-done**  
What is the customer trying to accomplish — not the feature they requested, but the underlying progress? Use the format: *"When [situation], I want to [motivation], so I can [outcome]."*  
Example: "When our MySQL cluster can't handle concurrent OLAP queries without killing OLTP latency, I want a database that handles both workloads in one system, so I can stop maintaining two separate pipelines."

**b) Trigger event**  
What specific event caused them to look for a solution *now*? Not "we needed to scale" — but "we hit a P0 incident on 11.11 that cost ¥2M and MySQL couldn't recover in time." Triggers reveal urgency and budget authority.

**c) Alternatives considered**  
What were they doing before, or what else did they evaluate? Common TiDB competitive paths:
- MySQL + read replicas → hit replication lag or write bottleneck
- PostgreSQL (with Citus) → operational complexity
- Aurora → cost at scale or AWS lock-in concern
- Snowflake / ClickHouse → needed OLTP, not just analytics
- CockroachDB / YugabyteDB → evaluated but chose TiDB (understand why)

**d) Deciding language**  
The exact phrases customers use. Not paraphrases. Not cleaned-up marketing language. The words that go directly into headlines and copy. Examples that come up repeatedly in TiDB customer interviews:
- "one database for both workloads"
- "MySQL compatible so we didn't have to rewrite everything"
- "handle Black Friday spikes without manual sharding"
- "didn't want to manage Vitess"
- "HTAP without ETL"

**e) Developer emotional outcome**  
Beyond the rational job-to-be-done, capture the emotional state the developer or engineer is trying to reach. This field feeds directly into developer-facing content tone and ICP-specific headline testing.

**Format:** "After adopting TiDB, they should feel ___."

Common emotional outcomes in TiDB's ICP:
- "ship faster without worrying about breaking things" (scale-out MySQL migrators — relief from fragility anxiety)
- "experiment without fear" (AI builders — safety to iterate quickly on data architecture)
- "no more 2 AM pager alerts about shard rebalancing" (scale-out ICP — operational calm)
- "we finally stopped maintaining two systems" (HTAP/ETL elimination — relief from complexity debt)
- "production-grade in minutes, not weeks" (AI SaaS builders — legitimacy + speed)

This is not a marketing flourish — it is the emotional proof point that validates the rational argument. When the developer says "I can finally sleep through the weekend," that's the deciding language that closes the deal.

---

## 3. TiDB core ICP segments (starting hypothesis — validate, don't just accept)

**Primary segments (2025 positioning: AI-Native Distributed SQL):**

| Segment | Trigger signal | Motion fit | Channel |
|---------|---------------|-----------|---------|
| **AI agent builders** | Building agentic AI apps; vector DB can't handle ACID; separate stores for vectors + OLTP + analytics | PLG → SLG upgrade | AI community (LangChain Discord, Hugging Face), GitHub, AI-focused newsletters, MCP ecosystem |
| **AI SaaS / multi-tenant platforms** | Building SaaS on top of AI; need per-tenant DB isolation at scale (1k+ tenants); operational explosion with separate per-tenant clusters | SLG | AI developer conferences (AI Engineer Summit), technical case studies, devrel content |
| **Scale-out MySQL** | MySQL write bottleneck or sharding complexity at 10M+ rows/table; don't want to manage Vitess | SLG + PLG | HN, DB engineering blogs, PingCAP community |
| **Unified HTAP / eliminate ETL** | Running separate OLTP + analytics stacks (MySQL + ClickHouse/Snowflake); ETL latency is causing business problems | SLG (enterprise) | Enterprise events, analyst reports, DBA communities |
| **Cloud-native / Kubernetes-native** | Moving infra to Kubernetes; need operator-managed DB | PLG + Community | CNCF ecosystem, KubeCon, GitHub |
| **Fintech / high-stakes OLTP** | Needs strict ACID, high TPS, disaster recovery; often Aurora replacement | SLG | Financial industry conferences, Plaid/fintech case studies |

**Real customer evidence for ICP validation:**
- Manus (AI agent platform): 1M+ DB tenants, migrated in 2 weeks → AI SaaS multi-tenant signal
- Dify (AI workflow platform): Consolidated ~500K containers, unified vectors + documents + relational → AI agent builder signal
- Atlassian: 750+ Postgres clusters → 16 TiDB clusters → Scale-out/consolidation signal
- Plaid: 96 Aurora services migrated → Scale-out MySQL / fintech signal
- Pinterest: 10x P99 latency cut on graph service → Performance-critical OLTP signal

---

## 4. Segment and prioritize

After extracting the four layers across signals, group by tightness of fit:

| Segment type | Criteria |
|-------------|---------|
| **Core ICP** | Trigger is strong and recent; alternatives are clearly inadequate; deciding language matches TiDB's actual strengths; activated and retained |
| **Adjacent ICP** | Fits 2 of 3 dimensions; needs more education or a feature they can work around |
| **Out of ICP** | Churned fast; bought for use case TiDB doesn't serve well; expensive to acquire and retain |

For each segment: rough size estimate, motion fit (PLG / SLG / Community), channel implication, and red-flag signals that disqualify.

---

## 5. ICP card output

One card per segment. Compact. Falsifiable.

```
Segment: [name]
Trigger: [specific event that caused the search]
Job-to-be-done: [one sentence in the customer's voice]
Developer emotional outcome: [the feeling/state they want to reach — "ship without fear of X", "finally stop doing Y"]
Alternatives they considered: [the real ones — not the ones we wish they considered]
Deciding language: ["exact phrase 1", "exact phrase 2", "exact phrase 3"]
TiDB strengths that closed the deal: [2-3 specific capabilities, not generic]
Motion fit: PLG / SLG / MLG / Community-led
Channels most likely to reach them: [2-3 specific surfaces]
Red flags (not this segment): [1-2 signals that disqualify]
Evidence base: [N interviews, N community posts, N support tickets, etc.]
```

---

## 6. What this is not

- Not a persona (no demographics, no job title photo)
- Not a wishful description of who we *want* to sell to
- Not stable: update after every 10+ new customer interviews, when churn patterns shift, or when a new use case emerges from usage data

---

## Pairs with

- `tidb-gtm-brief` — ICP card is the required upstream input; motion selection uses segment fit data
- `tidb-competitive-map` — ICP reveals the real competitive set (which often surprises the product team)
- `tidb-messaging-platform` — deciding language from ICP cards populates headline variants and positioning copy
- `tidb-channel-copy` — deciding language → headline and hook copy on each platform
- `@tidb-gtm-brain/knowledge/icp.md` — current approved ICP segment profiles for quick reference