This is the third part of a series of suggestions about what can be done to start making software for the aerospace MRO industry simpler. So far I have discussed being more open and the importance of User Experience (UX). Today I want to discuss how MRO software developers interact with their customers and in particular saying “no”.

Part 3: Learn to say “No”
I have spent my entire working life dealing with customers in one way or another. I’d like to think I’m quite customer focussed. Even whilst working in internally facing IT departments I always have treated those to whom I am providing a service as a client and it has usually served me well over the years. I think this comes from my teenage jobs in the retail industry… specifically selling Fast Moving Consumer Goods (FMCG)… that’s being a barman in layman’s terms.

I was always taught that the “the customer is king” and of course that “the customer is always right”…. Those two rules along with the fact that you should never discuss politics or religion with customers and “first impressions last” are business rules that I learnt as an impressionable 18 year old that I have never, ever questioned… until recently.

This year I picked up a book called Rework by Jason Fried and David Heinemeier Hansson and in there was a chapter entitled “Say No by Default”. The chapter begins with a quote by Henry Ford:

“If I’d listened to customers I’d have given them a faster horse”

They go on to discuss the integrity of your product and that customers should not be allowed to interfere with your vision. They provide examples where this has proved commercially successful or where it is downright obvious... like chefs for example. You wouldn’t expect a chef to change their lasagne recipe just because one or two pernickety patrons said it needed more bananas.

Although I squirmed a bit at first this message started to make sense… especially when there was a tech product involved. As I looked around I noticed more and more tech evangelists and successful creative types advocating a similar philosophy.

It got me thinking about all those times that I had argued with a client about a software feature but eventually graciously backed down, because they were the customer and had to be right…. No!! I was right all along, they were wrong! What do they know about software?? Idiots!! I’ve been brainwashed all these years….

Ok, maybe calling them idiots is taking it too far... there’s no need to be confrontational. I have learnt that bowing to every customer request is bad in so many ways.

Adding features adds complexity
Pretty obvious really: You make software simpler by removing, hiding or shrinking features. Therefore it follows that by adding features you are making it less simple. You run into the argument that it is only one additional field, one line of code etc etc what difference does it make? But as one Product Manager I know used to complain – “it’s just the thin end of the wedge”… where do you stop?

Quite right too…. I hereby apologise to any product owners and managers that used to despair when I rolled my eyes on hearing those words. Please know that I am deeply sorry: I have changed!!

In a recent discussion on the LinkedIn Aircraft Lifecycle Wikinomics Discussion board related to this thread my colleague Wayne Enis stated:

Most MRO software vendors don't have a huge pot of gold to design, develop & deploy a solution without a customer, nor should they. So a customer will play a significant role in the initial design process, the lead customer often ends up with an almost bespoke solution. Now, we talk about the MRO process, but whilst the start and end of the process may be the same across MRO's, the bit in the middle, where 99% of the work is done, can vary wildly between organisations. So, the second customer comes along and wants just a few changes to support their current processes and so on… For the MRO software vendor of today, this is marketed as a selling point, the fact that a new customer will benefit from 'industry best practice' of over 50 (or 60 or 70) other MRO's. In reality the software ends up bloated with features and functions that are only used by a few customers but end up being a distraction and confusion to all of the customers. It's at some point along this path that the software vendor thinks up the concept of 'switches' that can dictate how the system undertakes certain processes. Not just 1 or 2 switches that might dictate the use of process A or process B, or dictate using UI layout A or B; but 500+ switches that define much of the minutiae of how the system works under the hood. Whilst that sounds a perfect solution, nobody ever knows what the switches really do under the hood, and it becomes impossible to determine which switches can be used together (or which ones will cause problems if used together). From a QA perspective, it becomes impossible to test the system in all possible permutations. It is this level of complexity that makes the operation and usage of such systems so onerous.

There is a belief that designing software in this way is a customer focused design paradigm, incorporating the customer's requirements into the software model. But is that really the case? The customer may get what they want at the outset, i.e. a new field on the screen, or a new function in the system, but when that customer takes an upgrade in 12 months’ time and they get another 10 fields on the screen that other customers have asked for, and their new function works differently, how customer focused is that?

Manage Customer Expectations
So, you’ve decided that it’s a bad idea to cave in to every customer request and you’ve empowered your staff to say no, it is now vital that your customers are educated as to the reasons why you are refusing what to them seems like a perfectly logical and reasonable request. People can be surprisingly understanding about this way of working if you take time to explain to them your point of view and show willing to help the customer achieve a suitable way forward. This might mean a change of customer’s process; the development of an external tool (providing your software is open in the first place – see Part 1); or it could be that they take their problem elsewhere. You might even win them over to your way of thinking. In the end it is better for everyone that your product is not spoilt for the rest of your users by changing it for one customer.

Next week in the last part in this series I will be discussing Introspection in the MRO software industry.

Related Posts:
How to make Simpler MRO Software: Part 2
How to make Simpler MRO Software: Part 1
Why MRO Software isn't Simpler
Why isn’t MRO Software Simpler?