35% Understand the Problem but Not What Done Looks Like. I'd Have Bet the Opposite.

Day one on a large product org that was months behind, I asked why they were building a particular thing. Not the junior PM, not the business analyst, nobody in the room could answer. They'd made some assumptions and sort of thought they should.

That question is the fastest diagnostic I have. When nobody can say why the work exists, you're not looking at an engineering problem no matter how loudly the org insists you are. I've used it for years and it has never once failed to find something.

So I was genuinely thrown by a number in the 2026 State of Product Development survey, which Luca Rossi ran across 340 engineering professionals, from ten-person startups to orgs with more than a thousand engineers.

Engineers are more likely to understand why something is being built than to know what done looks like. 35% said they understand the problem but not the success criteria. Only 13% had it the other way around.

I'd have bet the opposite, confidently, and I'd have been wrong.

Both things are true, and the difference is the diagnosis

Here's how I've reconciled it, because I don't think the survey contradicts the day-one test so much as it locates a second failure I wasn't looking for.

The why-gap is what you find in stuck teams. It's a signature of genuine dysfunction – the org that's months behind, where product hasn't done the upstream work of understanding users and their problems, and the confusion has had time to propagate all the way down. By the time I'm brought in, it's usually there.

The done-gap is what you find in teams that look fine. Everybody knows the mission, everybody can recite the strategy, the standups are crisp, and nobody agrees what finished means. It's quieter, more common, and nobody calls a consultant about it, which is exactly why I'd under-weighted it.

Only 27% of engineers in that survey said both the problem and the success criteria were clear when they read a ticket. So roughly three in four are working from something incomplete, and the incompleteness is usually at the far end.

The done-gap is the expensive one because it hides

What makes this failure mode nasty is that it produces work. A why-gap tends to stall – people sit in ambiguity and ask questions or quietly slow down. A done-gap doesn't stall at all. Everyone's clear on the destination, so everyone builds, and the disagreement about what "done" meant only surfaces at review, or in QA, or in production.

The survey data bears that out. Ambiguous or missing acceptance criteria is the single largest reported cause of delay and rework at 50%, ahead of edge cases discovered too late at 40%. And unclear or changing requirements are the number one team bottleneck at 35% – twice the rate of the next item, QA and testing, at 16%.

Twice the next item. In a profession that spends most of its process energy on the ceremony around delivery, the largest single drag is the definition of the work.

Two more, because together they tell a small story: 60% of engineers say they need clarifying questions "often" or "almost always" before starting, and only 8% say tickets give them everything they need. Meanwhile 59% of teams discover missing tasks, stories, or dependencies mid-cycle – and that rate is flat from ten-person startups to thousand-engineer organizations.

Flat across three orders of magnitude of scale. That's not a coordination problem you grow out of, and it isn't solved by better tooling, or the last ten years would have solved it.

This is a shift-left argument and it predates AI

I've believed for a long time that a lot more time should be spent to the left of the workflow, and this is true whether or not there's a model in your pipeline: better thinking done by Product and Design leads to far better Engineering outcomes.

That doesn't mean Product and Design work in a vacuum and throw a spec over the wall. The work of understanding the user and their problems, doing the research, coming up with the feature ideas, the customer journey, the UX – that's the part we can't hand off. And once there's a good idea, and the bad ones have been rejected, that's when Engineering comes in to talk about validity, viability, and capability, and you keep workshopping until you're ready to build.

Requirements failures sit upstream of every delivery metric you're currently watching. The Project Management Institute has found that 37% of organizations name inaccurate requirements as the primary reason their projects fail – a figure I'd treat carefully, since it reaches me second-hand through a vendor that sells requirements tooling, but which is directionally consistent with thirty years of similar findings.

How to tell which gap you have

The two need different fixes, so it's worth five minutes to find out.

For the why-gap, ask three people at different levels – a PM, an engineer, a designer – why a specific in-flight item exists. Separately, not in a meeting. If you get three different answers, or one shrug, that's your gap and it's upstream. The fix is product work: user research, problem definition, a real answer to what this is for. It's slow and there's no shortcut.

For the done-gap, take an item everyone considers well-specified and ask the same three people what has to be true for it to be finished. You'll frequently get three different answers from people who all believe they agree. The fix is faster and more mechanical: acceptance criteria written before the work starts, the edge cases surfaced while they're still cheap, and a shared definition of the product behaviour you're trying to produce.

The second one is embarrassing precisely because it's so tractable. Most teams I've walked into could close a meaningful part of their done-gap in two weeks of disciplined ticket-writing, and haven't, because nothing in the system makes anyone responsible for it. The why is somebody's job. The definition of done belongs to everyone, which is another way of saying it belongs to no one.

The tell that you're looking at a done-gap

One pattern gives it away reliably, and you've almost certainly seen it: the argument about whether something is a bug or a feature request.

Those arguments feel like disagreements about severity or priority, and they're usually neither. They're two people discovering, after the code exists, that they held different definitions of what the thing was supposed to do – and the ticket didn't adjudicate between them, so the disagreement had nowhere to surface until production made it concrete. A team that has a lot of these doesn't have a QA problem or a triage problem. It has a definition problem that's being paid for downstream at the worst possible exchange rate.

What I changed

I still open with the why question, because when it fails it fails loudly and it points straight at the upstream problem. But I stopped treating a clean answer as an all-clear.

If the team can tell me why, I now ask what done looks like – and that's where the more interesting silence usually is. It's a worse question for diagnosing a crisis and a better one for diagnosing a team that's quietly leaking a third of its capacity to rework and can't figure out where it's going.

Being wrong about which question mattered more cost me nothing, which is the good kind of wrong. It just meant I'd been finding the loud problem and walking past the common one.