I've built products that were technically impressive but nobody wanted. I've also built simple products that customers loved. The difference wasn't the technology—it was understanding what customers actually needed. This is the most important lesson I've learned as an engineer and founder.
The Engineer's Bias
As engineers, we're attracted to complex problems, elegant solutions, new technologies, optimization challenges, and clever code. But customers care about solving their problem, ease of use, reliability, value for money, and getting their job done. These don't always align. In fact, they rarely do.
I once spent 3 months building a feature that I thought was brilliant. It was technically elegant. It solved a problem I thought customers had. Nobody used it. We eventually removed it. That's 3 months of engineering time wasted. That's opportunity cost. That's demoralizing for the team.
The solution is to understand customer needs before you build.
Design Thinking Framework
1. Empathize: Understand the Customer
Don't assume you know what customers need. Talk to them. Watch them use your product. Ask questions.
- Conduct user interviews (not surveys)
- Watch how they use your product
- Ask "why" five times
- Look for pain points and frustrations
- Listen more than you talk
2. Define: Frame the Problem
Don't jump to solutions. Define the problem clearly. This is where most engineers fail. We jump straight to solutions without understanding the problem.
Good problem statement: "Small e-commerce businesses need to process orders quickly without hiring additional staff." Bad problem statement: "Make the feature faster."
The good problem statement guides your solution. The bad one doesn't.
3. Ideate: Generate Solutions
- Automate order processing
- Batch processing
- AI-powered categorization
- Integration with suppliers
- Mobile app for on-the-go processing
- Hire a virtual assistant service
- Use a third-party fulfillment service
The goal is to generate lots of ideas, not to pick the best one yet.
4. Prototype: Build Quickly
Don't build the perfect solution. Build something to test your assumptions. This is where engineers often fail. We want to build the perfect solution. But perfect is the enemy of good.
This prototype takes an hour to build. It's not elegant. It's not optimized. But it tests the core assumption: will customers use batch processing?
5. Test: Get Feedback
Show your prototype to customers. What works? What doesn't?
Good feedback questions: "How would you use this?", "What's missing?", "Would you pay for this?", "What would make this better?", "How much time would this save you?"
Bad feedback questions: "Do you like it?", "Is it fast enough?", "Would you use this?"
Applying Design Thinking to Engineering
Feature Requests
When someone asks for a feature, don't just build it. Understand the underlying need.
Customer: "Can you add dark mode?" Engineer (bad): "Sure, I'll add a toggle." Engineer (good): "Why do you want dark mode? When do you use the app? Are you having eye strain? Would a different solution work better?"
Maybe they need better contrast, not dark mode. Maybe they use it at night and need a night mode. Maybe they just think it looks cool. You won't know until you ask.
Technical Decisions
Apply design thinking to technical decisions too.
Problem: "Our API is slow" Empathize: Talk to customers. Is it actually slow? Which endpoints? When? How much does it impact them? Define: "Customers report 2-second latency on the dashboard, which blocks their workflow. They can't process orders efficiently." Ideate: Caching, database optimization, API redesign, frontend optimization, pagination Prototype: Try caching first (simplest solution) Test: Measure improvement. Did it solve the problem? Did latency drop to acceptable levels?
Common Mistakes
1. Building Without Understanding: I built a feature I thought was cool. Nobody used it. 2. Optimizing the Wrong Thing: I spent weeks optimizing a feature nobody used. 3. Ignoring Feedback: I thought I knew better than customers. 4. Perfectionism: I delayed shipping because the solution wasn't perfect. 5. Not Measuring Impact: I built features and assumed they were valuable.
Practical Exercise
Try This This Week: 1. Pick one feature or problem 2. Talk to 3 customers about it 3. Ask "why" five times 4. Write down what you learned 5. Reconsider your approach
I bet you'll discover something you didn't expect.
Building a Customer-Centric Culture
- Product managers talk to customers
- Engineers talk to customers
- Designers talk to customers
- Everyone understands customer needs
This creates a culture where decisions are based on customer needs, not on what's technically interesting.
Conclusion
The best engineers aren't just good at writing code—they're good at solving real problems. Design thinking helps you bridge the gap between what you can build and what customers actually need. Start with empathy, define the real problem, and iterate based on feedback. That's how you build products that matter. Remember: the best code is the code that solves a real customer problem. Everything else is just clever engineering.