A customer problem is a capability, outcome, or condition that people need a software system to provide. Start with what the client is trying to achieve and how people will use the software, not with a requested feature or a proposed solution. Client wishes matter, but the underlying need may be different. section 8.1 section 8.2.1
The client and the end user may see the problem differently. Listen to the client, then check their account against users’ roles, experiences, and expected use. Surveys can surface pain points; focus groups allow discussion; user testing reveals difficulties with an early version; heatmaps can prompt questions about unused screens and user paths. The right method depends partly on how many users you can reach. section 8.1.3 section 8.1
When a requested solution misses the need
A technically skilled client over-engineered software that nontechnical users struggled to understand. Focus groups with the small end-user group exposed differences between the existing use cases and how people expected to use the system. Interviewing users helped prevent mismatched requirements. section 8.1.3
Table 8.2 Examples of client wants vs. needs (view table figure)
| Wants |
Needs |
|---|---|
| “Simple” e-commerce website |
Advanced inventory management, order tracking, and customer support systems |
| Implement every cutting-edge technology into a mobile app |
Upgrade to cutting-edge technologies only as needed |
| Robust customer loyalty program with a login and dashboard |
Creating a simple login and dashboard, and rolling out new features gradually |
| Flashy web design |
Designing a user-friendly interface |
| Custom solutions tailored for a specific project |
Scalable and sustainable technologies that provide long-term support and compatibility |
Compare requested features with underlying needs: a flashy design may call for a user-friendly interface, while a “simple” e-commerce site may need inventory management, order tracking, and customer support. section 8.2.1
Treat the problem as something to confirm together, not a decision to make on the client’s behalf. In an initial conversation, ask about the client’s challenge and listen before proposing an approach. When presenting one, state the pain points or requirements first, then the potential solution, benefits, risks, costs, and dependencies. Keep development-team pain points—such as unclear direction or inadequate tools—distinct from problems the software must solve for its users. section 8.1 section 8.5.1 section 8.5.3 section 6.1.1
