The supplier was blamed for years, turns out it was us

At Lloyds Direct, warehouse staff had a target time to unpack each pallet. They kept missing it. Stock arrived jumbled, items in the wrong order, the whole process slower and more frustrating than it needed to be. Pallets that should have been straightforward to unpack turned into a puzzle every time.

For years, the assumption was that it was a supplier problem. The supplier was packing the pallets badly. It was plausible, it explained the symptoms, and nobody questioned it seriously because the explanation was good enough.

It wasn't the supplier.

Tracing it back

When we actually investigated, we found the problem was in how our system was interfacing with the supplier's API. The way we were requesting and organising pallet configurations was generating layouts that made physical unpacking harder than it needed to be. The items weren't jumbled because the supplier packed them badly. They were jumbled because our software was telling the supplier to arrange them in a way that didn't account for how they'd actually be unpacked at the other end.

The system worked. The API did what it was told. The supplier packed what was specified. But nobody had connected the dots between the configuration our software generated and the physical reality of a person standing in a warehouse trying to unpack it against the clock.

Getting the engineers on the floor

Here's where it changed. We got the engineers to go to the warehouse and try to unpack a pallet within the target time themselves.

They couldn't do it.

That was the moment. Not a report. Not a metric. Not a meeting where someone presented slides about warehouse efficiency. Engineers standing in front of a pallet, trying to do the job, and realising it was genuinely difficult. The problem went from abstract to real in about ten minutes.

When you've personally experienced how frustrating a process is, you fix it differently. You don't file a ticket and move on. You understand the urgency because you felt it. And you're more likely to solve the root cause rather than patching a symptom, because you've seen the full picture.

What should have happened

Once the team understood the problem properly, the fix needed to be two-sided. Change how the system interfaced with the API so pallet configurations were optimised for unpacking, not just packing. Items arranged in the order they'd be shelved, grouped by location in the warehouse, structured so the person unpacking could work through the pallet methodically rather than hunting for things. And question whether the targets were realistic to begin with, given that the engineers themselves couldn't hit them under real conditions.

We found the root cause. We knew what needed to change. But the company decided there were other priorities, and the API change never got made.

That's a frustrating outcome, but the lesson still holds. The problem had been misattributed to the supplier for years. Getting engineers onto the warehouse floor and having them try the job themselves is what finally surfaced the truth. Even when the fix doesn't get prioritised, correctly diagnosing the problem matters. You can't fix what you've wrongly blamed on someone else.

What dogfooding actually means

Most people think of dogfooding as "use your own product." Install the app, click around, see if anything breaks. That's a start, but it barely scratches the surface.

Real dogfooding is closing the gap between the people who build the system and the people who live with its consequences. It's not just using the product. It's experiencing the conditions your users experience. The time pressure. The frustration. The workarounds they've invented because the tool doesn't do what they need.

At Lloyds Direct, the engineers didn't need to use the warehouse app casually. They needed to stand in a warehouse, on their feet, trying to hit a target, with a pallet of jumbled stock in front of them. That's the context that matters. That's what turned a three-year-old "supplier problem" into an obvious software fix.

The pattern

Every team I've worked on has had at least one problem like this. A long-standing issue that everyone has a theory about, but nobody has properly investigated because the current explanation is comfortable enough.

The fix is almost always the same. Go to where the work happens. Watch it. Try it yourself if you can. Talk to the people doing it every day and listen to what they tell you, especially when what they're saying contradicts the data or the official narrative.

If anecdotes keep surfacing that contradict the metrics, the measurement might be wrong, not the anecdotes. In the warehouse, the metrics said the supplier was the problem. The people doing the work knew something else was going on. They were right. We just weren't listening.