Worked Example: The Late-Paying Customer

Reading about a methodology or process and watching one run are different things. So let's run one.

This page takes a single problem through the entire opportunity backlog, define to decision: the conversations you'd have, the data you'd pull, the prototype you'd pick, the test you'd run, and the people you'd bring in at every step.

One thing before we start. The company in this story is invented, and so are the numbers inside it; I'll label them as they come. The method is real, and the industry benchmarks are real, credited to their sources. The point of the made-up parts is to make the mechanics concrete, not to claim a result.

Here's the setup. You run product at a company that makes invoicing software for small and mid-size businesses. Your customers are suppliers: they do the work, send the invoice through your tool, and wait to get paid. The businesses they bill, their customers, are the payers. All of it is B2B, business-to-business: businesses billing other businesses. Keep suppliers and payers straight, because this whole story lives in the gap between them.

Step 1: Define the problem

The item lands on the opportunity backlog the way the good ones usually do: from the people closest to the pain. Support keeps logging a complaint that isn't about your software at all. Your tool works fine. My customers just don't pay on time. Sales hears the same thing on renewal calls. It's direct customer feedback, unprompted, over and over, so it ranks high on source alone.

Resist the urge to start sketching reminder features. You haven't defined the problem yet.

So you get close. You sit with support for an afternoon and listen to the calls. Then you book interviews with ten customers and ask Mom Test questions, not pitch questions. Not "would you use a feature that chases late payers?" Ask: "walk me through the last invoice that got paid late. What did you do, day by day?"

Two perspectives come back, and they differ in a way that matters.

The owner talks about cash. She runs a 15-person services firm, and a late month means choosing between drawing on a credit line and delaying a hire. She doesn't describe a software problem. She describes a sleep problem.

Her bookkeeper talks about the chase. Friday afternoons on the phone, awkward calls to customers he knows he'll be calling again next month, a side spreadsheet of who promised what. And he drops the clue you'll want later: "Nobody's refusing to pay. The invoice is just sitting in somebody's inbox until I call."

Notice what the interviews already killed: this is not a non-payment problem. Almost everyone pays eventually. Atradius's 2025 Payment Practices Barometer for the US backs that up: only about 5% of long-overdue B2B invoice value ends up written off as bad debt (1). The rest gets paid. Late. So the problem is late payment, and late is a different problem than never, with different solutions. Collections agencies exist for never. Nothing your customers use solves late.

It's also not rare, and you can prove that without leaving your desk. Taulia's 2023 Supplier Sentiment Survey, which asked more than 11,300 businesses across 130-plus countries, found 51% of businesses are paid late on average. Only 44% get paid on time (2). The complaint your support team keeps hearing is the normal condition of doing B2B business.

Now you've earned the statement, in the same When / I want / So / But format from the Define the Problem page:

When I invoice my customers, I want to be paid by the due date, So I can cover payroll and plan my cash without borrowing to bridge the gap, But a big share of my invoices get paid weeks late, and I usually find out only after the date has already passed.

User-focused, broad, manageable. Not a feature named anywhere in it.

From here on, everything this opportunity learns lives on one card on the backlog. After this step the card carries its first two fields: Problem (the statement above) and Users (small and mid-size suppliers billing other businesses: the owner who feels it, the bookkeeper who fights it).

Step 2: Should you solve it?

Real is not the same as worth solving, so you run the assessment across the four areas from Step 2: User, Expected Outcome, Market Size, Competitors. The first two are your desirability check, and desirability goes first, because if nobody cares whether this gets solved, nothing else matters. Ten interviews already answered that one loudly.

This is also where you stop working alone. Two conversations carry the step.

