What Software Developers Can Learn from Their Cafeteria

Last year I consulted to an IT project of about one hundred and twenty people working on it. The company didn't have enough space in their offices to house the project, so they leased a large, local office. Unfortunately, the only space available locally that could accommodate the project was an open office which had previously been a call center. It wasn't the ideal workplace for the team, but they "made do." The one thing people struggled with most was the canteen food—they hated it. Everyone moaned about it, yet most ate it because there were no alternatives nearby. Some people made do by bringing their lunch in from home, others coped by moaning, and others just ate the chips and then took an after-lunch nap when they got back to their desks.

As you read this, I bet you're forming an image of the canteen in your mind. Perhaps you imagine a bunch of canteen staff and management who don't care-how could they serve such food otherwise? Perhaps you're annoyed at the project's management who didn't seem to care—how could they let things get so bad? That's what I thought when I first visited the office, but it turned out I was completely wrong. In turn, I also rediscovered something that's useful for software developers.

The canteen staff and management did care (as did the project's management, but I'll come back to them later). The guy who ran the canteen—a nice chap called Graeme—was a very engaging guy who always gave great service. One day, he told me that he was genuinely hurt because his boss kept getting negative comments back from my colleagues about the quality of his canteen's food. Yet, Graeme was proud of what his team accomplished given the severe budget constraints they were under. He said that he'd love to do better, but this wasn't the Ritz and his hands were tied.

He said that they'd put out a comments and suggestions box a few weeks earlier, but he got little feedback. They'd added a few items to their breakfast menu that sold OK, but they didn't make a big difference to their takings. They'd also started serving special meals. They were a little bit more expensive than the normal meals, which they were contractually obliged to sell at low prices, but they'd been quite popular despite being more expensive.

I nodded as I chewed over what he'd just said. They had put on special BLT Panini for lunch, and, although they weren't spectacular by high-street standards, a few of my colleagues had commented that they were nice which I relayed to Graeme. He said he was pleased but he didn't look all that cheered up. I felt sorry for him, but I didn't know what to say. There was an awkward silence that I felt I had to fill, so I burst out, "You know what Graeme? I'd quite happily pay more if the food were, um, more up-market."I was surprised by my comment, and so was Graeme.

"Pay more?"

"Yes, and I bet a lot of the people I work with would, too."

"Pay more?" he asked again.

"Yeah," I added, realizing that I was on to something. "And you know the coffee you sell? I'd quite happily pay five times what you currently charge if it were good, strong espresso."

"You don't like the instant stuff?"

"Not really."

He told me that they'd tried selling good, expensive coffee in the previous year, when the same office space was used as a call center, but no one bought it.

And that was then the light dawned. Our project's facilities department was still operating on the lease set up when call center staff was the main user of the canteen. When my client's facilities managers negotiated the lease, they specifically negotiated low canteen prices in order to keep their staff costs down. The problem was that what the call center staff thought of as "good value," the more highly paid IT folk thought of as "cheap slop." In coffee terms the canteen service wasn't even offering the "small" cup, let alone the super-sized cappuccino topped with whipped-cream. They were annoying their customers with poor choices and losing money because of it.

Without using the words "cheap slop," I explained my theory to Graeme. He thought for a moment then said that, in that case, he was sure that he could find a way to sell more "up market" food at a higher price which would keep us happy with new choices, and, at the same time, continue selling the "value range" items which some of his customers still wanted and which he was contractually obliged to sell. His eyes glazed over for a moment as (I suspect) he worked out how the higher margins from the up-market food would positively affect his canteens profits. I've since done the numbers and since most of his costs are fixed, not matter how many customers they served, Graeme could easily have doubled his profits even if only one in five of his customers "upgraded" to the higher margin products.

So, what's this got to do with the world of software development?

Well, to start with, I think you get a lot more work done if you have access to good quality food and facilities and if you feel like you're working for someone who cares about you, but that's not why I wrote this article.

Also, I find it fascinating how digging down into the causes of problems by politely asking "Why?" a few times can help you lead to false or no-longer-valid assumptions and then to simple improvements—but you already knew that.

No, the reason why this is important is that if you, like Graeme's canteen, serve many customers, but you only charge one price then you may be charging some customers less than they're happy to pay—or charging others more than they are willing to pay. Just like Graeme, you need to find a way of charging different prices for your product so that you not only make as much money as you can, but you keep your customers happy. Marketers call this "customer segmentation." Look around and you'll see that this is common business practice—one that we all benefit from. A few years ago in the UK, Microsoft released a low-price home—and—student version of Microsoft Office. By doing so, they made it possible for students and home users to use their products at a reasonable cost, and Microsoft made more money. It was, in other words, a win for both parties. Airlines have been doing similar for decades, charge massively different prices for two seats next to each other on the same flight depending, often, on how far in advance the flight was booked; they also charge much higher prices for business and first class seats, giving their customers the opportunity to pay more or less, according to their budgets. Some big-iron computer makers are reputed to have done the same by selling two versions of the same mainframe—one high powered, one low powered—where the only physical difference between the two was an additional component which slowed down the otherwise full-powered machine. Supermarkets sell their "own brand" products at much lower prices than the better known but similar big-brand products.

So what can you do? If you sell a software product but only give your customers one price, then consider how you can charge a variety of prices for the same product—perhaps an individual version, a professional version, and a corporate version. Perhaps the individual version is a free, but less powerful version of the fully featured professional version, and the corporate version adds on the ability to use corporate databases. If you're used to treating all of your customers alike, you'll have to start treating each market segment differently—they'll each have different budgets, priorities, and needs from your product.

Wherever you work, whatever your role, you may find it profitable to sit down for fifteen minutes with a nice strong cup of coffee and a couple of blank sheets of paper. Ask yourself, "Who are my customers?", "What do I offer them?", and "How are they different?" Jot down your answers. Then talk to your customers and colleagues and ask them the same questions. Jot down their answers. You may be pleasantly surprised by the results.

The same idea applies even if you work in a corporate IT department. The project I mentioned at the start of this article is a good example. Like many software projects, when this team spoke of "the customer," they referred to the dozen or so "subject matter experts" who worked with the IT team to identify then flesh out the project's requirements and features. The subject matter experts knew their business well and were easy to work with, but they weren't the only customer and they weren't paying for the project. One of the project's biggest problem was that the designated customers would eventually have to work with the resulting software. They kept ordering the super-sized white-chocolate frappuccino when their bosses only had budget for a tall americano, also known as the "minimum viable solution." The project ran into major difficulties until the two customer segments aligned their requirements.

Say you work as a freelancer (or contractor here in the UK) and you're finding it hard to find work in the current economy? Try segmenting your customers. If you normally work on longer term contracts and that work has dried up, then ask yourself if there are potential customers out there, perhaps with smaller budgets, who can't afford to hire you long term, but could pay to have smaller pieces of work done. If you don't know how to find these potential customers then ask your friends and family if they can ask their work colleagues if they know of any such work. A few weeks of good work ending with a satisfied customer may well lead to more work with the same customer, to a reference site, or to another recommendation.