How to validate B2B pain before writing code

Primary question

How do you tell whether a B2B problem is real enough to build a narrow software product around?

Practical takeaway

Real B2B pain shows up as repeated manual work, measurable downside, and clear ownership by someone with budget or influence.

Key points

Ask about recent workflow failures, not hypothetical preferences.
Look for repeated cost in time, revenue, risk, or embarrassment.
Tie the pain to a role that can actually buy or champion a fix.

Workflow

Start with the repeated job, not with the product idea

Founders often validate the product they want to build instead of the workflow that already hurts. That reverses the logic. The better starting point is to find a job that happens often enough, costs enough, and breaks in recognizable ways.

Ask people to walk through the last time the process failed, slowed down, or needed manual rescue. Specific workflow stories are worth more than generic approval like 'yes, that would be useful.'

Favor recent examples over abstract agreement.
Validate frequency before validating feature detail.
Stay close to existing behavior until the pain shape is clear.

Pain interview prompts

Ask what happened the last time the workflow broke.
Ask who noticed first and who had to fix it.
Ask what the delay or mistake actually cost.
Ask what they do today instead of using software.

Cost

Good pain has a visible consequence

A problem becomes build-worthy when it leads to visible waste. That waste can be time, missed revenue, compliance risk, slower response, or operator embarrassment. If the downside is fuzzy, the buying urgency will also be fuzzy.

This is why annoyance alone is a weak signal. People tolerate a surprising amount of inconvenience when the consequence is small. Software earns budget when it changes an outcome the buyer can already feel.