The first is with your finance lead, because finance holds numbers product doesn't. She gives you the industry's name for the problem: DSO, days sales outstanding, the average number of days it takes to collect the cash after a sale. Then she does the arithmetic that turns "annoying" into "expensive." Take a supplier doing $5 million a year on credit terms, meaning they invoice now and get paid later (made-up supplier, real arithmetic): that's roughly $13,700 of revenue booked per day, so every day of DSO is another $13,700 sitting in someone else's bank account. Atradius's 2024 US survey found overdue invoices were converted to cash an average of 20 days past the due date (3), and their 2025 report found 43% of credit-based B2B sales go overdue (1). Do that math on this supplier: 43% of the book running 20 extra days is roughly $118,000 of their cash parked in other people's accounts at any given moment. That's the owner's sleep problem, priced.

The benchmarks say the room to improve is real, too. The same Atradius 2025 report puts average payment terms at 45 days from invoicing (1). And The Hackett Group's 2025 US Working Capital Survey found an 18-day DSO gap between top-quartile and median performers (4). Read that gap the optimistic way: somebody is already collecting 18 days faster than the middle of the pack. Faster is possible.

The second conversation is with sales, who can tell you where the pain concentrates: small suppliers without a collections person scream loudest; your bigger suppliers have whole AR teams (accounts receivable, the people whose job is chasing the money they're owed) to absorb it. That's your market-size picture. Say your tool serves 4,000 supplier customers (made-up number) and the small end of that base is both the majority and the most exposed. The problem isn't niche inside your own walls.

Competitors next. Factoring companies will buy a supplier's invoices at a discount for cash now, which works and costs a painful slice of margin. Collections agencies solve the wrong problem and torch the relationship on the way. Other invoicing tools have basic late reminders. And the real incumbent, the thing you're actually competing against, is the bookkeeper's Friday phone calls. Whatever the customer does today is the competition.

One more thing goes on the card here, because this step is where you first smell it: anything that pressures payers could damage your customers' relationships with the very people who pay them. That's an ethics flag. You don't have to answer it today. You have to write it down so the build gate in Step 6 can't pretend it never came up.

Could you kill it right here? Absolutely, and with some items you should: market too small, competitor already owns it, pain too mild. This one survives on evidence. Big, broad, measurable, and felt. The card gains Expected Outcome (cut days-to-payment for suppliers; more cash in their hands sooner), Market Size, Competitors, Our differentiator (the invoice already flows through us, so we sit at the exact moment payment happens), and How might we? (how might we help suppliers get paid on time without souring the relationships they depend on?).

Step 3: A belief you can test

Now let's build a hypothesis.

The bookkeeper's clue ("nobody's refusing, the invoice just sits") is a hunch, not a hypothesis. So you look at the other side of the transaction. A couple of friendly customers introduce you to the people who pay them: the AP clerks (accounts payable, the team that pays a business's bills). Two more perspectives show up, and they complicate things in a useful way.

One clerk describes pure friction. The invoice arrives as a PDF, gets forwarded for approval, then waits for the every-other-Friday payment batch, when she logs into a bank portal and keys it in by hand. Nobody decided not to pay. Paying is a chore, and a chore loses to every urgent thing on her desk.

Then your engineer, sitting in on the readout, raises the rival belief: "Or they're slow on purpose. Big companies stretch terms because they can." He's not wrong to ask. The Hackett Group's same 2025 survey traced the second straight year of DSO degradation to customers using their bargaining power to extend payment terms (4). Strategic lateness is real, and if that's what your suppliers face, no payment link fixes a policy.

Two live explanations, friction and policy. That's exactly what a hypothesis is for: pick the one you believe, write it so a test can prove you wrong.

If we give customers a one-click payment link in the invoice email, they will pay faster, because the friction at pay-time is what's slowing them down, not an unwillingness to pay.

Then the measures, set with the multi-functional group, not alone at your desk. Baseline days-to-payment first, before anything changes, because you can't see movement without knowing normal. A short survey of payers for the why behind the lateness. Then days-to-payment with the link, against a control group that doesn't get it.

And you name the vanity trap before it tempts anyone: link clicks. Clicks will go up and to the right and feel like winning. Run clicks through the three-question metric test from the Hypothesis page and as a measure of success they die at question one: no business decision changes because somebody clicked. Paid-on-time is the number. Clicks are trivia.

The card gains Hypothesis and Measures of success.

Step 4: Concepts, and the cheapest honest test

Now the room gets bigger on purpose. An engineer, a designer, the support rep who's heard a hundred of these calls, somebody from sales, and for one hour, a customer's bookkeeper. Diverge first: lots of ideas, bad ones welcome, because a bad idea sitting next to a good one is usually what sparked it. Then converge, ruthlessly, to the few worth testing:

• A one-click pay link inside the invoice email.
• Smarter reminders, timed before the due date instead of after it.
• A pay-part-now, rest-later option for cash-strapped payers.

A fourth idea, auto-charging a payer's card on file when the invoice comes due, gets real debate and gets cut. Sales doesn't believe payers will hand a supplier standing access to their money, and support points out that one mistaken charge would burn more trust than a year of late payments. It stays on the card as a future concept. It doesn't go in the test.

Then engineering switches hats, and you run the three feasibility questions from the Design Concepts page:

• Existing: the payment processor you already integrate with offers hosted payment pages, so a "pay now" link needs almost nothing built.
• New: for a test, nearly nothing; for a real product, reminder scheduling and reconciliation work, sized roughly in weeks, not quarters.
• Assumptions: written down, on the card, and one of them matters more than the rest:

We assume the person receiving the invoice email is allowed to just pay it.

Picking the prototype is the easy part, because the riskiest question isn't "can we build a pay link." You can. The risky question is "does a pay link change payment behavior," and that's a question you can answer with no software at all. Your MVE, the smallest thing you can put in front of a customer to learn, is a hand-sent reminder email carrying a real pay link. Ugly is okay. No mockups, no sprint, no backlog tickets.

And before the real link goes anywhere, you line up an even cheaper pre-check: the same reminder email with the link pointed at a placeholder page, just to count who clicks. It can't tell you whether anyone pays. It tells you whether anyone reaches for the door, for the cost of an afternoon.

The designer catches a wrinkle before the room breaks up: this test bundles two of the concepts, the early reminder and the pay link, into one email. The clean-test lesson from the Hypothesis page says only one thing should differ between your groups, and this design bends it on purpose, because a pay link nobody opens an email to see tests nothing. The link has to ride the reminder. So you write down, now, how you'll pull the two apart when results land: link usage tells you whether anyone walked through the pay door, and the payer survey tells you whether the lateness was friction or forgetting. If invoices get paid faster while the link goes untouched, the reminder was the lever, not the link.

The card gains Feasibility and MVE.

Step 5: Run the test

You climb the currency ladder from the Test & Validate page instead of leaping to the top of it: cheap signals like clicks on the bottom rungs, real money at the top.

The first rung is the pre-check you lined up in Step 4, and it's nearly free: the reminder email with a pay link that lands on a placeholder page, just to count who clicks. Cost: an afternoon. Say a third of payers click within two days (made-up number, like everything inside this story). Good: payers at least reach for the door. But clicks are the trivia we already convicted: never the answer, only the price of admission to the next rung. You don't celebrate. You climb.

The second rung is the MVE itself, the real test, and it still isn't software. It's a concierge test: you do manually what the product would eventually do automatically. You recruit a dozen supplier customers to opt in, call it 600 outgoing invoices over two billing cycles, about eight weeks. For each supplier you split their invoices: half go out the normal way (your control group), half get a short reminder a few days before the due date with a live pay link to the processor's hosted page. You and a support rep send every email by hand from a shared inbox. To the payers it looks like a product. It's two people and a spreadsheet.

The currency on this rung is the best kind: money, moving sooner, against the supplier's real receivables. Nobody gets asked what they would do. You watch what they do.

Two people keep the test honest while it runs. The support rep on the inbox reads every reply, and a few of them are their own little discovery: "can you resend the invoice? We never got the original." Some lateness, it turns out, is invoices dying in inboxes, which nobody said in a single interview. Write it on the card. And your finance lead guards the dial with the baseline lesson from the Hypothesis page: these suppliers have seasonality, so the comparison is the control group running in the same weeks, never last month's numbers.

One field gets filled in before any data lands, so nobody can move the goalposts after: What did we expect? Invoices with the reminder-plus-link get paid meaningfully faster than the control. The card also gains Number of users tested.

Step 6: Read the dial, pick a door

Eight weeks later you're in a room with the numbers, and one of three stories is on the screen. Walk all three, because each one ends at a different door, and the last field on the card, Experiment Success?, gets its honest answer in this room.

The dial jumps: build. Say the link group's median days-to-payment drops from 58 to 49 while the control holds at 57. Real movement, control flat, and the payer survey confirms the why: it was just easier. The friction belief held. Before the card moves anywhere, you run the gate you flagged back in Step 2: ethicality. Does a polite reminder and an easier way to pay harm the payer? No. This isn't pressure, it's the removal of a chore, and the relationship risk you wrote down doesn't show up in a single reply. The card leaves the opportunity backlog for the product backlog, and engineering, who've been in the room since the concept workshop, already know exactly what they're building and why. That's the door everyone wants, and you earned it instead of assuming it.

Part of it moves: pivot. Reminded invoices got paid faster, but almost nobody used the link. Payers paid the old way, just sooner. The friction belief missed, and something truer surfaced: a chunk of lateness is forgetting, and timing is the lever. Same problem, same card, sharper guess. You write the new hypothesis around reminder timing and channel, and loop back to Step 3 with everything the first test taught you. A pivot isn't a new card. It's a better swing at the same thing.

Nothing moves: archive, and redefine. Days-to-payment didn't budge in either group. The follow-up calls find the reason, and it's the assumption you underlined in Step 4: the person getting the email was never allowed to just pay. The invoice sits in an approval workflow on the payer's side, and no link, however slick, jumps that queue. So you archive. This card closes, with the why written on it (the approval-workflow lesson), so whoever finds it in eighteen months doesn't pay for the same lesson twice. The problem, though, is still real, still expensive, still felt. It redefines: the bottleneck lives inside the payer's approval process, which is a different problem statement, maybe a different user, maybe a different product. That sharper problem goes back into the opportunity backlog as a new card, starting at Step 1 with everything this card just taught you. That's the loop redirecting you, and it stings less than it sounds. The total bill for finding out was some hand-sent emails and eight weeks of attention, not two quarters of engineering.

And if the dial moved, but not enough to commit and not little enough to kill? That's the persevere read from the Build / Pivot / Archive page: same test, more time, with a deadline and a number attached before anyone agrees to keep going.

What the loop bought you

Tally the cost of everything above. A dozen-plus interviews. A finance conversation and a few published benchmarks. One workshop. A placeholder page. Two people on a shared inbox for eight weeks. In every single branch, production code waited until the evidence earned it.

Now tally the default. Skip the loop, take "customers complain about late payments" straight into a quarter of building a payments-and-reminders feature, and if the truth was the third story, you discover the approval-workflow problem in production, from silence. Same lesson. Wildly different price.

The card is the quieter asset. Every field on it is filled now: Problem, Users, Expected Outcome, Market Size, Competitors, Our differentiator, How might we?, Hypothesis, Measures of success, Feasibility, MVE, Number of users tested, What did we expect?, Experiment Success? Whichever door it went through, the next team to touch this problem starts from knowledge instead of from zero.

One problem, six steps, three honest endings. The loop didn't make the idea succeed. It made the truth cheap. That's the whole job.

The benchmarks behind the numbers

The industry figures in this walkthrough are real and credited to their sources. The supplier, its dollars, and the test results are invented to make the mechanics concrete, and labeled as such where they appear.