Every Friday we go to this cozy restaurant to enjoy a nice meal after a great week of work. It’s those kind of small places where the food quality seems to be the inverse of the restaurant size — really good traditional food served to a relatively small amount of people.
In the past weeks the service has become poorer though, with food taking more and more time to be delivered. That culminated past week with the meals taking around 2h to be delivered to our tables since we arrived.
It was Friday night — we weren’t in a hurry to go nowhere. Even though we can spend a good time together and chat for a while, 10 hungry people inevitably get a bit grumpy after such a long-time.
There were a few things that didn’t help:
- They served less appetizers & starters than usual, which normally helps keep the mob happy while they get the main dishes ready.
- They forgot a few times to bring us some of our orders (as drinks).
- The waiters in the room were scarcer than ever, which made it harder to ask them for starters.
- No one ever came to us explain what was happening, or to tell us how much more time we should expect to wait.
We then got up to find a waiter, and ask him what was happening. He finally shared with us: We have a new cook since a month ago and he is still having a hard time the pace of these busy days.
Taking this info and the various indicators, we could imagine how things were going on the backstage: we didn’t see much of the waiters because they were all inside helping the cook — I had the opportunity to be on a restaurant kitchen in moments of stress as these and it’s not pretty — , and consequently everything else outside the kitchen was being forgotten.
While waiting, we gradually reverted to this grumpy pre-historical homo sapiens who were in pain for lack of food at 11PM.
From that moment all conversation topics revolved around the situation. Eventually we realised that the same pattern does also happen in Product Development.
What product teams can learn from restaurants
Set the right expectations from the beginning
We were one of the last groups arriving in the room, with the space mostly full already. It’s probable that the delays started (or were at least expected to happen) even before we arrived, so it would have been great if they noticed us that food could take more time than expected. It would not be great news, but at least we had the right expectations from the beginning.
The same happens in Product Development: The soonest we find something will take longer than usual or expected, new expectations should be set and shared.
It’s hard to give the news, but it will be harder later when they don’t see the deliveries when they were expecting them.
Keep showing progress
We were a group of famished individuals. The best thing the restaurant could have done was to keep feeding us with snacks. Which snacks wouldn’t matter. Just keep our stomachs entertained and probably the appearance of our grumpy selves would have been delayed.
In Product Development, when feature development is delayed, or issues arise, teams tend to become distracted with that work. On the other side of the screen, you have users or clients completely in the dark of what’s happening.
Two weeks after the expected date you appear and say: ”Hello. Sorry for the lack of news, but we have been focused in finishing features X and Y.”
You may have been working a lot, but no one has damn idea since nothing has been released. All they see is a stall product.
So, besides setting and updating your users’ or clients’ expectations in a frequent manner, please keep delivering new features. Keep showing progress. Keep shipping.
Distribute the the different types of tasks through the team (which I understand to get much harder if you’re just 1 or 2 people). Even if you’re stuck with a big feature, strive to keep delivering small snacks.
Train for the worst
Bill Walsh was one of the few coaches in the NFL winning 3 Super Bowls. His philosophy consisted in training in the most precise manner (ex: if the play consists in having you run 23 yards, that’s exactly how much you should run. Not more, not less.).
That’s because he believed that the human brain doesn’t think well when under pressure, thus leading to mistakes. To avoid that, he strived to turn plays the most mechanical possible — this way you didn’t have to think about them when in game. Everyone in his team knew, all the time, where they should be precisely positioned and exactly what to do in every moment of the play. All of this almost without thinking.
The same goes on a restaurant or a product team: when situations of high pressure come, everyone must know their place.
When the kitchen goes wary, the waiters should know how to help the cook efficiently, and maybe the cashier or the maitre d should move to the room to temporarily help with the table service. They must know how to keep the conversation going with the clients, update them about the status of the dishes, and keep delivering the snacks.
When a critical issue appears on the production server, part of the team should focus on communicating with the users or clients while the other part focuses on fixing the issue.
Don’t let your clients hungry
The waiting time at that restaurant wasn’t a pleasant experience, but that lead us to discuss the similarities between Product Development and the process of delivering food to our mouths, which you were able to read in this post.
At the same time, I believe this lead us to become a bit more tolerant — we may not have a restaurant to take care, but we have made some of these mistakes in the past. This helped us get some perspective of being on the side of the client, oblivious about what’s happening and gradually less happy with the situation. The important part is always to think through what went wrong after things calm down and work hard to not repeat the same mistakes.