Most product failure isn't strategy. It's the basics, done vaguely.

The post-mortem always reaches for something grand. A market that moved. A competitor who got there first. A strategy that didn't hold. The truth is usually duller, and far more fixable: the basics were done vaguely. Not skipped — that would be easier to spot. Done, but loosely. Gestured at. Signed off with a nod rather than a definition. And a loose basic doesn't announce itself; it just quietly bends everything built on top of it.

This is the least glamorous claim in product, which is exactly why it's underrated. Teams reach for new frameworks, new strategies, a reorg, an offsite. The thing actually costing them is that nobody can say, in one sentence a user would recognise, what problem they're solving. Get the basics sharp and most of the clever stuff takes care of itself. Leave them fuzzy and no amount of strategy upstream survives the journey down.

The four basics, and how they go vague.

Four ordinary things carry most of the risk. Each has a vague version that feels fine in the room and falls apart in the work.

• The problem. "We need to improve onboarding." That isn't a problem, it's a direction. The sharp version names who, where, and how much: new users can't complete ID verification on mobile, and 38% drop at step three.
• "Done". "It's basically done" is the most expensive phrase in delivery. Done has to mean something specific: tested, instrumented, behind a flag, signed off against acceptance criteria. Otherwise it quietly means "nearly", and "nearly" ships.
• The outcome. "It shipped" is an output, not an outcome. Shipping is not the win; a changed behaviour is. If you can't say what should move and by how much, you've built something you can't tell succeeded.
• The owner. "The team owns it" means no one does. Sharp ownership is one named person and one decision date — the difference between a thing that moves and a thing that's discussed.

Vagueness is a tax, and it compounds.

A fuzzy basic isn't a contained problem; it's an interest rate. Start with a vaguely-defined problem and engineering builds a vaguely-right solution, QA tests against a vague idea of done, and the launch is measured against a vague sense of better. By the time it reaches a user, the original fuzz has compounded into a real gap — and the gap is now expensive to close, because it's wrapped in code, in a sprint that's already shipped, in a roadmap that's moved on. Cheap to fix at the start; ruinous to fix at the end. That's the tax, and most teams pay it without ever seeing the bill.

In regulated work, vague is expensive.

Everywhere, vagueness costs. In a regulated business it compounds faster and lands harder. "Roughly right" is fine for a landing page and ruinous when the thing being decided is someone's money: their mortgage approval, their KYC check, their balance. The teams that ship calmly in those environments aren't more cautious by temperament. They're more precise about the small things: exactly what the problem is, exactly what done means, exactly what changes for the user, and exactly who decides. Precision isn't bureaucracy there — it's the thing that lets them move at all.

Sharpness is a habit, not a document.

The fix isn't a new template or a heavier process — that's just vagueness with more pages. Sharpness is four small disciplines, applied every time, until they're reflex:

• State the problem in one sentence a user would recognise. If they wouldn't nod, it's still a direction, not a problem.
• Make "done" mean something before you start. Tested, instrumented, behind a flag, signed off against acceptance criteria, agreed up front rather than negotiated at the end.
• Name the behaviour that must change, and how you'll know. One metric, one direction, one timeframe. If nothing should move, ask why you're building it.
• Give it one owner and one date. Not a committee, not "the team": a name, and a day a decision gets made.

None of it is hard. All of it is skippable in the moment, which is precisely why it gets skipped. And it's why the teams that don't skip it look, from the outside, suspiciously like they're just better at strategy.

Why this matters now.

The pressure on every product team right now is to move faster and do more with less. The instinct under that pressure is to skip the sharpening — to take the rough problem, the loose "done", the unnamed owner, and just go. It feels faster. It isn't. Vagueness is the thing that makes teams slow, because it sends work in roughly the right direction and lets it drift, and drift is the most expensive motion in product. The fastest teams aren't cutting the basics. They've made the basics so sharp and so habitual that they cost almost nothing, and buy back everything downstream.

How we use this at Product Pieces.

When a product function feels stuck, the diagnosis is rarely a missing strategy. It's a basic, done vaguely: a problem nobody sharpened, a "done" that means "nearly", an outcome no one defined, an owner who's actually a committee. That's what the free Diagnostic is built to find: not the grand thing that's wrong, but the small, fixable one that's quietly bending everything above it. Usually the missing piece isn't a new direction. It's a basic, sharpened. And the relief on a team when the fuzz finally lifts is the most reliable signal in the work.