When talking to my business clients I like to ask the question: “Why do you want to become a customer-centric organisation?” And the response I usually get is along the lines of: “What else would we do?”
Despite it being the decent thing to do, as well as sounding good, there is another, more important reason to becoming customer-driven – it pays off. In other words, it is the profitable thing to do.
If you are a truly customer-centric business you are more likely to build and sell more valuable products because they ultimately deliver more compelling benefits. And consequently, you can charge more for them.
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.
With more sales and reduced costs comes higher profitability. And you will need these profits because you will have to reinvest them in smarter solutions and technologies, more efficient resources and motivation – in order that you can sell more value. But at least you’ll get to keep some of it. (One way you can see examples of this is to write down the products that you love and use, then go online and check the profitability of the company who sells them.
Finally – and probably most importantly – you will make your customers happy. Today we don’t have to use suppliers and products we don’t like anymore because we have more options. And these options make us happier. (Whether we’re switching because the new product is better is unclear – but when an airline you want to use charges you more than they should, when your bank increases their fees or when a cab driver is rude to you, finding alternatives feels good.)
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.
So how is Agile going to help my organisation to be more customer-driven?
Every Agile project starts with a vision. A vision is the “why”. The reason you are undertaking the project – the business case. Except it has to be expressed from the customer’s perspective. In other words, what’s in it for me as the end customer? What benefits do I get?
If there is no direct benefit for the customer, but you have to do it for compliance, regulation, migrations, etc. be very careful about how much time and energy is dedicated to it. If there is too much, there won’t be enough left for the projects that actually deliver something valuable.
To get closer to our customers, understand them better and feel what it’s like to be a customer we use personas. These are representations of end customers that are so everybody on the project team can understand why they are working on the project.
Not only do we start with a vision of the end customer benefit, we try to stay consistent with this approach at all times. 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 promise 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.)
Every functionality should deliver something beneficial for the end customer. If it doesn’t, you’re going to really need to explain why you want to do it. To make it more realistic, here is the format of a user story: “As a user type, I want this functionality so that I get this 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 (volatile, uncertain, complex and ambiguous), 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 is why in Agile we focus a lot on getting customer feedback as soon and as frequently as possible. With Agile this is mandatory, meaning 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 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 great thing about Agile is how you can easily and seamlessly incorporate changes. We capture these 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 iteration they are focused 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 there must be a good reason for it. Our job is to make sure we make it happen.
Many people ask how you make sure you’re always in contact with the customer. The answer is by having a dedicated role for this. It may have different names but the most common is product owner, the title used in Scrum.
The responsibility of a product owner is to ensure that the product delivers value and benefits to the customer and manages 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 I 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 the 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 processes might be adjusted, how new tools could be deployed so the next sprint delivers more results. When they deliver more results per sprint (which means same timeframe and same resources) this translates into higher efficiency so more results are achieved with the same or less costs.
In conclusion, Agile is a 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. The worse thing that can happen is it doesn’t work and you return to the old way of doing business. But experience shows that it does work!