Six ways to be a better client for your developer – Point 1
Dear Reader,
Are you a good client for your freelance programmer? I hear both sides of this conversation from different friends. Freelancers complain that clients and potential clients just don’t have a clue. They feel the need to figure out what the client needs instead of listening to what the client wants. Clients complain that no matter how much they explain what they want, the developer is rarely listening and is usually just waiting to speak.
For the purposes of this article series, I will use the word developer when I mean freelance developer, internal development team or external development company. Most of these points apply to all three.
Understand that you alone know the problem
You and you alone are the vision keeper for your project. You have to convey the problem that needs to be solved without specifying how it is to be solved. Work with your developer to make sure they understand you as you describe the problem. When in doubt, stop talking and ask them to describe the problem as they understand it so far. If they are just waiting to talk, they will describe the solution they have in mind, not the problem you have described.
When describing your problem that you want solved, make sure you use clear and plain language. Don’t assume that the developer will understand industry jargon or acronyms. Just because it’s clear to you doesn’t mean that it is clear to them. Most developers will ask a lot of questions as you talk. Don’t get off track but make sure that all questions they have are answered to their satisfaction. As the problem space expert, it is your job to make sure they understand the proper problem to solve.
That’s all for this one. Look for the rest of this series to be posted soon.
Until next time,
I <3 |<
=C=
Tags: freelance, web development
Sadly, not all clients really understand the problem. Many, if not most, have an idea of what they think the solution should be because they shop for software from the perspective of how cool it would be if they had something like what X has. X may be Google, CNN, a competitor, a restaurant website, or something they saw on Junior’s computer.
So a lot of the time they think the problem is “I don’t have a website that does X” instead of “I need a better way to get messages about my business’s hours changes to my customers.” Even if they describe the problem, developers will still have to listen past it to understand what the underlying business need is.
Hi Sandy!
The lovely and talented Kathy and I were discussing this very point at Starbucks this morning sparked by your comment. You are correct, a lot of times, clients don’t understand the problem they are trying to solve or just haven’t thought it through. It is the job of the developer to draw this out of them in the discovery meeting. Stepping back from specific features, the developer should ask questions like “What is the purpose of the application?” Don’t ask them what the problem is, ask them what the eventual solution is. When the application is complete, what new thing will they have? New sales? new leads? New readers/listeners? They do know WHY they want something built, even if they can’t articulate the problem. Once you understand the WHY, as a developer, you can help them figure out the WHAT.
Thanks for taking the time to comment,
=C=