“They need a way to export data.” That’s what the salesperson told the product manager. “It’s a big sale. We’ll lose it if we don’t put a data export feature in.”
On the surface, it sounds like a reasonable request. But there’s a complication.
The team can’t do a great job with the information they have. They could implement a data export feature in several different ways — each very different. If the designers just guess what the customer wants, it’s very likely they’ll build the wrong functionality. That would be a costly mistake.
The salesman came to the meeting with a customer’s solution. To be successful, the team needs to understand the problem behind that solution.
Human nature kicks in.
It’s human nature to start with a solution. When any of us walk into a store, we bring with us a shopping list of solutions. Not the problems we want to solve.
Starting with a solution is a concise way to communicate what we think we need. It’s expedient, but it leaves out important information.
Why did that customer tell the salesman they needed to export data? There are at least three possible reasons:
- Maybe they needed a secure backup.
- Maybe they wanted to move the data to another instantiation of the application.
- Maybe they wanted to bring the data into another vendor’s application, to manipulate it somehow.
(There could be more possible reasons, but let’s stick with these three for now.) Each of these reasons is radically different. A well-designed solution would be very different depending on which of these is what the customer actually needs.
The problem changes how we implement the solution.
The first alternative problem assumes the customer needs a backup solution. If the team were to build a backup capability, exporting the data is only half the problem. They’d also need a way to restore the data. That’s a…