Be your client’s client

tl;dr
When you build something for somebody, do you know everything he or she needs?

The main difference between building custom solutions for yourself or for clients is that you already know why you need it and usually don’t have a clue why that customer needs it. It is dangerously easy to underestimate the power of thorough analysis of the problem.
When you “scratch your own itch” you know exactly which functionalities are fundamental and how the flow has to go to perfectly fit your needs. You also know your tech savviness (never underestimate “tech non-literacy” of your product’s users). And because you already know all this, it is no problem to build solid specifications.

But when you are trying to make your customer’s life better you usually don’t know anything about his or her problems. You don’t know who the end users are, how they think, how good are they with using keyboard and or mouse, how are they used to work with existing solutions…

The best way to build a great product for a client is to really get to know the problem from all perspectives. The client will always forget some important details that he or she takes for granted or thinks that are too obvious to even tell you about them. But because you don’t know them, it could cost you a lot of time and money to modify the product in the middle of client testing.

So what to do? Be the client of your client. Ask him to show you their current solution, let them show you how they are doing things right now, also with “real” users not only with their tech guy. Ask the users how they see that product, what is great and what would they (not just the management) change. Fiddle with that solution yourself, find the faults that drove the users mad, find ways that could help fasten or cheapen the flow.

It will cost you some more time, but that’s the price if you want to be the best in your field.

*Photo from Knight Foundation