필사 모드: The Complete Product Sense Guide for Engineers: Customer Empathy, JTBD, North Star Metric, AB Testing, PMF, Prioritization, and Roadmaps (2025~2026)

"Fall in love with the problem, not the solution." — Uri Levine (founder of Waze)

The stretch where engineers get stuck hardest on the road to Staff+: product sense. Once technical skill has carried you to L4~L5, moving up to L6 Staff demands judgment about "what to build and why."

Through 2024~2025, AI code generation made "how to implement" relatively less valuable and pushed the value of "what and why" judgment up. This post builds a product sense system you can use every day.

1. What Product Sense Actually Is

1.1 Definition

Product sense = the ability to understand user needs, behavior, and context, and to make product decisions aligned with business goals.

Three axes:

1. Customer Empathy: who uses it, why, and in what situation.
2. Problem Framing: what the real problem is.
3. Solution Judgment: which of several solutions you pick, and why.

1.2 Technical Sense vs. Product Sense

Staff+ = the integration of both senses. An engineer with only one of them stays at Senior.

1.3 What an Engineer Gains from Product Sense

• Asking the real questions in spec reviews.
• Being able to talk to a PM as an equal.
• Using trade-off language in tech debt debates.
• Having an opinion on priorities in roadmap meetings.
• Being able to found a company, or start one inside one.

2. Customer Empathy — The Three Levels

2.1 Level 1 — Data-based Empathy

• Google Analytics, Mixpanel, Amplitude analysis.
• Cohort retention, funnel drop-off.
• Who stays, and for how long.

The limit: numbers show you "what" but cannot explain "why."

2.2 Level 2 — Observational Empathy

• User Session Recording: record real usage with Hotjar or FullStory.
• Support Ticket Analysis: the pain that keeps repeating.
• NPS and Surveys: ask directly.
• Sales Call Recordings: listen on Gong or Chorus.

The limit: what a user "said" and what they "really wanted" can be two different things.

2.3 Level 3 — Immersive Empathy

• Customer visits: observe real usage in their office or their home.
• Dogfooding: use the product yourself, every single day.
• Customer shadowing: sit beside them for a day and watch the work.
• Playing the customer role: if the persona is a PM or a developer, do the job yourself.

Example: the three Airbnb founders spent a month using nothing but their own product and discovered why listings you would actually want to book again were so rare → they brought in free professional photography → revenue doubled.

2.4 Five Things an Engineer Can Start Right Now

1. A 30-minute call with five customers every month. "When did you use this product last week?"
2. Subscribe to the support channel. Slack or Zendesk alerts.
3. Use your own product daily. Eat your own dog food.
4. Monitor review sites. G2, Capterra, Product Hunt, App Store reviews.
5. Listen to one sales call a week.

3. Jobs-to-be-Done (JTBD) — The Revolution in Problem Framing

3.1 Christensen and the "Milkshake Story"

An investigation into why McDonald's milkshake sales were rising:

• Demographic segmentation got nowhere.
• Customer observation: men in their 30s and 40s were buying them at 7 a.m. on the commute.
• JTBD: "I need something easy that takes the edge off a boring commute and holds hunger off until 10."
• The competition: bananas, bagels, coffee (not other milkshakes).
• The solution: a thicker morning-only milkshake, plus a way to serve it fast.

3.2 The JTBD Framework

"People do not buy products; they hire them to make some progress in their own lives." — Christensen

Job Story format:

When [situation], 
I want to [motivation], 
So I can [expected outcome].

Examples:

• Bad: "Customers want a mobile app."
• Good: "When I am waiting in an airport lounge on a business trip, I want to check my schedule fast, so I can walk into the meeting feeling prepared."

3.3 Functional/Emotional/Social Jobs

• Functional: the practical task (tracking to-dos).
• Emotional: the feeling (less anxiety, a sense of accomplishment).
• Social: the social dimension (looking professional).

Example — buying a Tesla:

• Functional: getting from A to B.
• Emotional: relieving environmental guilt, a taste of the future.
• Social: an eco-friendly image, early-adopter status.

Look only at the functional and product design fails.

3.4 JTBD in Practice for Engineers

About the feature you are building right now:

1. What situation is the user in when they reach for this feature?
2. What progress are they trying to make with it?
3. What is the functional, emotional, and social side of it, each in turn?
4. What other solutions deliver the same progress? (the competition)
5. Does this feature actually create that progress?

Those five questions alone can improve 50% of a spec.

4. North Star Metric — Everyone Facing the Same Way

4.1 What a North Star Metric Is

"The one metric that best captures the core value your product delivers to customers." — Sean Ellis

The single metric whose rise means the product and the company are succeeding.

4.2 Famous NSM Examples

What they have in common:

• A behavior in which the customer actually experiences value.
• Correlated with company revenue.
• Measurable.
• Improvable.

4.3 NSM Anti-patterns

• Revenue itself: a lagging indicator, and the team cannot move it directly.
• Page views and clicks: easy to grow in volume, unrelated to value (the failure of the Yahoo era).
• Several at once: four or more and it is no longer a north star.

