Sharpening Product Sense Deliberately: A Practice System
By now you understand many ideas about product sense and user empathy. But understanding is not skill. Skill comes from practice. This final chapter turns the whole guide into a routine you can run every week, so your product sense keeps growing.
First, the most important belief to fix in your head. Product sense is not something you are born with. Marty Cagan, a respected product thinker (founder of the Silicon Valley Product Group, a consultancy that advises product teams), puts it plainly: too many people think product sense is a trait you must be born with, but in fact it "is something you can develop by embracing the right mindsets and putting in the effort."
Deliberate practice is a term from psychologist Anders Ericsson. It means structured, focused reps with feedback, not just "showing up for years." A pianist who practices the hard bar slowly, on purpose, improves faster than one who just plays songs. Product sense works the same way. Below is a set of habits that turn your daily life into reps.
The core habits
1. Keep a swipe file
A swipe file is a curated collection of examples you keep for reference (the term comes from copywriters who saved great ads). Keep a running note — a screenshots folder, Notion page, anything — of moments that delighted or infuriated you as a user. Write one line on why. Over months this becomes your personal pattern library.
2. Do regular product teardowns
A teardown is a structured critique of an app or flow. Pick one. Find exactly one thing it makes obvious and one thing it makes confusing. Write the why for each, naming the real principle at work (see the vocabulary below). The forced "one good, one bad, plus why" structure is what turns idle browsing into practice.
3. Build the "why did they build it this way?" reflex
Treat every design decision as intentional until proven otherwise. Ask what user, constraint, or job drove it. This trains you to read designs as hypotheses, not accidents. It connects to Cagan's idea that strong teams are handed "problems to solve rather than lists of features to build" — so a good design encodes a problem, and your job is to reverse-engineer it.
4. Shadow support and sales
Sit with real support tickets and listen to real sales or onboarding calls. You will hear the exact words your users use and the exact places they get stuck. This grounds your sense in reality instead of your own assumptions. For your print SaaS, ten tickets from non-technical shop owners will teach you more about a confusing "Order Status" screen than a week of guessing.
5. Write the press release and FAQ before you build
This is Amazon's "Working Backwards" method, used since around 2004. Instead of building first, you start by describing the finished customer experience, then work backward to what to build. The main tool is the PR/FAQ — a Press Release plus Frequently Asked Questions, written before any code.
- The press release is a few paragraphs, always under one page, focused entirely on the customer being excited — not on competitors, profits, or what you can build today.
- The FAQ is five pages or fewer.
- It is heavily iterated: 10+ drafts and 5+ leadership reviews is normal.
It slows the start but saves time and money by surfacing problems before they happen. Amazon built Kindle, Prime Video, and AWS this way. (See the book Working Backwards by Colin Bryar and Bill Carr, 2021.)
6. Form strong opinions, then hunt for evidence you are wrong
"Strong opinions, weakly held." You must commit to a hypothesis to design at all — but then actively look for proof you are wrong, not proof you are right. This fights confirmation bias (the human tendency to notice only what agrees with us). It pairs perfectly with talking to users the right way (next box).
7. The shop-owner test
Re-experience your own product as someone who has never used software. Would a non-technical print-shop owner understand this label and this placement without explanation? This single habit catches most of your worst mistakes.
The vocabulary that makes teardowns real
Good teardowns name causes, not vibes. Borrow this language from two pillars of the field.
Don Norman — The Design of Everyday Things (revised 2013). Norman co-founded the Nielsen Norman Group and gave us the idea of discoverability: can a user figure out what's possible and how to do it? It rests on five concepts:
- Affordance
- What an object lets you do (a chair affords sitting). It is the possible action.
- Signifier
- The perceivable cue that signals how or where to act (a "PUSH" label, a handle's shape). Norman added this term in 2013 to clarify "affordance." Affordance = what's possible; signifier = the visible signal of it.
- Constraint
- A limit that prevents error (physical, cultural, semantic, logical).
- Mapping
- The relationship between a control and its effect (stove knobs laid out like the burners).
- Feedback
- An immediate, informative response to an action.
Nielsen Norman Group (NN/g) — the 10 Usability Heuristics. A heuristic is a broad rule of thumb. Jakob Nielsen refined these ten in 1994; they are still the field standard.
- Visibility of system status (keep users informed)
- Match between system and the real world (speak the user's language)
- User control and freedom (an undo / emergency exit)
- Consistency and standards
- Error prevention
- Recognition rather than recall (make options visible; don't make people remember)
- Flexibility and efficiency of use
- Aesthetic and minimalist design
- Help users recover from errors — in plain language, never codes
- Help and documentation
Heuristic #6, recognition over recall, is the science behind the shop-owner test: recognizing something on screen costs far less mental effort than remembering it. Heuristic #9 is exactly why an "Order Status" error must say "We couldn't save this order — check your internet and try again," not "Error 500."
Jon Yablonski — Laws of UX. Three laws to keep on your shoulder:
- Jakob's Law: users spend most of their time on other sites, so they expect yours to work the same way. Put the cart top-right, make the logo link home. Don't reinvent conventions to "be clever."
- Fitts's Law: the time to reach a target depends on its size and distance. Make the most important action big and easy to reach.
- Hick's Law: decision time grows with the number and complexity of choices. Reduce and segment options to avoid paralysis.
Get the user's real job — JTBD
Clayton Christensen (Harvard professor, author of The Innovator's Dilemma) popularized Jobs To Be Done: customers don't buy products, they hire them to make progress in a specific situation.
Talk to users without being lied to — The Mom Test
Rob Fitzpatrick's The Mom Test (2013) says people lie to you politely about your idea — even your mom. So ask questions even your mom couldn't lie about. Three rules:
- Talk about their life, not your idea.
- Ask about specifics in the past, not opinions about the future.
- Talk less, listen more.
A weekly practice plan
| Cadence | Practice | Ties to |
|---|---|---|
| Daily (5 min) | Add 1 swipe-file entry: a great or terrible UX moment + the why | Swipe file |
| 2× / week (~30 min) | One teardown: 1 obvious thing + 1 confusing thing, name the principle | Teardowns + vocabulary |
| Weekly | Read 10–20 support tickets or sit on 1–2 sales calls; capture exact words | Shadow support/sales |
| Weekly | Run the shop-owner test on one of your own screens | Shop-owner test |
| Per feature | Write the 1-page PR + short FAQ before building | Working Backwards |
| Monthly | Take one strong opinion, go find disconfirming evidence | Strong opinions, weakly held |
| Ongoing | Read ~1 chapter from the canon; follow 2–3 people below | Study |
Ask these before placing any UI element
BEFORE you place a button / field / setting, ask:
1. Where would a NON-software user look for this?
2. What LABEL would they get with no explanation?
(no uuid / slug / payload — "Store Name", "Order Status")
3. Recognizable, or am I forcing them to remember? (NN/g #6)
4. Does it match how OTHER apps work? (Jakob)
5. Is the key action the BIGGEST + EASIEST to reach? (Fitts)
6. Too many choices here? Can I segment? (Hick)
7. What does it AFFORD — does a SIGNIFIER show it? (Norman)
8. If it fails, does the error say what to DO next? (NN/g #9)
9. What JOB is the user hiring this screen to do? (JTBD)
10. Would a non-technical shop owner find + get this? (shop test)
Go deeper — the canon
Books: Don Norman, The Design of Everyday Things (2013); Marty Cagan, Inspired (2017) and Empowered (2020); Julie Zhuo, The Making of a Manager (2019); Clayton Christensen, Competing Against Luck (2016) and The Innovator's Dilemma (1997); Rob Fitzpatrick, The Mom Test (2013); Jon Yablonski, Laws of UX (2nd ed., 2024); Bryar & Carr, Working Backwards (2021). Adjacent: Steve Krug, Don't Make Me Think; Teresa Torres, Continuous Discovery Habits.
People & resources to follow: Nielsen Norman Group (nngroup.com); Jakob Nielsen & Don Norman; Marty Cagan / SVPG (svpg.com); Julie Zhuo (Facebook's first design intern, later VP of Product Design — writes deeply on building product intuition through reps); Jon Yablonski (lawsofux.com); Rob Fitzpatrick (momtestbook.com).
Key takeaways
- Product sense is trainable and compounds — build a routine, not a hope of natural talent.
- Make it a system: daily swipe file, twice-weekly teardowns, weekly support-shadowing and a shop-owner test, a PR/FAQ per feature, and a monthly hunt for disconfirming evidence.
- Name causes, not vibes — use Norman's five concepts and NN/g's ten heuristics so your critiques have real vocabulary.
- Watch users, don't just ask them (JTBD milkshake); and talk to them so they can't politely lie (The Mom Test).
- Run the ten placement questions before you ship any element — especially "where would a non-technical shop owner look, and what label would they understand?"