How to make Customers Happy

I’m sure many a developer and creative service provider is on occasion pondering that very question. Well, it could be achieved with chocolate, wine, super low prices, etc. But it would probably work better with ongoing communication and active inclusion of the client in the development process. But how to put that rather abstract notion into practice?

team-meeting

You might know that IT joke, “How do you spot an extroverted IT guy?” …insert break to give other person time to think…answer: “When he talks to you, he looks at your shoes.” Ha!

Ok, maybe that joke is slightly funnier when you actually hear it. Still, there’s a little bit of truth in it, at any rate. Even the best developer will not manage to make the customer happy, when they don’t speak the same language (and I mean that figuratively. Although *literally* speaking the same language won’t hurt either) and when they’re thus not able to work on the best possible solution together with the customer. “Ok, so that’s it?” Not quite.

Because that takes care of the technological realization, but not necessarily of the customer’s needs and wishes. Therefore, it’s also important that a person who has spent years studying and learning to code can actually explain complex technological issues in a way that anyone could understand. Only then will someone without that background really be able to make impactful decisions which influence the entire project and its output.

Before the project …

In my experience, it’s very important for the developers, the project lead and the entire team to precisely understand the customer and their target audience, as well as the planned use case. Also a certain amount of insider industry knowledge is necessary for a successful solution. Otherwise, a project that disregards the customer’s (or worse, the users’) needs completely, is likely to develop.

In my opinion, that’s one of the greatest money pits – the conception and implementation of technical solutions for which the customer has no need and which the user’s can’t work with properly. If you can establish from the very beginning, who will use the software (app, website, etc.) and what they users should be able to accomplish with it, you’ll avoid wrong turns and problems in the long run.

That’s why we’ve started to do so-called ‘technology workshops’ with our customers before we actually get started on the project. Such a workshop mainly serves to present new and unfamiliar technologies and concepts to the clients and to understand them, their customer base and their industry. Together, we then conceptualize the solution that works best for them

Some questions and issues usually discussed during a technology workshop are:

+ What are the goals of the project?
+ What are the expectations of the various parties for the finished projects?
+ Can these goals and expectations be measured or quantified?
+ What’s the target audience, who will use the software?
+ Who will benefit most from the developed solution?
+ Where does the project fit within the global company strategy?
+ Are there any risks or issues which could affect the project’s successful completion?

costs graph

fixing errors early will save you a lot of time and money

Only when these questions are answered, we’ll select the technology which fits the project best. More often than not, we’ll be asked to pitch an augmented reality app, but after some discussion what we’re actually asked to develop is an online 3D product configurator or a web page. Maybe someone approaches us about bluetooth beacons, when the perfect solution is actually an AR app… and occasionally someone wants to buy, say, a Porsche on the budget of a Fiat Panda 😉

When you consider how easily such fundamental changes of direction can be handled early on, it almost seems foolish not to schedule enough time for the design and conception phase. It’ll save you at least twice that during development. Because once you’ve started heading in a fixed direction, changes and problem fixes will be harder and they will cost you a lot of time, money and energy.

During the project …

So what exactly happens when you eventually start on the project and you (think you) know everything about what the client needs? You start coding, of course. Then the client will see or hear nothing from you for a while, the anticipation will grow. And then, suddenly, after a long silence, you hand over the software, proudly and eagerly awaiting the customer’s reaction. And the conversation might go something like this:

You: “Tadaa, dear client – here’s your finished product!”
Client: “Well, that’s not at all what I expected!”  – or, a little worse
Client: “That’s not what we discussed!”

These things do tend to happen when you work with the (classic, very well-known and sometimes totally useless) waterfall model. Meaning that first, you plan and conceptualize, then you develop it and then you’re done. Over the past few years, however, a different (and dare I say better) project management system has found its way into the IT sector, which is way better suited to software development and creative processes in general. This system is called Scrum. The big difference when compared to the waterfall model, is its iterative approach and the inclusion of the client in the process.

We use this system daily, in that we will send our clients test versions of the software on a bi-weekly basis and ask them to try it and give us feedback. So, you can imagine that there are many advantages in doing it this way. The client will be able to imagine what the finished product will look like early on and can influence the course of development in between the various iterations (which are called sprints). Additionally, some problems only become noticeable once you actually start using the software. So you basically collaborate with your client to produce something that will perfectly fit their needs.

Further, in order to make the relatively abstract process of producing software more tangible for the client, we use the free online tool ‘Trello‘. Here, you can make the entire development process very transparent and the client will at any time be able to check on the progress and see which Tasks are in the ‘ToDo’, ‘InProgress’ and ‘Done’ columns. They can add their feedback and input too, which means that no crucial information will be lost in the inboxes of various developers. You can also define clear responsibilities and due dates, which greatly helps you to structure your project and to make sure no tasks remain incomplete due to unclear communication.

trello_E

examplary trello board with multiple lanes

Since we’ve implemented that system in combination with regular status updates (in person or on the phone) we receive about 80% fewer emails and telephone calls from clients wondering about the project status. I think we can agree that this makes everyone’s life easier and allows the developers to put all their energy into the project at hand.

After the Project…

What we’ve learned over the past few years is this: Only because the project is done, that doesn’t mean it’s really finished. Sometimes you’ll only become aware of a few problems once people start using your product. These are either problems that you didn’t think of or they might be problems you could never have foreseen. Therefore, it’s important to also schedule enough time for improvements, updates and further development after the project is ‘done’. To accomplish this, we collect feedback – yes, you guessed it – with Trello. Thus, we can bundle useful features and extensions for use in later versions.

Right, I almost forgot the most important thing. When you have successfully managed to make your customers happy before, during and after the project, you should never forget to thank the customer and to celebrate appropriately! Of course, I now have to ask myself the following question: does writing this blog post count as finishing a project? Hm, I would have to say, yes! 😉