4.4 Applying It as an Engineer

Designing an NSM at the feature level:

• What is the NSM of the feature your team is building?
• How does this feature contribute to your own team NSM?
• Why build a feature that cannot lift the NSM?

Throwing one question into a spec review — "how does this feature contribute to the NSM?" — changes the level of the whole team decision-making.

5. Product-Market Fit (PMF) — Whether You Have It, and How Far Along

5.1 What PMF Is

"Product-Market Fit means being in a good market with a product that can satisfy that market." — Marc Andreessen

PMF is not on/off; it is a spectrum.

5.2 Rahul Vohra and the PMF Survey

"How would you feel if you could no longer use this product?"

• Very Disappointed: 40% or more means PMF.
• Under 40%: not PMF yet.

Superhuman designed its whole path to PMF with this method.

5.3 The Four Stages of PMF

1. Idea Fit: does the idea address a real problem.
2. Problem Fit: do users actually feel that problem.
3. Solution Fit: does our solution solve that problem.
4. Market Fit: is the market willing to pay.

The trap engineers fall into constantly: pouring most of the time into stage 3 and sprinting off without ever validating 1 and 2.

5.4 After PMF — Scale Fit

PMF is not success either. Go-to-Market Fit, Channel Fit, and Pricing Fit each have to be secured on their own.

Plenty of tech startups have PMF and still fail because there is no GTM.

6. AB Testing — The Craft of Experimentation

6.1 Why AB Tests Fail (More Than 60% of Them)

1. Sample size too small: no statistical significance.
2. Measuring over too short a window: a one-week test cannot see long-term impact.
3. Novelty Effect: mistaking an opening bump for a lasting effect.
4. Wrong metric: watching nothing but a proxy.
5. Ignoring segmentation: the average looks fine while one group is wrecked.
6. External variables: season, events, marketing changes.
7. Implementation bugs: A and B are not actually split the way you intended.
8. Selection Bias: group assignment is not random.

6.2 A Proper AB Test Protocol

1. Hypothesis: "If X, then Y, because Z."
2. Sample size calculation: up front, with power analysis.
3. Duration: two weeks to a month minimum, allowing for the weekly cycle.
4. Primary Metric + Guardrail: the main metric, plus the metric that must not get worse.
5. Segmentation plan: decided in advance.
6. MDE (Minimum Detectable Effect): the smallest effect you intend to detect.
7. Analysis plan in advance: so nobody p-hacks after the fact.

6.3 Airbnb and Booking.com

• Booking.com: runs 1,000 experiments at the same time. Of the roughly 1,000 a year, 90% come back null or negative. Only 10% improve anything.
• The lesson: most experiments fail. An experimentation culture is about finding the failures fast.

6.4 The Experimental Mindset of an Engineer

• Before every feature: "can this be validated by an experiment?"
• Reframe failed experiments as learning.
• Understand confidence intervals (know the statistical basics).
• Launch is not the end of the experiment; it is the start of continuous monitoring.

7. Prioritization Frameworks

7.1 The RICE Framework

• Reach: how many users it touches.
• Impact: how large the effect (1, 2, or 3 points).
• Confidence: how sure you are (0.5, 0.8, 1.0).
• Effort: how much work it takes (person-months).

RICE Score = (R × I × C) / E.

7.2 The Kano Model

Classifying features from the user point of view:

1. Must-be: its absence draws complaints, its presence is taken for granted.
2. Performance: the more of it, the more satisfied.
3. Attractive: nobody demands it, but its presence surprises.
4. Indifferent: nobody cares either way.
5. Reverse: its presence actively annoys.

Strategy: lock down the must-be items, then differentiate by investing in the attractive ones.

7.3 ICE — The Light Version

• Impact, Confidence, Ease, each out of 10.
• Whatever has the highest sum goes first.

Faster than RICE, and easier to use live in a meeting.

7.4 How an Engineer Contributes in Prioritization Meetings

• The cost only engineers can see: accumulating tech debt and the cost of maintaining it.
• The value only engineers can see: future optionality and platform effects.
• Put a number on it: "if we skip this now, six months from now we need X refactoring, Y weeks of it."

8. Roadmap Design — Three Months, Six Months, Two Years

8.1 The Now / Next / Later Frame

• Now (next 1~3 months): committed, concrete.
• Next (3~6 months): prioritized, still movable.
• Later (6+ months): directional, flexible.

8.2 Outcome-based Roadmap

Instead of a feature list, work in outcomes plus experiments:

Q1 Outcome: Free→Paid conversion 10%→15%.
Experiments:
- Improve the onboarding checklist
- Friend-invite incentive on the paid trial
- Usage-based pricing experiment

The upside: even when a specific feature flops, the focus stays on hitting the outcome.

8.3 Lean Roadmap (Opportunity Solution Tree)

Teresa Torres and Continuous Discovery:

• Outcome: the goal.
• Opportunities: three to five problems or openings.
• Solutions: two or three ideas per opportunity.
• Experiments: validation for each solution.

It dissolves the rigidity of the top-down roadmap.

