Inside customer fallacy

Inside customer fallacy

Let’s think of a restaurant. The kitchen is small and understaffed. There are 5 tables and they each have ordered something different. All of them expect to be served ASAP and the chef is cooking against the clock. Dishes pile up. Plates get rushed. The longer this lasts, the worse it gets.

There are a few solutions that come to mind. A larger kitchen, or even multiple kitchens with more staff. A small menu. A table could wait until the previous one is served before ordering. Unfortunately, these solutions are unlikely. Why? Because the people sitting at the tables are customers. And customers are king.

If a customer orders the hamburger but asks for a gluten-free bun, a good cook can improvise. If they ask for a vegan version of pork ribs, a good waiter points them to the salad. Only when they order steak in a fish restaurant, a business owner says No.

We can steer customer demand a bit, but in the end we oblige as often as possible.

We see this dynamic in IT teams. Understaffed and too many demands at the same time. Feature requests keep piling up and each of them has to be completed ASAP. There is never time to do the dishes or think up a new recipe. The same solutions come to mind: multiple fully staffed teams, a smaller wishlist, prioritisation and patience. These are unlikely for the same reason: We serve our customers after all.

The customer in case of a development team is rarely an external agent. Most likely it’s that group of people we have come to call “Business”. They ask for a pizza and the dev team tries to make one as soon as possible.

But there is one crucial difference. They all work for the same company. When we frame Business people as customers, they stop being stakeholders. They care about their meal, not the restaurant. In fact, in a lot of companies, they are incentivised to do just that.

“I don’t care how you do it, just do it.”

“We don’t have time for X, just give me Y”

We’ve come up with all kinds of frameworks to streamline the development team. We have Ticketing System after Workflow Engine to control what happens in the kitchen. But we don’t have a system in place to align the patrons at the table.

The role of Business is not to make demands and have the IT department crank out plate after plate. They are not the customer. Their role is to figure out demands and opportunities and provide their dev teams with the tools and support to make it happen. They’re there to help and support IT, not to make unreasonable demands.

Self-organizing product teams sound like a great idea. There is no Business vs IT in those.

But for a lot of organisations, that’s unfeasible. Changing the architecture of a company takes years.

The next best thing is changing the relationship. We could move from “We need this” to “Our customers have this problem, how can we work together to solve it?”

A customer demands. Their interest is the food.

A stakeholder supports. Their interest is the restaurant.