How to Build Product Sense: A Weekly Practice System

You’ve probably met someone whose product instincts seem almost magical. They glance at a screen and instantly know why it feels wrong. Here’s the secret nobody tells you: that “instinct” is not a gift they were born with. It’s a muscle they built, one small rep at a time.

The good news is that you can build the same muscle. The even better news is that you can do it with a routine simple enough to run during your morning coffee.

Why this matters

Understanding ideas about good design is not the same as having skill. You can read every book on product sense and still freeze when it’s your turn to decide where a button goes.

Skill comes from practice, not reading. And product sense has a wonderful property: it compounds. Every example you study becomes a pattern stored in your head. The more patterns you collect, the faster you recognize new ones, almost without thinking.

Marty Cagan, founder of the Silicon Valley Product Group and one of the most respected voices in product, says it plainly. Too many people treat product sense as a trait you must be born with, when really it “is something you can develop by embracing the right mindsets and putting in the effort.”

So the question isn’t do I have it? The question is what reps am I doing this week?

The one belief to fix in your head first

Psychologist Anders Ericsson gave us the term deliberate practice: structured, focused repetition with feedback. Not just “showing up for years.”

Think of two pianists. One plays full songs for an hour. The other isolates the one hard bar and plays it slowly, on purpose, listening for mistakes. The second pianist improves far faster, even with less total time at the keyboard.

Product sense works exactly the same way. The habits below are designed to turn your ordinary daily life as a user into deliberate reps.

The core habits that build the muscle

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 to learn from.

Keep a running note: a screenshots folder, a Notion page, anything. Every time a product delights or infuriates you, capture the moment and write one line on why. Over months, this becomes your personal library of patterns, drawn from real reactions instead of theory.

Do regular product teardowns

A teardown is a structured critique of an app or flow. Pick one, and force yourself to find exactly one thing it makes obvious and one thing it makes confusing. Then write the why for each, naming the real principle at work.

That “one good, one bad, plus why” structure is the whole point. It’s what turns mindless scrolling into actual training.

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 pushed someone to do it that way.

This trains you to read designs as hypotheses, not accidents. As Cagan notes, strong teams get handed “problems to solve rather than lists of features to build.” So a good design quietly encodes a problem, and your job is to reverse-engineer it.

Shadow support and sales

Sit with real support tickets. Listen to real sales and onboarding calls. You’ll hear the exact words your users use and the exact spots where they get stuck.

This grounds your sense in reality instead of your own assumptions. Ten tickets from non-technical shop owners will teach you more about a confusing “Order Status” screen than a week of guessing at your desk ever could.

Write the press release 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 tool is a PR/FAQ: a short press release plus a list of 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, not on profits, not on what’s easy to build today.
• The FAQ is five pages or fewer, and it’s where the hard questions get answered.
• It’s heavily iterated. Ten-plus drafts and several leadership reviews is normal.

Yes, it slows the start. But it saves time and money by surfacing problems before they’re baked into code. Amazon built Kindle, Prime Video, and AWS this way. (See Working Backwards by Colin Bryar and Bill Carr.)

A quick example. Before building a “bulk reorder” feature, write the one-page release first: “Maria reopens her store Monday morning, taps Reorder last batch, and 200 business cards are in her cart in five seconds.” Writing that sentence forces you to design the obvious path first, and it instantly exposes every unanswered question for the FAQ.

Form strong opinions, then hunt for proof you’re wrong

The phrase is “strong opinions, weakly held.” You have to commit to a hypothesis to design anything at all. But then you go looking for evidence that you’re wrong, not evidence that you’re right.

This fights confirmation bias, the very human habit of noticing only what agrees with us. It pairs perfectly with talking to users the right way, which we’ll get to below.

Run 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 any explanation?

This single habit catches most of your worst mistakes before they ship.

Common misconceptions

Myth: Product sense is a personality trait. Reality: it’s a skill built through deliberate practice. People with great instincts simply did more reps, more deliberately.

Myth: You can judge your own product fairly. Reality: you can’t un-know what you know. If you critique your design as yourself, the person who built it and knows where everything is, the shop-owner test gives a false pass every time. You have to genuinely pretend to be a first-time, non-technical user.

Myth: Asking users what they want gives you the answer. Reality: people lie to you politely, and even when they’re honest, they’re often wrong about their own future behavior. Watching what they do beats asking what they think.

The vocabulary that makes your teardowns real

Good teardowns name causes, not vibes. “This feels off” is useless. “The signifier contradicts the affordance” is a finding you can act on. Borrow this language from a few pillars of the field.

Don Norman’s five concepts

Don Norman co-founded the Nielsen Norman Group and gave us discoverability: can a user figure out what’s possible and how to do it? It rests on five ideas.

• Affordance - what an object lets you do (a chair affords sitting). The possible action.
• Signifier - the visible cue that signals how or where to act (a “PUSH” label, a handle’s shape). Affordance is what’s possible; the signifier is the visible signal of it.
• Constraint - a limit that prevents error.
• Mapping - the relationship between a control and its effect (stove knobs laid out like the burners).
• Feedback - an immediate, informative response to an action.