8.4 A Two-Year Vision + a 90-Day Tactical Plan

• Two-year vision: does not change, sets the team direction.
• 90-day tactical plan: reviewed and adjusted every three months.
• Monthly: progress check.
• Weekly: blockers and shifts.

9. Designing the Engineer + PM Relationship

9.1 Worst vs. Best

9.2 What an Engineer Should Invest in the Relationship with a PM

1. Understand the why behind the PM: internalize the OKRs and the NSM.
2. Share customer empathy: watch the sessions and the tickets together.
3. Explain the technical constraints: trade-offs in language the PM can follow.
4. Proactive Proposal: be the first to say "how about this?"
5. Respect Product Thinking: drop the prejudice that "a PM is just someone who writes specs."

9.3 Engineers on Teams Without a PM

In startups and small teams the engineer doubles as the PM:

• Leading customer calls in person.
• Drafting the OKRs and the roadmap.
• Holding the authority to set priorities.
• Measuring the results.

That experience is a powerful asset on the way to Staff+, or to founding something.

10. Top 15 Learning Resources for Product Sense

10.1 Books

1. "Inspired" — Marty Cagan (principles of product teams).
2. "The Lean Startup" — Eric Ries (experimentation culture).
3. "Escaping the Build Trap" — Melissa Perri (outcomes).
4. "Competing Against Luck" — Clayton Christensen (JTBD).
5. "Hooked" — Nir Eyal (designing habits).
6. "The Mom Test" — Rob Fitzpatrick (customer interviews).
7. "Measure What Matters" — John Doerr (OKR).
8. "Trustworthy Online Controlled Experiments" — Kohavi.

10.2 Blogs and Newsletters

9. Lenny's Newsletter.
10. First Round Review.
11. Reforge Blog.
12. Stratechery (Ben Thompson).

10.3 Podcasts

13. Lenny's Podcast.
14. Acquired (Ben Gilbert, David Rosenthal).
15. This Week in Startups (Jason Calacanis).

11. The 90-Day Product Sense Starter

11.1 Month 1 — Empathy Foundation

• Five customer calls a week.
• Use your own product every day.
• Ten minutes a day in the support channel.
• Customer review sites once a week.

11.2 Month 2 — Framing

• Rewrite three features in the JTBD format.
• Discuss the NSM and the guardrails with your team.
• One hour a week of session recordings.

11.3 Month 3 — Judgment

• Re-prioritize the roadmap with RICE.
• Design one experiment yourself.
• Write a 90-day outcome document.

12. The 12-Point Product Sense Checklist

• A 30-minute conversation with five customers every month.
• Using your own product daily.
• Subscribed to the support channel.
• Fluent in the JTBD Job Story format.
• Team NSM understood and shared.
• Your own product diagnosed by PMF stage.
• Basic AB test statistics understood.
• RICE and ICE used for prioritization.
• Outcome-based roadmap.
• Product conversations with a PM as an equal.
• A quarterly customer deep dive.
• Steady intake of books and podcasts.

13. The 10 Product Sense Anti-patterns

1. "Engineers just implement": Staff+ is off the table.
2. Building feature requests exactly as filed: ignoring JTBD and the opportunity.
3. "If it does not sell, blame marketing": no awareness that PMF is missing.
4. Chasing only short-term metrics: ignoring retention and LTV.
5. Cherry-picking AB test results: looking only at the outcome you wanted.
6. Working without an NSM: building features with no direction.
7. Taking what customers "said" literally: the Ford "faster horse" trap.
8. Feature Factory: feature count as the KPI.
9. "No Time for Discovery": too busy executing to validate anything.
10. Treating the PM as the enemy: throwing away a chance to learn.

14. Closing — Product Sense Is a Muscle

"Good judgment comes from experience. Experience comes from bad judgment." — Mulla Nasrudin (attributed)

Product sense is not something you are born with. It is a function of the hours you have spent with users.

Five customer calls a week × 10 years = 2,500 calls. That accumulation is what turns you into a different engineer.

For an engineer in 2026, product sense is a Tier-1 route to Staff+. Technical skill gets offset by AI, but understanding users, markets, and the business is still human territory.

Three things are enough to start:

1. One 30-minute customer call this week.
2. Write your next PR description as a JTBD Job Story.
3. Read your own team NSM and summarize your next sprint contribution in one sentence.

Three months from now, your spec reviews are a different quality of thing.

Next Post — "Engineering Politics: Organization, Power, Decision-Making, Alliances, and Building Political Capital"

If product sense is the "what," organizational politics is "how you get it through." The next post covers:

• Defining power — Jeffrey Pfeffer and the book "Power"
• Accumulating and spending political capital
• Alliances and stakeholder mapping
• The kinds of conflict and how to resolve them — Lencioni and the 5 Dysfunctions
• "Push vs Pull" influence strategies
• Good Politics vs. Bad Politics
• Promotions, reorgs, and winning budget in practice
• Five things engineers routinely forget about politics

We drop the prejudice that "politics is dirty" and design politics that is both good and effective. Continued in the next post.