Frequently Asked Questions
Honest answers to the questions most beginners ask before they start.
Is product sense something you're born with, or can you learn it?
It is learned. Some people get a head start because they pay close attention to how things make people feel, but "good taste" in products is just thousands of small observations stacked up. Every principle in this guide is a shortcut to observations you'd otherwise take years to collect. With deliberate practice (Chapter 13), anyone can build it.
What's the difference between empathy and sympathy?
Sympathy is feeling sorry for someone — "that's a shame the user got confused." Empathy is stepping into their shoes — "I see exactly why they got confused, because the save button looked disabled." Sympathy keeps the problem at arm's length; empathy makes it yours to fix. We want empathy.
How is this different from UX or UI design?
UI (user interface) is the pixels — buttons, colors, layout. UX (user experience) is the whole journey through them. Product sense sits above both: it decides whether the right thing is being built at all, and empathy fuels every layer. You can have a beautiful UI for a feature nobody needs. This guide is about not making that mistake.
I'm a backend developer. Why should I care?
Because the user can't see your clean architecture — they only experience the surface. A slow query becomes a spinner with no end. A missing validation rule becomes a "Saved!" message that silently drops their data. The most damaging usability bugs often start deep in the code. Empathy is everyone's job.
How do I practice if I don't have real users yet?
Three ways. First, dogfood — use your own product as if you were the shop owner, doing real tasks. Second, keep a friction log of every product that annoys you and diagnose why. Third, do teardowns of great products (Chapter 11) and bad ones. You can build sharp judgment from other people's products long before you have your own audience.
Do I need a professional designer to make good products?
A designer makes things better and faster, and you should partner with one when you can. But you cannot outsource product sense — the engineer who understands the user's job will catch problems the prettiest mockup hides. The principles here let you raise the floor on any team, designer or not.
How do I balance "simple" with "powerful"? My power users want more.
You don't choose one — you stage them. This is progressive disclosure (Chapter 8): show the simple path by default, and reveal advanced controls on demand. Set smart defaults for the 90%, and let the 10% dig deeper. The goal is "simple by default, powerful when needed," never "complex for everyone."
Won't asking users what they want just give me bad answers?
Often, yes — people are poor at predicting their own behavior. The fix isn't to stop talking to them; it's to ask better questions. The Mom Test (Chapter 12) teaches you to ask about their real past actions, not your idea. "What did you do the last time an order went wrong?" beats "Would you use this feature?" every time.
How do I know if a design is actually good before I ship?
Run it against a checklist instead of trusting your gut. Use Nielsen's ten heuristics (Chapter 9) and the self-questions on the cheat sheet: Does every state — loading, empty, error — get handled? Would a non-technical user understand every label? Is the most common action the easiest one? Structured review catches what taste misses.
This feels slower than just building. Is it worth it?
It is faster overall. Confusing software generates support tickets, refunds, churn, and rework — all far more expensive than thinking clearly up front. Spending ten extra minutes to make a checkout obvious can save a shop owner an abandoned order and you a week of "why isn't this working?" emails. Empathy is not a tax on shipping; it is what makes shipping count.