The Question
I'd been asked to design a reporting module for a CRM system. I'd built a comprehensive solution: configurable charts, exportable CSVs, date range filters, user-level access controls. The client looked at it for two minutes and asked: 'Who actually reads these reports?'
I didn't have an answer. I'd assumed that reports were read by the people who requested the reporting module. The client then explained that the reports were generated for external clients — and that those clients received them via email, never logging into the system. The entire in-app reporting interface I'd designed served nobody.
The Gap Between Good Code and Good Engineering
Good code solves the problem correctly. Good engineering starts by questioning whether you've identified the right problem. These are different skills. I'd been optimising for code quality and feature completeness on a solution that didn't serve the actual use case.
The question the client asked — 'who actually uses this?' — is one I now ask at the start of every feature, not at the demo. It takes five minutes and occasionally saves weeks.
Key takeaways
- Ask 'who actually uses this and how?' before designing any feature — the answer determines what you build, and the assumption is often wrong
- A technically excellent solution to the wrong problem is worse than a mediocre solution to the right one — it creates confidence where doubt is appropriate
- The questions that matter most in early feature definition are product questions, not technical ones — 'what problem are we solving?' before 'how do we build it?'
Conclusion
The meeting changed how I open every project conversation. The first questions are always: who uses this, what do they do with it, and what would make their life better? The technical design comes after those are answered, not before.
Enjoyed this article?
Vivek Kumar Singh
Technical Expert · Full Stack Cloud Engineer · Tokyo, Japan
