The case for being customer-driven. Or the “why” question.
I actually asked at some point one of my customers this question. Why do you want to become a customer-centric organisation? What I got straightaway was a simplistic and superficial “are you crazy, what else would we do?”. I am not trying to make a case against becoming customer-driven, I am merely trying to understand the reasons why you would do it. There must be a real reason besides that fact it sounds nice in a brochure. Particularly in the business world.
After having direct contact with quite a few people who are doing it, here is the conclusion. It pays off! It is very profitable to do it! Not to mention it is the decent thing to do. And here’s the relatively long explanation.
If you are truly customer-centric you will build and sell more valuable products because they ultimately deliver more compelling benefits. Consequently, you can charge more. It is proven that people who sell valuable make more money. And you know what’s the fun part? People are actually happy to pay for it. Disclaimer: I am writing this on an over-priced laptop while drinking some over-priced coffee.
Putting customers first makes you think twice about how you spend your valuable time and your customer’s hard-earned money. You tend to be more efficient which translates into reduced costs. And since this is a bold statement, we’ll revisit it later, in the second half of this story.
With more sales and reduced costs comes higher profitability. And you will need those profits because you will have to reinvest them in smarter solutions and technologies, more efficient resources and … motivation! So that you can sell more value! But you’ll keep some of it. Rightfully! And since this too seems unrealistic here’s an exercise you can do. Write down on a piece of paper the products that you love and use. And then go online and check the profitability of the company who is selling them. You may want to avoid the information about the jurisdiction where they pay their taxes though.
And probably, the most important reason of them all, you will make your customers happy. Today we don’t have to use suppliers and products we don’t like anymore because we start to have options. And those options are making us happier. Actually, I am not sure if we’re switching because the new product is better or because the old one was crappy. Keep that is mind when the airline you want to use is charging you more than they should, when you bank increases their fees or when the cab driver is being rude to you. You will figure out the alternatives for these examples, I am sure.
The business case for becoming more customer-centric is simple: more revenue, optimised costs, higher profits and customer satisfaction. Basically, all the things that every CEO should care about.
And now that you’re buying it, let’s see how it’s done.
I am pretty sure there are about a million ways to achieve it and there’s no MBA school who wouldn’t evangelise it. But let’s stick to things we know to work for sure. And since I spend most of my time with Agile tools, practices and methodologies, we’re going to restrict the list of tools to those related to Agile. We’re not going to cover what Agile is, you should already have an idea by now. If that’s not the case, let’s talk!
So how is Agile going to help my organisation to be more customer-driven?
Every Agile project starts with a vision. And in spite of giving it a fancy name, it is quite simple actually. A vision the “why”. The reason you are undertaking the project. Sort of a business case. Except, and here’s the cool part, it has to be expressed from the customer’s perspective. In other words, what’s in it for me as an end customer. What benefits do I get from you running this project? I guess for most project it is going to be fairly easy. But there will be some when it might not be easy to think of a customer benefit. This is the truly interesting part. Even for those we need to strive to find a link with the customer. If there isn’t any, why do you do it? If there is no direct benefit for the customer but you have to do it – compliance, regulation, migrations, etc. – I would be very careful about how much time and energy I would dedicate to it. Because if it is too much there won’t be much left for those projects that actually deliver something valuable. So, whatever you do, start with the customer. If you don’t, sooner or later your customers will migrate to somebody who does.
To get closer to the customers, understand them better and feel how it feels to be a customer we use personas. These are representations of end customers that are usually displayed publicly so everybody on the project team can see and understand why they are working on the project. It is so that the individual portrayed by the persona gets some benefits. You can literally see the impact you have on people’s lives, the connection between your work and the impact of the product on an actual human being.
Not only we start with a vision of the end customer benefit but we try to stay consistent with this approach at all time. Every requirement in an Agile project will have to be expressed in the same way. If the vision makes a promise, I want to see how that promised is respected and fulfilled by every requirement in the project. I say requirement because is a universal term that anybody understands. In Agile we use different names like metaphors or user stories. And not only different names but different philosophy. Every functionality has to deliver something beneficial for the end customer. If it doesn’t you’re going to really have to explain why you want to do it. Again, if it is necessary but doesn’t deliver anything valuable, fine. But be very efficient when implementing it so it doesn’t waste too much time. To make it more realistic, here the format of a user story: “As a user type, I want this functionality so that I get his benefit”. At any moment you will be working on a functionality because somebody wants it for a personal reason. This way you will be delivering value to your customers and reduce the time spent on useless things.
And because we live in a VUCA-world (that is volatility, uncertainty, complexity, ambiguity), we want to make sure we’re always in sync with our customers. They might not know what they want, might not be able to express it or, as it happens quite often, they change their minds. That why in Agile we focus a lot on getting customer feedback as soon as possible and as frequently as possible. It is common sense you might think but with Agile is also…mandatory! What I mean with that is that it is part of the framework. For instance, if you chose to do Scrum, at the end of every sprint (which typically takes a few weeks) you will do a so-called Sprint Review. This is basically a demo of the result of the sprint to get customer validation and hopefully more ideas. If your interpretation of what customers want was wrong, at least you’ll learn it fast, after only a couple of weeks. We even call this failing fast. Or, if it’s too much for your strict corporate culture, call it experimentation. But this review will also allow you to evolve the product in the way that customers think is valuable to them. You can think of this as some sort of customer co-creation of the product.
Another thing which is great about Agile is how you can easily and seamlessly incorporate changes. We capture those changes by keeping in constant contact with the customer (see customer feedback section above) and we implement them by focusing on iterations rather than on the overall project. When the team is working on an iteration they are focusing on delivering the most important functionalities at the moment while remaining open to changes that could affect the next iteration. Short term more predictive, longer term more adaptive. We also understand that changes are not actually changes. They are improvements and if somebody is asking for some changes they must a good reason for it. Our job is to make sure we make it happen.
Many people ask how do you make sure you’re always in contact with the customer? Well, the answer is we have a dedicated role for this. It may have different names, the most common is Product Owner, title used in Scrum. The responsibility of a Product Owner is to ensure that the product delivers value and benefits to the customer and manage the day to day operations related to the product backlog: talking to customers, adding new requirements, re-prioritising the existing ones, supporting the delivery team and managing the stakeholders.
Earlier we made a bold statement, that Agile will make you more efficient. That is, reduce costs and deliver more results. Doing more with less, as you may have already heard a million times. We do that by spending some time on retrospectives at end of each delivery cycle (sprint). In a retrospective the team will typically discuss how they can be more efficient. And it not just a simple discussion. They will think about how different processed might be adjusted, how new tools could be deployed so the next sprint they deliver more results. When they deliver more results per sprint (which means same timeframe and same resources) that translates into higher efficiency so more results with same or less costs.
In conclusion, Agile is vast universe of ideas, tools, practices or philosophies that should help a lot when trying to deliver more value to the customer. It is actionable, hands-on with immediate results. Try it! The worse things that can happen is that it doesn’t work and you return to the old way of doing business. Failing fast, as it were! But experience shows it will work!