Understanding client needs

Using lean software design to get to the point and produce a tool the client uses and is happy with

3 min readApr 23, 2014

I've worked on several projects during my years as a software developer, and I feel I have learned an important lesson: You don’t understand what the client wants, even if you think you do. Well, let me rephrase that: the client doesn't know what he wants.

We've all been there: someone asks you to develop something that he\she will use for day to day work etc. What I used to do is go back to the stuff I learned in school:

“Do a system analysis and take into account: the stakeholders, the stories, the needs, etc. Plan the new product as much as possible from the get go. The more you plan before you code, the better.”

Now you’d think that having done all that, and afterwards embarked on the code writing and testing, will derive a good tool that the client will love. Well, not exactly. I came to realize there are always changes. Something has been forgotten (by the client). Generally something big. Some big functionality was not taken into consideration, and implementing it at this stage means many many changes. OK so you implement them, but the product is still not perfect as the client might have changed his mind in how he wants things to work, or you discover the product you've built is getting underused (80% of the features are not used at all).

After that has happened with more then one client, so I couldn't blame a certain person anymore (“it must be him. He’s too indecisive”), I started thinking that there must be an easier approach to write tools that people actually use. And I think I found the correct way to do it.

Think Lean

For the starting point, try to gather from the client the most basic functionality he needs. Refine that further, striping down all features. Do a minimal list of the features, so that the functionality is met and still the client is happy. This is your first version. Now you can start working.

The client might want more

That’s Fine. You can say “yes, you can get that in version 2. Let’s get the tool working first”.

The client will change his mind

Keep notes of the features the client complained he’s not getting in the first version. Chances are you’ll never implement them; Most of the time the client, after using your working version, will have a different approach and will understand he needs something else entirely.

Keep Lean

Now each time a need arises for more functionality (this generally comes from the client), do the same process: derive the minimal list of features needed to be added to meet this new functionality, and do just that. Keep doing those lean iterations and what you’ll get is a tool actually being used, with a happy customer using it.

I hope you find this approach suitable, and think you should give it a try when working on your next project, however small it might be.