What it is and what problem it solves
Almost every value proposition promises the same things: quality, service, closeness, experience. They aren't false; they're interchangeable. Cover the logo and any competitor could sign them.
Promise and proof forces two things. The promise has to answer the job the customer is trying to get done, not what the product does. And every promise carries a verifiable proof next to it. Whatever can't be proven comes out, or gets flagged as a hypothesis to validate.
The result is a message architecture by segment, role and channel that the sales team, the agency and the website use without reinventing it every time. Strategy has no color. It has results: this is where you decide what gets said and what holds it up, not how it looks.
When to use it and when not to
It comes after the decision-maker map, because each role has its own job and needs its own proof. It is the step before an agency brief, a website or sales-collateral rebuild, and any repositioning.
It is not a brand book and it doesn't replace creative work. Nor can it be done without prioritized segments: a promise written for the whole market ends up identical to the competition's. And if the company isn't willing to generate new proof, the tool is limited to cutting promises, which is also useful.
How to build it
- Write the job by segment and role. "When [situation], I want to [progress], so I can [outcome]," with its functional, emotional and social dimensions. Deliverable: one job statement per role.
- Map the current alternatives. What the customer uses to get that job done today: a competitor, a spreadsheet, an employee or doing nothing. Deliverable: alternatives and why they fall short.
- Write the promise. One sentence, with no adjective that can't be proven. Deliverable: a promise per segment and role.
- Inventory the proof. Everything that can support the promise, graded by strength. Deliverable: a proof inventory with its level.
- Assign channel and moment. Which proof goes on the website, which in the first meeting and which in the proposal. Deliverable: the message architecture, ready for a brief.
Anatomy of the deliverable
The architecture reads row by row. A hypothetical example of a packaging manufacturer selling to agri-food exporters:
| Segment and role | Job | Promise | Proof | Strength | Channel and moment |
|---|---|---|---|---|---|
| Exporter, operations director | Cargo arrives without losses and passes inspection at destination | Packaging validated for the specific route and destination | Documented strength tests by route | High | Technical proposal |
| Exporter, purchasing | Justify the cost against current packaging | Cost per unit delivered, not per unit made | Total cost comparison with open assumptions | Medium | Negotiation |
| Exporter, quality | Comply with the destination country's regulations | Documentation ready for each market | Current technical data sheets and certificates | High | Website and first meeting |
Proof strength is graded like this:
| Level | Type of proof | When it's enough |
|---|---|---|
| High | Measured first-party data, a demonstration, a contract clause | To close with a committee |
| Medium | A verifiable reference, a documented process | To open a conversation |
| Low | Self-assertion, years in business, awards with no criteria | Never as the main proof |
The classic framework: Jobs to Be Done, and what it lacks
Jobs to Be Done was popularized by Harvard professor Clayton Christensen, above all in Competing Against Luck (2016). The idea: customers don't buy products, they "hire" them to make progress in a specific circumstance. His best-known example is a milkshake sold in the morning that didn't compete with other milkshakes but with the banana or bagel the driver ate on the commute. The job has functional, emotional and social dimensions, and the circumstance explains the purchase better than the customer's profile.
We keep two ideas: the real competition is defined by the job, not the category, and the circumstance matters more than the industry. We add what JTBD doesn't provide: the proof. The framework tells you what to promise; it doesn't tell you why they'll believe you. In B2B, where the purchase goes through a committee, credibility weighs as much as relevance.
Where it falls short: JTBD thinks of one buyer with one job. In a business purchase there are several jobs at once, one per role and sometimes in tension: the user wants ease, purchasing wants price, leadership wants lower risk. That is why we write one job per role, not one per segment.
Common mistakes
- Promising features. "State-of-the-art technology" describes the product, not the customer's progress. It happens because whoever writes it knows the product better than the job.
- Inflating the strength of the proof. A testimonial with no name or title is presented as if it were data. The committee notices, and the whole promise loses credibility.
- One promise for the whole company. It sounds coherent and convinces no one in particular, because each role hears an answer to a question it never asked.
- Writing it at the agency with no customers in the room. It comes out well written and poorly grounded. The promise is validated through interviews; the agency turns it into assets afterward.
An illustrative scenario
Take a hypothetical business software company for distributors, selling in Spain to sales directors who run their teams through regional branches. Its website promises "total control of your business." The interviews surface a different job: the sales director wants to know on Monday which branch is drifting off target, without waiting for month-end close.
The promise gets rewritten around that job. The proof available is a demo with the customer's own data, which becomes the first step of the sales cycle. What couldn't be demonstrated, such as integration with any ERP, comes out of the message until proof exists. How this fits into sales material is covered by the playbooks and sales enablement practice area.