The customer is considered more and important for software development. Software teams have to delivers products and services that solve the needs of their customers. But understanding what a customer wants isn’t always that easy.
In the “old days”, it was all about requirements. Make sure that you get all requirements on paper, and have them sign them to know for sure that it is what they need. We all know now that this doesn’t work; you simply cannot get everything on paper, what is written down is often ambiguous, and in time the needs will change. So a new approach was needed.
Newer development methods focus upon interaction with the customer. Like in Agile methods, where customer collaboration is valued more then contract negotiation. Those teams use iterative development to frequently deliver solutions. By giving demo’s of the solutions, and asking for feedback, they try to build a better understanding of what the customer needs.
Many teams look at their customer as a department, another company, or somebody out there who buys the software or uses the system. But customers are persons, just like you and me. They get up, go to work, drink coffee, talk to people, and want to make their customers (and bosses) happy. So even if you don’t know them (which is often still the case), they are really human, with good and bad habits, just like you and me.
For me, a customer is a role, not a person. A role in which a person uses the products and services that we have delivered. Similar to how I use products and services delivered by other people, then I’m acting as a customer. When thinking about my customer, I put myself in his/her position, and ask myself: What can I do with the new product that I can’t do right no? How can this new service help me? Why would I use it, what’s in it for me? I try to walk a mile in my customers shoes, to understand what value they would expect to get from my products and services.
I remember my first project that I was asked to manage, which had to deliver embedded software for a CNC machine. Previous projects that had tried to develop that software failed to deliver a stable working product, or were stopped since they weren’t able to deliver anything. So the customer had lost its trust in the product. I’ve put myself in the customer role, and was thinking: “what would I want”? The answer was easy: I didn’t want plan or a planning, or complex documents that would describe how the problem would be solved? I just wanted working software, something that would at least do a part of what was promised years ago, a first version of the product! It didn’t have to do much, but what it did should work without problems. That would help me as a customer to regain trust, and start to believe that my supplier would be able to deliver a solution to my problem.
So back to my role as a project manager. I did a minimum of planning, just a couple of increments in which we would start delivering parts of the product. The first deliveries would not be on the target hardware, but on a PC. It would only do some of the basic (but still important) functions, and have a small user interface shell in stead of the extensive graphical user interface that was required in the end product. We showed this first iteration to the customer, and since it was running on a PC he took it home and tried it out. Meanwhile we developed the second iteration, which contained additional functionality and we also solved the few problems that the customer found in the first iteration. Again we showed him this iteration, and he saw that the new functionality worked good, and the problems that he had reported on the previous version were solved now. We kept delivering iterations every couple of weeks, until the software had sufficient functionality to integrate it into the embedded product, and release it on the target hardware.
By playing the role of the customer I understood what he wanted, and together with the team we managed to deliver that in short cycles. Based on the contact with the customer, we got a better understanding on what was needed, and what not. It turned out that some of the problems that the previous project had tried to solve would not happen in practice; end customers would never use the product that way so it wasn’t required for our software. We saved time and money by not developing it. The way we worked was very much appreciated by our customer, and by the team and my manager (quite important since it was my first project, back in the early nineties). It was a win-win for everybody.
This all comes back to understanding your customer. If a customer wants a big detailed plan (which can be a very valid question if he needs to align the work we do with his own work), then I’ll make a detailed plan. If he just needs to know the main items that I will be doing, I’ll make a shortlist. But I always maintain close contact with the customer, and frequently ask for feedback to make sure that I understand what he needs, and why.
Why not think like a customer for a moment? Try to look at the product that you are developing from a customer point of view. How can it help the customer to do his/her job better, or to save money, or time? When you want to know more about what your customer wants, then just for moment assume you are the customer, and think what you would need. You will get a different view of your product, and it will help you to understand what a customer really needs. Because in essence, we are all customers!
