Customer Success Over Customer Satisfaction

In the software services industry, sometimes people become lost in the jargon (e.g. “timely” and “quality delivery”), delivering what the customer is looking for, getting new business from the customer, etc. The conversation revolves around statements like, “We have a team of 100 people working for XYZ customer” and “This customer account is very important for the organization, and we are looking for 25% growth in revenue this year.”

The conversation sometimes may show concern, but mostly from the vendor’s perspective and with an “us vs. them” mindset: “This time, yet again, the team is not able to work on the next release and instead is working on ‘business as usual (BAU)’ work. The reason being, the customer is going through a lot of restructuring yet again. It happens all the time at their end.”

I sometimes feel that the conversations should instead revolve around questions like:

• Are we helping the customer generate more money (i.e., business value) with our software delivery? If not, how can we help the customer move towards business success and goals?
• We may be earning millions this year from this customer account, but what about the customer? Do we care, or should we care?
• Delivering something that the customer asks for is fine, but is it helping the customer move towards business success?

The reality sometimes remains that even when the customer is experiencing revenue loss for the last few years, the development team’s focus still remains stuck in detailed level delivery goals like improving the current product quality, test automation, or rewriting the whole application to remove technical debt. This leads to disaster for both the vendor and the customer. Eventually, the customer may be out of business, which doesn’t serve any purpose for either side.

With that, it seems logical that software delivery teams should work towards customer success. But then the counter-argument may be, “We specialize in software delivery, not helping the customer make business decisions. It could be true some years back, but unfortunately not anymore.”

With Lean Startup’s arrival on the horizon, development teams have started working with a mindset of “discovering and building products and services that people love using disciplined, scientific and capital efficient methods.” Recently, GlobalLogic started taking a Lean Startup approach to software projects, as well. Agile from a delivery perspective and Lean Startup techniques from a business success point of view complement each other very well. Here are some examples:

• Instead of looking at revamping the product with new technology and architectures -- and in the process keeping the product roadmap stagnant for a year, which of course may be a great business opportunity for the team -- the team instead asks, “Is this the right thing to do from a business point-of-view? If not what could be the right balance?”
• Instead of building a big feature right away after spending 2-3 months on it, teams use a “Fake Door” UX pattern (i.e., only building the important bits, faking the rest, and testing on real users). This approach helps teams identify if end users really want a certain feature or not, helping them understand whether to build it with very minimal costs instead of learning what users want when it's too late.

Summary

It’s not about the tool box or techniques (i.e. Lean Startup), but about the mindset that makes development teams partner in customer success or failure. In a startup world, customer success has already been proven to be the best kept secret of the hyper-growth of those startups. A similar mindset is required in services industry, as well: customer success is your success.