Blog
The Supermarket Principle
What managers in product development can learn from supermarkets.
What do supermarkets have to do with product development? Admittedly, not much. But when it comes to the speed of a product development, a supermarket makes it very easy to understand what matters.
We all know this
Have you ever stood at the end of a long queue with your weekend shopping, at the only open checkout in the supermarket? Then you will have wished that somebody would open a second one.
That situation is not so different from a customer requesting, say, a software function in a product. The customer now queues up too, usually alongside other petitioners, at product development, and waits until their wish is implemented. In small organizations with a single team, the situation for the customer is much like standing with a shopping trolley at the only checkout of a supermarket. Customer requests are worked through one after another. If a great many requests are to be implemented, the queue can become very long, just as in the supermarket. The wish for real scaling and therefore a shorter lead time is obvious.
Unfortunately most companies fail with their approaches to scaling. What usually happens is not what happens in supermarkets, namely opening a second fully equipped checkout and nearly halving the lead time through parallelization. The approach companies often choose would probably cause a revolt in a supermarket, and it would look like this:
The thought experiment
At the second checkout that is now opened you can only pay for dairy products, say. At the same time, the first checkout only handles the rest of the goods. Follow that logic and, for even more performance, further checkouts are opened for cold cuts, drinks, non-food, tobacco. With what result?
Chaos!
Customers run back and forth between all the checkouts, unload and reload, pay, and as a result move more slowly through the checkout area and out of the supermarket.
This is what real scaling looks like
What is so obviously wrong in the supermarket is everyday practice in product development. Scaling is not approached through parallelization but through simple division of labor, splitting the customer request (the shopping basket) into a frontend and a backend team (dairy products and the rest). None of these component teams is able to deliver a customer request on its own any more. In really large organizations with dozens or hundreds of teams we fragment customer requests so finely that a vast number of teams is involved in creating customer value, and dependencies between the teams grow. Which team is then responsible for overall coordination? Hard to say. So such organizations usually introduce coordinating roles: project and sub-project managers, or epic and feature owners. That increases organizational complexity and creates a large overhead that does not really contribute to creating customer value.
Dear managers, look at the checkout area in supermarkets and create product organizations with structures and teams that can create customer value independently and in parallel. Teams that understand analysis, design, implementation and test, as well as the delivery of customer value, as a team task. We call such teams feature teams.
Feature teams
Feature teams are the biggest lever for minimizing or eliminating lead times, dependencies and handovers. They make the organization leaner and create the flexibility that allows work to always go to the highest customer value. Important properties for companies competing globally for customer loyalty.
Be brave!
Topics
- Feature Teams
- Scaling
- Product Development
Interested in how this could work in your organization?
Get in touch. A first conversation costs nothing and commits you to nothing.
Read on