Zsolt Fabók

Practical ideas on kanban, lean, scrum, xp, java, programming…

Customer Diversity

in management

Last year at xp2010 Scott E. Page talked about the benefits of diversity inside an organisation. According to Scott, diversity improves the performance and decision making process of an organisation.

Today late afternoon I attended a startup meetup event where Patrick Vlaskovits talked a bit about the diversity among customers. Based on his experience startup companies should define themselves a specific market segment - their customers - which they can serve properly and are really passionate about.

Imagine that a company works with a variety of customers. Different people want different things - sorry for the cliché - and there is no way that a startup company can deliver a feature or a set of features which satisfies all of them. This eventually will cause dissatisfaction among the customers, and they’ll leave the company. Fewer customers means less revenue or no revenue at all, and the company shuts down.

Startups aren’t necessary small companies, actually, their size does not matter that much, but their passion really does. People start companies because they have a good idea, they see something in it, and finally but not least they are passionate about it. If the ”not-the-target” customer wants a feature which the company is not interested in at all, it is pretty sure that there won’t be any passion in working on that feature. Without passion the product will lose its edge, and the real (target) customers may leave.

It seems that a company can really benefit from the diversity among team members, but on the other hand, it causes trouble if we are talking about customers.

Patrick told us an interesting story about target segments and passion. His friend runs a startup, and one day a customer came by and offered a huge amount of money (we are talking about millions) for certain features. This particular customer wasn’t in the target segment, she gave only the 30% of the usage of the product. They didn’t really like to work with that customer, and they weren’t that excited about the requested features either. They turned down the offer, and guess what? They are still on the market and the company makes more money than before. They chose a smaller group of customers over diversity and money.

According to Patrick, for finding the right market segment it is not enough to know what the customer wants, but one should definitely know

  • who the customer is exactly

  • why the customer wants that particular feature

In order to corroborate his statement he told us about two companies - Southern Airlines and Walmart - who asked their customers for feedback and possible new features. After receiving the customers’ feedback, Southern Airlines started to think about why the customers want the new features and by the way, who they are exactly. Spending some time on background checking was worth the effort, because it turned out that the majority of the targeted customers want the new features and actually it will be useful for them. Unfortunately, Walmart didn’t go that far. They asked customers to fill out a survey, and took the result as it was. They chose the ”if the customers want this, we’ll give it to them” approach. Later on it turned out that the customers “just” filled out the survey and what they asked for wasn’t really necessary - on the contrary: they didn’t like it at all, which resulted in loss of revenue for Walmart. (More details about the stories are available here and here.)

The difference between the two companies is that the first company focused on the ”who” and ”why”, while the second company just took the ”what” and implemented it.

Actually, there shouldn’t be anything new in this for agile teams, because they know that a good user story description looks like this:

As a ROLE I want A FEATURE in order to ACHIEVE SOMETHING

  • The “role” defines the ”who”

  • The ”feature” defines the ”what”

  • and lost but not least, ”achieve something” defines the ”why

Most of the teams I worked with stopped at the feature (the ”what”) and never put too much thought into the role and what the customer wants to achieve with the feature.

Let’s go back to the diversity issue. After the event, I remembered that I have faced the very same problems during my career. In my first project we had only one customer, who sometimes had trouble defining what she wanted, but in the end, our code base reflected only her desires. It was maintainable, testable, and understandable. A little paradise.

Unfortunately, one of my latest projects was completely different. Project management wanted us to maintain an application used in six continents. There was huge diversity in the customers’ desires, and our code base was chaotic. There was no way to satisfy every customer, but we had to do it anyway, or more precisely: we had to try…

What I learnt this evening is that when I start something new or participate in something new,

  • it should be clear which customer segment I want to work with,

  • who they are and why they want to use my product

In case I cannot answer those questions, I shouldn’t start anything, because it will probably fail.

Related posts you may find also interesting:

Comments