Why Don't Software Customers Just Say What They Want?
Why Don't Software Customers Just Say What They Want?
And more importantly, how do developers overcome this?
Join the DZone community and get the full member experience.Join For Free
You are in a session, grooming, specifying, pasting stickies on the to-do board. The customer is there, too, for giving specs. But you are getting nowhere. Opinions change by the minute. It never gets concrete. Agitated vibes are felt.
If you let it be, you won't have enough information to do the job. But the deliverable is on your plate for this sprint. How can you fix this?
The problem with customers
Steve Jobs summed this up rather succintly:
"Customers don't know what they want."
A customer's mind contains a vague idea, maybe half a goal. Bits and pieces, far from complete or consistent. Things they do not want. Some pictures of UIs he/she liked. That's it.
This isn't strange. They are not specialists; they are customers. However, we developers stoically act as if the customer does know exactly what he/she wants:
- We ask for technical details a customer cannot know the answer to
- If the customer did write something, we over-interpret his/her wording and interpunction, and treat it as a super-exact specification, though we know it's not
Why do we do this while it's obvious we will get poor results?
You may also like: 5 Tips on How to Keep Clients Happy
We're asking the wrong questions
Suppose the customer wants to rate website content with one to five stars.
What customers don't understand is that this rating data needs to be modeled, stored, sessioned, user-ID'd, timestamped, categorized, tooled for pruning fake votes, 1-decimal accurate averages, half stars, a UI to list filtered ratings, prevent comparing noncomparable categories, list widgets, dynamic ratings based on roving time window average, and cached average refresh rules. To name a few.
The customer thought he/she asked something simple, and it triggered an avalanche that turned a five-star widget into an enormous ratings data control center.
Now developers ask for details, like: "Do you want the confirmation link emailed? How long must the roving time window be? How much decimal accuracy in the averages?" Developers think these are "smart" questions, because everything can be deducted from the customer's answers, as if the customer has a brain full of exact blueprints of each moving part.
Of course, the poor customer has no clue what to say. Makes wild guesses, does not know, bounces questions back to you. Or becomes frustrated and frictional, and keeps beating about the bush. But a developer needs details to make working software.
Whatever question you skip now will appear later as bugs, wishes, disappointments, refactoring, retrofitting, or plain technical debt.
Better understanding, better specs
You should first understand and accept the fundamental mindset differences between developers and customers. Then, change your approach on that knowledge.
Customers learn by progressing insight only
Customers only know what they wanted when they see the end result. Be at peace that this is how it works. Use it to your advantage. Deliberately trigger progressing insight by showing the expected end result as early as possible.
Customers are not logical thinkers
Developers are good at solving logical puzzles. That is what we live, breathe, and do all day to make software work. We expect customers to be like us: highly deductive, rational, logical, and immediately understanding all implications.
Customers are not good at this. When talking with you, they feel smart-assed, not helped, and looked down upon. Developers often think customers are either plain stupid or deliberately act as if they are stupid to dodge clear answers.
Customers fear blame
Specifying is deciding on unknowns. Whoever decides gets the blame when the decision turns out to be wrong. Customers and developers try to put each other up with specifying (= make decisions) to avoid blame. That is not a productive collaboration; that is a power struggle.
Customers are unaware of incompleteness and inconsistency
Consider the figure below. Left: what the developer thinks the customer has in mind. Right: what the customer really has in mind.
The customer thinks he/she has a pretty clear idea, but is not aware that walls are missing, the roof is way too small, the windows have no place, and this TV is not relevant yet.
Lo and behold the confusion. The customer cannot provide the information we want because it's not there. We must help the customer to generate it.
So, how do we get better specs from the customer?
Here's the plan:
- complete the picture
- make assumptions, discuss, and agree on them
- make a package deal
Your first mission is to complete the picture of the outside and agree on it. The house has two floors and a foundation. The door needs a latch. The chimney tells there is a fireplace. There must be room for the TV.
This does not tell you data model properties, algorithms, and configuration UI options yet, but it gives you common ground.
Trigger progressing insight with pictures
Show pictures of the expected result before building anything so that imagination starts running. Explain to the customer that the goal is progressing insight about what to make, not to discuss graphical design aesthetics.
It could just be html-edited screen grabs of existing software. It can be drawings. Clickable mockups are great. Make pictures of dialogs, editors, and control screens that you need to get this to work; they tell you a lot about how you expect to implement it technically and tell the customer what they should expect. Discuss them and go through the details, especially the ones you know have a deep technical impact.
You should discuss questions like:
Is this what you want to achieve?
Do you want to configure this by yourself?
Will your users understand this?
If this is not what you had in mind, what is on your mind now?
Get a designer
If you want to be really effective, you need someone that can make good-looking UI pictures or clickable mockups fast.
Since technically apt designers are scarce, a pragmatic way is to have techies make ugly but technically correct drawings, and then tell the designer "make something beautiful from these elements."
Bonus: if the designer misinterpreted your input, the customer certainly would have, too. Always approve technically before showing to the customer.
It comes with guidance
You need to guide the customer, and keep everyone's eye on the ball: progressing insight to discover what they want. Consensus on what it will look like design-wise is bycatch, not the goal.
Keep it non-technical
Avoid technical drawings like data models, flow charts, and code. It causes a treacherous dynamic: You end up explaining to the customer how everything is going to work. The customer feels comfortable and safe not having to deliver input; just lets you talk and watches the show. You get no new information.
Assumptions are the mother of all good specs, if explicit.
Technicians make loads of assumptions. This time, do something new: Write them down and discuss them with the customer. Assumptions mean filling in the blanks for the customer, who has no idea. So, make educated guesses.
Example: Imagine an app with lots of tables and lists. Developers propose simple templating. The customer then needs to specify a lot about possible elements, variations, and details. Instead, talk about the underlying assumption:
"We will spend much project capacity on making ±40 lists and tables with many similarities. With templates, we save time building and maintaining them, going to market faster, but at the expense of fine-grained control on how each detail looks."
Now that is something the customer does understand: faster results, less control.
Could the customer live with being not too fussy on looks, but go to market faster? Will they still demand fine grained control later, causing templating to become a source of messy, scattered code?
This is something you can discuss with a customer very well, and often leads to usable answers. "What types of variants do you want in the row templates?" would not give you the same result.
Customer must agree on the assumptions
A big risk of assumptions is that the customer likes the ease, leans back, lets you do all the thinking, and gives no input or feedback. In other words, they go into blame-prevention mode; when something goes wrong, they can tell their boss that it was your idea.
You cannot deliver a spec if the customer won't say "yes" to the assumptions it's based on.
It must be a shared responsibility. There are things no one can know. So we guess things. If we were wrong, we all agreed to it, and we are all to blame.
Agreed assumptions have more benefits
From relatively few assumptions, you can deduct a lot of specs without having to grill the poor customer. It prevents many more frustrating discussions later.
Assumptions help you to put yourself in the customer's shoes. Making good assumptions is not as easy as it looks. It can be confronting. You used to ask the customer. Now it is up to you to make up those wild guesses.
It is easier to recognize a bad assumption than a bad spec. You may save everyone from going in the wrong direction early on.
By writing down assumptions, you can steer clear of bad decisions the customer is likely to make. In a sense, you can play "mama knows best" without sounding condescending.
Make package deals
Progressing insight must be contained, or else it becomes a runaway train. The agreed assumptions and the specs you wrote from that must remain coherent to be able to deliver.
Therefore, make the deliverable a package deal that the customer cannot cut up in smaller parts. With one part missing, the package is useless.
Here you meet a weakness of Agile: Exposing customers to the decomposition of a deliverable. The customer sees these as stickies on the board, and thinks he/she has a say in it. That must not happen. No cherry-picking. It's a package deal.
Make sure the customer agrees with your assumptions first, or else a package deal makes the customer feel wedged and forced.
When the customer says "no" to the package
Suppose the customer finds the package over-featured or too expensive.
A denied package deal is a negotiation asset. There always is a stupid-simple, extremely limited alternative. The art is to have the customer understand and accept the limitations of the cheap alternative. Or decide too simple is useless. If the customer wants the package after all, cost and scope are known.
Share the entire package
The package deal now contains:
- Pictures, clickable mockups
- Assumptions/starting points
- A clear grouping in package deals
- Specs and user stories if needed
- Technical drawings and to-dos for developers
You should put all materials in the package deal and let the customer agree to it all, even though the customer will probably only read and understand the pictures and assumptions. It provides transparency and a fallback in case disagreement emerges later.
If you understand the customer's mindset and adapt your approach to it, you get a clearer spec with less effort, waste less group time, have less findings downstream, and a more productive collaboration.
Opinions expressed by DZone contributors are their own.