You already know a Norman door: the door with a pull handle that you actually have to push. The signifier lies to you. Bad software does this constantly, with a button that looks like a link or a “Save” that gives no feedback. Norman’s lesson is worth tattooing on your brain: when users fail, it’s usually design error, not human error.

Nielsen’s 10 usability heuristics

A heuristic is a broad rule of thumb. Jakob Nielsen refined these ten in 1994 and they’re still the field standard:

1. Visibility of system status (keep users informed)
2. Match between system and the real world (speak the user’s language)
3. User control and freedom (an undo, an emergency exit)
4. Consistency and standards
5. Error prevention
6. Recognition rather than recall (make options visible; don’t make people remember)
7. Flexibility and efficiency of use
8. Aesthetic and minimalist design
9. Help users recover from errors, in plain language, never codes
10. 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 error must say “We couldn’t save this order. Check your internet and try again,” and never “Error 500.”

Three Laws of UX to keep on your shoulder

From Jon Yablonski’s Laws of UX:

• 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.

Find the user’s real job (JTBD)

Harvard professor Clayton Christensen popularized Jobs To Be Done: customers don’t buy products, they hire them to make progress in a specific situation.

The famous example is milkshakes. A restaurant chain wanted to sell more of them. Improving the flavor based on focus groups did nothing. So researchers stopped asking and started watching, and found that nearly half of shakes sold before 8:30am, to solo drivers who bought only the shake and left.

The real job? Make a long, boring commute less dull and stay full until lunch, all drunk one-handed in the car. The shake’s true competition wasn’t other shakes. It was bananas, bagels, donuts, and boredom.

The lesson: watch, don’t just ask, and define the job, not the product category.

Talk to users without being lied to (The Mom Test)

Rob Fitzpatrick’s The Mom Test makes an uncomfortable point: people lie to you politely about your idea, even your own mom. So you ask questions that even your mom couldn’t lie about. Three rules:

1. Talk about their life, not your idea.
2. Ask about specifics in the past, not opinions about the future.
3. Talk less, listen more.

The classic mistake is asking “Would you use a feature that did X?” That practically begs for a polite lie. Instead, ask “Tell me about the last time you had this problem. What did you do, and what did it cost you?” Real signal is the time, money, and clumsy workarounds someone has already spent.

How to use this: your weekly practice plan

Here’s the whole system, turned into a schedule you can actually keep.

1. Daily (5 min): Add one swipe-file entry. A great or terrible UX moment, plus the why.
2. Twice a week (~30 min): Do one teardown. One obvious thing, one confusing thing, and the principle behind each.
3. Weekly: Read 10 to 20 support tickets, or sit in on a sales call. Capture the exact words users use.
4. Weekly: Run the shop-owner test on one of your own screens.
5. Per feature: Write the one-page PR and short FAQ before building.
6. Monthly: Take one strong opinion and go hunt for evidence it’s wrong.
7. Ongoing: Read about a chapter a week from the canon below.

The ten questions to ask before placing any UI element

Pin these where you work. Before you place any button, field, or setting, ask:

1. Where would a non-software user look for this?
2. What label would they understand with no explanation? (No uuid, slug, or payload. “Store Name,” “Order Status.”)
3. Is it recognizable, or am I forcing them to remember? (Heuristic #6)
4. Does it match how other apps work? (Jakob’s Law)
5. Is the key action the biggest and easiest to reach? (Fitts’s Law)
6. Are there too many choices here? Can I segment? (Hick’s Law)
7. What does it afford, and does a signifier show it? (Norman)
8. If it fails, does the error say what to do next? (Heuristic #9)
9. What job is the user hiring this screen to do? (JTBD)
10. Would a non-technical shop owner find it and get it? (Shop-owner test)

A small but powerful rule of thumb: a setting about a product belongs near the product, not buried in global settings. That’s where someone who has never used software would look for it. The ask is the intent, not the coordinates.

Go deeper: the canon

When you’re ready to read more, start here. Don Norman, The Design of Everyday Things. Marty Cagan, Inspired and Empowered. Julie Zhuo, The Making of a Manager. Clayton Christensen, Competing Against Luck and The Innovator’s Dilemma. Rob Fitzpatrick, The Mom Test. Jon Yablonski, Laws of UX. Bryar and Carr, Working Backwards. For lighter on-ramps, Steve Krug’s Don’t Make Me Think and Teresa Torres’s Continuous Discovery Habits.

Conclusion

If you remember one thing, remember this: product sense isn’t a gift you’re waiting to discover. It’s a routine you choose to run. The person with “magical” instincts is just someone who has been quietly collecting patterns, one small rep at a time, for longer than you have.

So start today with the easiest habit on the list, the five-minute swipe file, and let it compound.

And here’s the thread worth pulling next: every habit above assumes you can step outside your own head and see your product through a stranger’s eyes. That skill, empathy on demand, is harder than it sounds, because your own expertise is constantly working against you. Learning to deliberately un-know what you know might be the most valuable trick of all.