Loading
The left column is what you would say in a design review. The right column is the same work stated so that a person managing earnings against a hold period can act on it. The mechanism underneath each pair is what makes it a translation rather than a rebrand: if you cannot state the mechanism, the right-hand column is spin, and it will not survive its first follow-up question.
Two rules govern this page. First, no row carries a number, because a number belongs to a specific company and a specific measurement, not to a phrasebook. Second, every row names the overclaim it is closest to — the tempting stronger version that would be unsupported — because in practice the failure is almost never using the wrong words. It is using the right words about an effect you did not establish.
A note on why the right-hand column has to be built per company rather than looked up: the SEC’s own guidance on performance metrics observes that such metrics “can vary significantly from company to company and industry to industry”, and expects a company disclosing one to publish a clear definition of it and how it is calculated. If the regulator assumes the definitions differ, so should you. Ask what a metric means in the company you are standing in before you promise to move it.
| What you would say | What they can act on |
|---|---|
| We added a human review gate before the extraction is committed. | We cut the error rate that was generating support tickets and blocking adoption. |
Mechanism: Low-confidence extractions are intercepted in-flow, so an error that previously surfaced as a customer-reported problem is corrected before it propagates. The cost route is cost of revenue: fewer contacts and less manual remediation per customer served. Nearest overclaim: Claiming a retention or renewal effect. Errors reaching customers is one of many reasons an account churns, and you have no way to isolate this one. | |
| The onboarding flow was confusing, so we rebuilt it. | New accounts reach first successful use without a services engagement. |
Mechanism: If activation previously required a solutions engineer or an implementation call, removing that need takes hours out of the cost of landing an account — a sales and marketing route, or a cost of revenue one where onboarding is delivered as a service line. Nearest overclaim: Claiming increased new-customer revenue. Winning the deal happened before onboarding; this changes what the deal costs to fulfil, not whether it closed. | |
| We shipped a shared component library across the portfolio. | Several products stop paying separately to build the same capability. |
Mechanism: A one-time build plus a per-product integration cost replaces N local builds. The claim is arithmetic and has a break-even integration count, which you should state. Nearest overclaim: Claiming portfolio-wide savings before anyone has adopted it. Until the second integration lands, the only verified number is the build cost you have already spent. | |
| The design was inconsistent across the product. | Support and training material has to be maintained per-variant, and every new surface starts from zero. |
Mechanism: Inconsistency is a recurring cost paid in engineering time, documentation and support handling, not an aesthetic complaint. Name where the recurring cost lands or the point does not carry. Nearest overclaim: Attaching a trust or brand-perception claim you have no instrument for. If nobody measures perception, do not spend credibility on it. | |
| Our NPS went up after the redesign. | This is a leading indicator with no established link to this company’s renewals, and I am not resting the case on it. |
Mechanism: Saying this out loud is the translation. NPS is a survey metric with a self-selected respondent pool; treating it as a proxy for revenue is the single easiest way for a design function to get caught overclaiming. Nearest overclaim: Converting a survey movement into a revenue number. If someone else in the room does that arithmetic for you, that is their claim, not yours. | |
| We made the agent’s reasoning visible to the user. | Operators can accept or reject agent output without escalating, so fewer runs require a human specialist. |
Mechanism: Visibility is only worth money if it changes what a person does next. The financial claim lives in the avoided escalation, not in the transparency itself. Nearest overclaim: Claiming increased trust as an outcome. Trust is not a line item; the behaviour it changes might be. | |
| We added streaming so the interface responds immediately. | Users stop abandoning long-running tasks partway through, so work that was started and paid for actually completes. |
Mechanism: Abandonment is measurable and has a cost where compute or human time was already spent. The claim is about completion rate, which you can instrument, not about perceived speed, which you mostly cannot. Nearest overclaim: Claiming a conversion or expansion effect from responsiveness alone. Note also that this is exactly the kind of claim that is easy to make and hard to retract. | |
| We ran usability testing before shipping. | We spent a fixed, small amount to avoid a rework cycle whose cost we can estimate. |
Mechanism: Research is an insurance argument, not a growth argument. It reads well when priced against the specific rebuild it is preventing and badly when defended as good practice. Nearest overclaim: Claiming research improved outcomes generally. Price one avoided rework, or make no financial claim at all. | |
| We fixed the accessibility issues. | Procurement and enterprise security reviews stop stalling on the accessibility questionnaire. |
Mechanism: In enterprise software the commercial mechanism is usually the sales cycle: a deal that cannot clear a buyer’s accessibility requirement is a deal that does not close, or closes later. That is a sales and marketing route with a real, observable blocker. Nearest overclaim: Sizing the addressable market of disabled users as new revenue. It is a legitimate reason to do the work and an unverifiable number in a case. | |
| We reduced design debt. | The cost of building the next surface fell, and here is the surface that proved it. |
Mechanism: Debt reduction is an R&D-route claim about future build cost. It is only checkable against a specific subsequent build, so name the build. Nearest overclaim: Presenting debt reduction as a benefit in itself. Nobody funds the removal of a cost they were never shown. | |
| We prototyped three options in a week. | A decision that would have taken a quarter of engineering to test was made before the engineering was committed. |
Mechanism: Speed of prototyping converts to money as avoided build cost on rejected options. It is one of the few design claims where the counterfactual is genuinely legible. Nearest overclaim: Counting all three rejected options as savings. You would not have built all three; count the one you would have. | |
| The interface now matches the brand. | Theming is configuration rather than a fork, so the next product adopting this surface does not pay a customisation cost. |
Mechanism: Across a portfolio of separately branded products, token-driven theming is what keeps per-integration cost low — which is the variable the whole shared-component case rests on. Nearest overclaim: Claiming brand consistency drives revenue. In a portfolio of independently branded companies, it is not even the goal. | |
| We simplified the admin experience. | Configuration work that customers currently pay professional services to perform becomes self-serve. |
Mechanism: Moving work from a services engagement into the product moves revenue mix from services to product, and cuts the cost of delivering it. Both effects are visible in reported line items. Nearest overclaim: Claiming a margin improvement without checking that the services work was actually being paid for. If it was absorbed, the effect is on cost, not on mix. | |
| This change will improve the user experience. | No translation exists yet — this sentence names an artifact, not a financial effect. |
Mechanism: There is no honest mechanism here, and that is the point of including it. Until you can name the route and the behaviour that changes, the correct move is to say the case is not written yet. Nearest overclaim: Reaching for any number at all to fill the gap. An unfinished case costs you one meeting; an invented number costs you every meeting after it. | |
The risk of a page like this is that it turns into a set of magic phrases — you learn to say “cost to serve” and stop checking whether cost to serve actually changed. The defence is the mechanism line. Read the row, then say the mechanism out loud in your own case’s terms, naming the person or system whose behaviour changes. If that sentence has a missing step, the row does not apply to you yet, however well the words fit.
The most valuable row on this page is the last one. Being able to say “I do not have a financial case for this yet, and here is what I would need to measure to build one” is what buys you the benefit of the doubt on every case where you do.
This course argues against overclaiming, so it holds itself to the same rule: every number on these pages links to a source that was opened and read. Where a source sells the thing it is describing, the prose says so. If a claim looks unsupported, check the resource list and tell your teaching agent — a lesson that overclaims is a bug.