value-prop-that-converts — скилл для Claude Code: как установить

---
name: value-prop-that-converts
description: "Write a developer value proposition that is specific, provable, and free of puffery. Use when the messaging leans on \"powerful,\" \"better,\" \"seamless,\" or \"best-in-class,\" when claims have no proof, or when the same line is supposed to reach both the developer and the buyer."
---

# The 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)

1. **Never say "better."** Say better *how*, by *how much*, versus *what*.
2. **Time savings must be specific.** ❌ "saves developer time" · ✅ "8× faster builds, 2 hrs → 15 min" (attributed).
3. **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.
4. **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.
5. **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.
6. **Never "pleased to announce" / "excited to share."** No one cares how you feel.

## Framework: the three dimensions of a dev value prop (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.

## 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 |

## Proof hierarchy (weakest → strongest)

```
your claim  <  a demo  <  a benchmark you ran  <  a named user's attributed result
```
Spend your effort at the right end.

## 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.

## Your next 30 minutes

- [ ] 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*).
If you can't tell whether your value prop actually lands with a buyer, get a human read. Reach out to me on [LinkedIn](https://www.linkedin.com/in/devtoolgtm/).