This is one killer mistake! Some people take the “if you build it they will come” approach to software projects. Sorry, that only works in the movies. Those projects are a total flop because they don’t deliver what users want or need.
To avoid this mistake, you need to spend some time up front getting to know the people that will use your software. This is the only way to be sure that you will know exactly what your program should do.
If this seems obvious, read on; most people don’t take it anywhere near far enough.
Knowing your users gives you key ideas so your program can exceed their expectations.
You need to know:
- What users expect the software to do for them
- What they expect to input
- What kind of output they expect
- What they will do with the output
- How the user will interact with the program
- How the program fits into the real world
You need to understand the problem you are solving better than
most users do. You get to that point by talking with lots of users.
OK, let’s take a look at how things go when you talk with 10 users. Here’s how it usually breaks down:
- About three of the ten users are a complete waste of time. They don’t really think about the world around them, or don’t care to share their thoughts with you. Once you are sure someone falls into this group, end the conversation politely, but quickly.
- About four of the ten will give you good information, stuff you need to know. Some have a slightly different take on certain issues. Most tell you the same thing as others. This group will give you a solid background on the basic features your program needs to include.
- The remaining three will give you some breakthrough ideas, or trigger awesome ideas based on what you learned from the other seven. This is like striking gold!
Just imagine what the other seven users (that’s 70% of your user base) will think when you create a program with breakthrough features that blows away their expectations.
Now there’s a path to success!
One word of caution, when you talk with users, sometimes you run head-on into a rant. Some people can really unload on you.
Don’t take it personally, TAKE NOTES!
When people get that exercised by a discussion, you’ve found an opportunity to solve a problem that is important to them.
A guy I know, we’ll call him Pete, refuses to talk with users saying “What does Joe know anyway? He just works in shipping.”
- Joe knows the time consuming tasks that the computer should be doing for him.
- Joe knows the jobs that are left undone (or get done poorly) because they are a pain.
- Joe knows the most efficient sequence of steps to get something shipped.
- Joe knows a lot of things that don’t hit the radar of anyone not directly involved in shipping.
Now, Joe may not be able to come out and explain all the above points clearly, but I bet you can get the scoop from him over a cup of coffee. It’s easy enough to organize what you learn into a useful form.
Even if you don’t learn anything from Joe, you’ll at least get his buy in on the project. This is important because you will need cooperation to get your program into operation.
Remember, many people are afraid of computers and resist change, you may have to help them through the transition.
Another excuse I’ve heard for not talking with users is “I don’t have time for that.”
All I’ve got to say on that is if you don’t have time to talk with users, where are you going to find the time for a do-over? Save yourself some time, money, and grief and talk with your users the first time around.
Bottom line: make your users “king of the feature list.” If they don’t want a feature, and it’s not a hard business requirement, don’t waste your time on it, no matter how good an idea anyone else thinks it is.
That’s all for this time, go talk with your users!
Next time we’ll cover Mistake Number 2; the one that gets many newbies into big trouble.