My Part Works. So Why Is the Customer Still Struggling?

I had planned to write about understanding why something exists before deciding to fix it. That’s still advice I occasionally need to give myself, preferably before I’ve explained my excellent solution to everyone involved. But a recent conversation nudged my thinking further. Understanding each part of a system matters. So does recognizing that all those parts can work exactly as intended while the person relying on them still has a miserable experience.

My wife and I have a useful demonstration of this in our kitchen.

I do most of the cooking, and she does a lot of the cleaning up afterward. This is a generous arrangement considering I can make dinner for two look like a restaurant has been searched by the police. By the time we sit down, I’m assessing whether everything is cooked properly, tastes good, and arrived on the table reasonably close to the same time. She can appreciate the meal while also noticing that I’ve used three cutting boards, several pans, and what appears to be the emergency reserve of spoons. From the cooking department’s perspective, we have delivered. There may even be a case for an award.

The cleanup department has questions.

She is also extremely particular about organizing things. When I hang a picture, I leave the level on top so she can double-check my work. “Looks straight to me” is a preliminary assessment in our house, pending independent verification. In the kitchen, I tend to judge an arrangement by whether I can reach what I need while something threatens to burn. She has to consider whether the room can eventually be used again. We both want dinner to go well; we’re just paying attention to different portions of the evening.

If I save myself ten minutes by creating another twenty minutes of cleanup, I haven’t necessarily improved anything. I’ve moved the work and served it with a garnish. A more useful definition of success would include a good meal and a reasonable path back to a functioning kitchen. That doesn’t require either of us to do everything, but it does require me to look beyond the moment I put the plates on the table.

Product organizations can make this same mistake with considerably better dashboards.

A team ships a feature that works beautifully. Another team handles configuration, a third owns permissions, and someone else manages onboarding. Each has sensible priorities and evidence that its part is performing well. Meanwhile, a customer trying to complete one ordinary task has to navigate all four, discover an undocumented prerequisite, and contact Support. Nobody designed that entire experience on purpose. It emerged from decisions that were reasonable within their individual boundaries, which makes it frustratingly difficult to fix by asking everyone to do their existing job a little better.

The customer experiences the whole thing, including the spaces between our responsibilities.

I’ve become increasingly interested in those spaces. A feature can be easy to use once you find it, but difficult to discover. Setup can be straightforward for an administrator who understands the terminology and baffling for the person actually trying to get started. An automated interaction can resolve its portion of a request, then hand someone over to a human who asks them to repeat everything. The individual steps may be functioning. The accumulated effort is still enough to make someone reconsider how badly they wanted to finish.

This changes the questions I want a product team to ask. Alongside whether customers use a capability, I want to understand what they were trying to accomplish, what they had to do beforehand, and what happened afterward. Where did they stop? What did they have to explain twice? Who helped them get unstuck? Following one real task from beginning to end can reveal things that disappear when we divide the evidence into separate reports.

It also changes how we approach other teams. “We need you to build this” arrives as another demand on a roadmap that probably isn’t short of them. Showing where customers struggle, what you’ve observed, and what you’re still uncertain about gives people something they can help investigate. They may know a simpler solution. They may also explain why your proposed fix would cause trouble elsewhere, which is useful information to receive before the launch announcement.

Taking that broader view does not give Product a license to take over everyone else’s responsibilities. Nobody needs a colleague who has interpreted “ownership” as permission to become the regional manager of all adjacent decisions. The work is to make a shared problem understandable, involve the people who can address it, and agree on how you’ll know the change helped. Sometimes that means leading an experiment. Sometimes it means supporting another team’s solution or changing something in your own area that was creating work for theirs.

For a product leader, there’s a coaching responsibility here as well. If our reviews concentrate entirely on what shipped, we shouldn’t be surprised when people prepare excellent accounts of what shipped. We can ask what became easier for the customer, what evidence supports that conclusion, and where the remaining friction sits. A PM who identifies a problem outside their team’s direct control has brought us something worth understanding. Our response helps determine whether they’ll keep looking.

None of this requires assembling a committee to redesign the entire customer journey before anyone can release anything. Pick one task and one troublesome transition. Perhaps a clearer setup step removes a recurring support request, or carrying information through a handoff saves customers from starting again. Make a small change with the relevant people, then check both sides. Faster completion in one place is encouraging; finding out that the next person now spends their afternoon correcting mistakes is also evidence, although it makes for a less festive slide.

I think that’s the useful expansion of my original thought. Understanding why something exists helps us avoid careless changes. Understanding how it connects to everything around it helps us choose changes that matter. It gives teams a reason to look beyond their own delivery without expecting them to control the whole organization, and it gives leaders something more meaningful to develop than increasingly efficient feature production.

At home, I can start by asking whether my approach to dinner made the rest of the evening easier or harder. My wife will have evidence. At work, the equivalent is following the customer far enough to find out whether our successful release actually helped them succeed. “My part works” is useful information. I’d just like us to stay curious about what happens next.

Wishing you all the best
Mike