value-prop-that-converts
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseThe value prop that converts
高转化的价值主张
"Better" is sloppy thinking. Better how, along what dimension, by how much, proven by whom? Developers test every claim you make. Give them numbers or give them nothing.
Use this when: your value prop contains puffery, your claims aren't attributed, or you're trying to make one sentence do the job of two audiences.
“‘更优’是一种敷衍的表述。到底在哪方面更优？优势幅度有多大？由谁验证？开发者会检验你的每一个主张。要么给出数据，要么别说空话。”
适用场景： 你的价值主张存在夸大表述、主张未注明依据，或是试图用一句话同时触达两类受众时。
The core idea
核心思路
Developers have a finely tuned BS detector and they will verify you. Specificity is credibility. Every strong dev value prop is: specific + provable + spoken in their language.
开发者拥有敏锐的“空话探测器”，并且一定会验证你的说法。具体性就是可信度。每一份出色的开发者价值主张都具备：具体 + 可验证 + 用他们的语言表述。
Framework: the value-prop rules (Frankl)
框架：价值主张准则（Frankl 提出）
- Never say "better." Say better how, by how much, versus what.
- Time savings must be specific. ❌ "saves developer time" · ✅ "8× faster builds, 2 hrs → 15 min" (attributed).
- Two kinds of time, speak to both:
- Chronos (Alpha Dev): clock hours saved per week.
- Kairos (Empowered CTO): calendar time, weeks off a release cycle, competitive edge.
- The same product must land both. "Release fast or die" worked for developer and CTO.
- Every claim needs proof. A demo is the weakest proof (ideal conditions). An attributed testimonial (name + title + company + number) is the strongest. Anonymous quotes are assumed invented.
- Sell the category, not the solution. Talk about the problem and the need for "a tool like this"; don't proactively pitch features; it trips developer defenses.
- Never "pleased to announce" / "excited to share." No one cares how you feel.
- 绝不说“更优”。要说明在哪方面更优、优势幅度多大、相较于什么更优。
- 时间收益必须具体。❌ “节省开发者时间” · ✅ “构建速度提升8倍，从2小时缩短至15分钟”（注明依据）。
- 两种时间维度，兼顾两类受众：
- Chronos（一线开发者）：每周节省的时钟时长。
- Kairos（决策层CTO）：日历时间，比如缩短发布周期的周数、获得竞争优势。
- 同一产品需要同时打动两者。“快速发布，否则淘汰”这句话对开发者和CTO都适用。
- 每一项主张都需要依据。演示是最弱的依据（基于理想条件）。署名推荐语（姓名+职位+公司+数据）是最强的依据。匿名评价会被认为是编造的。
- 推销品类，而非解决方案。谈论问题以及“这类工具”的必要性；不要主动推销功能，这会触发开发者的防御心理。
- 绝不说“荣幸宣布”/“激动分享”。没人在乎你的感受。
Framework: the three dimensions of a dev value prop (Czakon)
框架：开发者价值主张的三个维度（Czakon 提出）
A complete value prop answers all three, fast:
- What is it?: category / known-incumbent comparison / plain statement ("a Datadog alternative," "CI for monorepos").
- For whom / what use case?: the ICP and the job (from ).
who-is-this-for - Why you over the 10 alternatives?: the legitimate, provable reason to exist.
Headline = what is it. Subhead = for whom / what job. For dev tools, weight the how over the why. Developers often already know why they hurt.
一份完整的价值主张需快速回答以下三个问题：
- 是什么？：品类/与知名竞品对比/直白表述（“Datadog 替代工具”“适用于单体仓库的CI”）。
- 面向谁/什么场景？：目标客户（ICP）及其需求（来自）。
who-is-this-for - 为什么选你而非其他10款竞品？：合理且可验证的差异化理由。
标题 = 是什么。副标题 = 面向谁/解决什么需求。对于开发者工具，要更侧重如何实现而非为什么需要。开发者通常早已清楚自己的痛点。
The puffery detector: flag and replace
夸大表述检测：标记并替换
| Banned | Why devs discount it | Replace with |
|---|---|---|
| Powerful | everyone claims it | the specific thing it does |
| Easy to use | they'll test it in 60s | time-to-value with a number |
| Best-in-class | says who, by what metric | the source or the number |
| Seamless integration | unprovable in the abstract | named integrations + logos |
| Industry-leading | says nothing | real share / user counts |
| Platform | hears: integration headache | the one job it does |
| Revolutionary / cutting-edge | pure air | name the actual technology |
| 禁用词汇 | 开发者质疑的原因 | 替换内容 |
|---|---|---|
| Powerful（强大） | 所有人都这么说 | 具体的功能描述 |
| Easy to use（易于使用） | 他们会在60秒内测试 | 带数据的价值实现时长 |
| Best-in-class（行业领先） | 谁说的？依据什么指标？ | 来源或具体数据 |
| Seamless integration（无缝集成） | 抽象表述无法验证 | 明确列出集成对象+品牌标识 |
| Industry-leading（行业领先） | 毫无实质内容 | 真实市场份额/用户数量 |
| Platform（平台） | 开发者会联想到集成难题 | 具体的核心功能 |
| Revolutionary / cutting-edge（革命性/前沿） | 纯粹空话 | 明确说明实际技术 |
Proof hierarchy (weakest → strongest)
依据可信度层级（最弱 → 最强）
your claim < a demo < a benchmark you ran < a named user's attributed resultSpend your effort at the right end.
your claim < a demo < a benchmark you ran < a named user's attributed result把精力放在可信度最高的部分。
Mistakes that look reasonable
看似合理的错误
- Adjective stacking: "powerful, seamless, intuitive." Three words, zero information.
- One line, two audiences: a Chronos-only message loses the buyer; a Kairos-only message loses the adopter.
- Unattributed social proof: "developers love us." Which developers? At which company?
- Leading with the why: for most dev tools the pain is known; lead with the how and the proof.
- 堆砌形容词：“powerful, seamless, intuitive（强大、无缝、直观）”。三个词，零信息。
- 一句话触达两类受众：仅面向Chronos的文案会失去采购方；仅面向Kairos的文案会失去实际使用者。
- 无署名的社交证明：“开发者喜欢我们”。哪些开发者？哪家公司的？
- 先讲“为什么”：对于大多数开发者工具，痛点是已知的；先讲如何解决以及依据。
Your next 30 minutes
接下来30分钟可完成的任务
- Run your homepage copy through the puffery table. Delete or replace every hit.
- Rewrite your #1 claim with a number and an attribution (even a single named user).
- Write one Chronos line (hours/week) and one Kairos line (weeks/release). Make sure both exist.
- State your value prop as the three dimensions: what · for whom · why you.
Built from real dev-tool GTM experience, with frameworks from Adam Frankl (The Developer-Facing Startup) and Jakub Czakon (markepear.dev).
When a framework can't make the call, that's what a human is for: The DevTool GTM Company.
- 用夸大表述检查表排查你的首页文案，删除或替换所有违规内容。
- 用数据和署名依据（哪怕只有一位署名用户）重写你的核心主张。
- 撰写一句面向Chronos的文案（每周节省时长）和一句面向Kairos的文案（发布周期缩短周数），确保两者都存在。
- 从三个维度表述你的价值主张：是什么 · 面向谁 · 为什么选你。
基于真实的开发者工具GTM（上市营销）经验构建，整合了Adam Frankl（《面向开发者的创业公司》）和Jakub Czakon（markepear.dev）提出的框架。
当框架无法做出决策时，就需要人工介入：The DevTool GTM Company。