Problem Sections That Put a Number on the Pain (27)

What a quantified-pain problem section actually is

A quantified-pain problem section is the decision to put a real number on the pain instead of describing it. A plain problem section says the current setup is slow, scattered, or wasteful. A quantified-pain section counts it: the hours lost, the money leaking, the share of work that fails. That figure is what turns a nod of recognition into something the reader cannot argue with, because a measured cost reads as a fact rather than a marketing line.

The best problem sections put a number on the pain in one of a few ways, often more than one at once:

• A row of stat cards. A grid of hard figures that price the pain from every side. Nautis lines up four at once: 54% burnout, $500 a month, 30 tools, and 40% of time lost, so no single number has to carry the case alone.
• A single headline stat. One big figure that states the problem before the reader can look away. Deep opens on "Up to 84% of digitalisation programmes fail," and Bulkmark leads with 97% of saved items never opened again, using an aggregate number to prove the pain is widespread.
• A running tally of wasted effort. A stacked receipt that adds up to a punchline. Saleshandy counts $200+ on domains, 3 days on DNS, and 3 weeks warming up, then lands the total: an entire month wasted, and nobody replied.
• A ratio that exposes a leak. A rate the reader can map onto their own funnel. Synapsa frames it as, for every 10 buyers who show interest, 7 never reach a conversation, while Payaca pins the cost at 15 hours a week spent copying data between systems.

Why it works

A number does two things a description cannot. It makes the cost feel concrete, because a specific figure reads as something measured rather than something written, and it gives the reader a way to self-check. When Payaca says a team loses fifteen hours a week to copying data, the reader silently maps that onto their own week and either confirms it or quietly fears it is worse. Either way, the pain stops being an adjective and becomes a quantity.

An aggregate stat does extra work. A figure like Deep's 84% of programmes failing, or Bulkmark's 97% of saved items never reopened, tells the reader the problem is not a personal failing but a pattern other people share. That lowers the quiet shame that keeps people sitting with a broken setup, and it borrows the credibility of scale: if most people hit this wall, hitting it is not the reader's fault, and looking for a fix is reasonable.

How the best problem sections do it

Across the scored examples below, the pattern that lands is a number the reader can actually check. The strongest sections attach a figure to a specific setup the reader lives with, rather than a generic claim, and they keep the figure believable enough to trust. UserEvidence grounds its 67% of buyers ruling out a vendor in a cited Evidence Gap Report, so the stat reads as research instead of a boast. Nautis stacks four numbers so the pain is priced from every angle at once, and Voltaiq scales its 80% scrap rate up to the industry cost, billions, so a battery maker feels the weight of it. The move is the same each time: a hard figure the reader can picture, tied to their own situation.

This angle rarely stands alone. The number is what makes problem sections that price the cost of doing nothing land, and it sharpens the mess in problem sections that set up a before and after. You can see the full range in the problem section gallery.

40/100

Common mistakes

10/100

The usual failure is a number that is round, vague, or unearned: "save hours every week," "10x faster," "cut costs by half," with nothing behind it. A figure the reader cannot trace reads as marketing, and it does less than an honest description would. The second failure is a stat with no setup attached, a percentage floating free of any situation the reader recognizes, so there is nothing to map it onto. The best examples avoid both by keeping the number specific, grounded, and tied to a setup the reader already lives with, the way Nautis, Payaca, and UserEvidence do.