What Is A Customer?
For a while now I have been developing a system - COMPASS - to help the owners of software businesses focus more of their energy on what gives them the best chance of success. The “C” in COMPASS stands for ‘Customer’ and it’s appropriate that it is the first of the strategic pillars of the approach.
While it’s a cliche to say “the customer comes first” the sad reality is that where software is concerned it’s actually rarely true! Often the product idea is the real star and the customer (or more likely the assumptions about the customer) exists mostly to serve the product. I think the root of a lot of very expensive software failures begin here.
If you want to improve your chances of building a successful software business you should be a lot less excited about your product/service idea and a lot more interested in the needs and habits of customers.
If I asked you “What is a customer?”, I suspect you wouldn’t have any hesitation in answering. Your answer would probably be something along the lines of, “Someone who buys my product” or, “Someone I sell to”. Neither are wrong, but these definitions can blind us to how people engage with our products and to categories of people we should definitely care about when building software products.
My definition of a customer is “anyone whose behaviour we seek to change”. Going from ‘non-buyer’ to ‘buyer’ is certainly a very common change of behaviour we may seek. But in selling our product to some customers we may also need to change the behaviour of others in different ways. We may even require them to stop behaving in a way that does not work for us (or them).
The reason for defining customer in this way is to change our focus from seeing customers as buyers and as inert, passive, recipients of our product, to a more inclusive view of an inter-related cast of active participants, each with a range of behaviours that we need to understand and shape if we are ever to expect them to engage with us.
The truth is that *all* software is, inherently, about changing behaviours. We are either enabling something that could not be done before, or otherwise altering an orthodox way of doing something to a new, and hopefully better, approach.
For example online banking applications have facilitated a change of behaviour from visiting (or phoning) my branch to ask for my current account balance to opening an app and viewing it there. In the future we may imagine changing our behaviour again. The new norm may be “Hey Siri, what is my current bank balance?” Would that work? Maybe only for people comfortable sharing their bank balance with fellow passengers!
Sometimes such changes are very natural, and sometimes they create opportunities that people have wanted (even if they didn’t know that they wanted them) for a long time, and this is easy. For example people didn’t really realised they needed a full mobile web browser until Apple came along with their iPhone and made it so easy to have one (and, along the way, disproved the notion that people wouldn’t use a phone without a hardware keyboard - another behaviour change).
What I am trying to emphasise is that, in building software products, we would all be better off if we started to think about customers as a set of interrelated needs and behaviours. That is, we need to focus on their needs and current behaviours and realise that ‘better’ means change in those behaviours. So, we must also ask ourselves, “How we are going to achieve change?”
If we were sat together I would be asking you, “How do your customers behave now? Are there people whose behaviour can negatively impact you? How will these changes of behaviour affect your thinking?”