What Is Product Sense?

What does product sense mean in practice?

Product sense is the habit of asking the right questions before a product decision, so that the call you make holds up when the data is thin and people disagree. Jules Walter, a longtime PM at Slack and YouTube, put it this way in Lenny's Newsletter: "Product sense is the skill of consistently being able to craft products (or make changes to existing products) that have the intended impact on their users." The word that matters in that definition is "consistently". One lucky feature is not product sense; a track record of calls that land, plus reasoning you can explain in advance, is.

Walter's article also describes product sense as ranking near the top of the PM skills in Lenny Rachitsky's survey of roughly 1,000 PMs, while being the vaguest of them to describe. That survey measures what PMs say matters, not what their managers reward, but it still shows the gap: everyone agrees the skill counts, and few people can say what it is made of.

A working definition you can use on Monday morning: product sense is visible in three places. It is visible in what you build, in what you choose not to build, and in how you explain the difference to a stakeholder who wanted the other option.

Why does what you skip count as much as what you ship?

Most product teams build more than their users use. Pendo's 2019 Feature Adoption Report found that 80 percent of features in the average software product are rarely or never used. The figure comes from 615 Pendo customer subscriptions and only counts features those customers chose to tag, so it describes Pendo's own customer base rather than all software. It still points the same way: a large share of what gets shipped never earns its maintenance cost.

That is why a PM with strong product sense spends as much effort on the no as on the yes. Saying no to a plausible feature is a product decision with a user cost, a business cost and a team cost, and it deserves the same reasoning as a launch. If you want the mechanics of the conversation itself, the guide on how to say no to stakeholders covers it.

How do user, business and technology trade-offs shape a decision?

Every product sits where three forces overlap: what users need, what the business needs to keep funding the product, and what the team can build and keep running. You almost never get the maximum of all three. Product sense is less about finding a perfect balance and more about choosing, on purpose, which force gives way this time.

Take a food delivery app deciding whether to show the full delivery fee on the restaurant list instead of at checkout. Users want the real price early, because a surprise fee at the last step feels like a trick. The business worries that showing fees earlier lowers the number of people who start an order. Engineering points out that fees depend on distance and demand, so showing an accurate figure on a long list of restaurants means calculating it for each one on every scroll.

A PM with weak product sense picks the side of whoever argued loudest. A PM with strong product sense names the tension in one sentence: "We are trading some top-of-funnel starts for fewer abandoned checkouts and more trust, and we will accept an estimated fee range instead of an exact one to keep the list fast." That sentence is the skill. It makes the loser of the trade-off explicit, it proposes a technical compromise, and it tells everyone what to measure.

Common tensions you will meet again and again:

• Best experience against monetisation: removing an ad slot makes the page better and the quarter worse.
• Speed to market against stability: shipping this sprint means shipping with known edge cases.
• Simplicity against flexibility: every new setting helps one segment and confuses another.

How do you build product sense week by week?

Product sense grows from feedback loops, and most PMs get too few of them because real launches take months. You can shorten the loop with a routine that fits into about an hour a week. Walter describes spending one or two hours a month deconstructing new products; the routine below keeps that habit and adds a prediction step so you can check yourself.

1. Pick one product you used this week, ideally one outside your industry.
2. Write down what you think the company's goal is and who its target user is, in two sentences.
3. Walk one flow (sign-up, checkout, sharing) and note one place where the design serves that goal and one place where it works against it.
4. Propose one improvement, then write the trade-off it creates across user, business and technology.
5. Make one prediction about a product you work on ("this onboarding change will reduce support tickets about setup"), date it, and set a reminder to check it.
6. Once a month, reread your old predictions and mark each one right, wrong, or right for the wrong reason.

Step 6 is the one people skip, and it is the one that turns opinions into judgment. A prediction you never check teaches you nothing, even if it happened to be correct.

What does good product sense look like in a real decision?

Strong product sense is easiest to spot in how a PM handles a request. Suppose the head of sales at a B2B invoicing tool asks for an "export everything to Excel" button because two prospects mentioned it. A PM on autopilot adds the ticket. A PM with product sense asks what the prospects are trying to do with the spreadsheet, finds out that their finance teams reconcile invoices against bank statements every month, and realises the real problem is reconciliation, not exporting.

That reframing changes the solution space. A bank-feed match might serve the job far better than a spreadsheet, or the export might still be the fastest fix for this quarter. Either way, the decision now rests on the problem instead of on the words of the request. The problem statement template walks through that decoding step in detail, and the product decision making framework turns the rest of the call into a seven-step checklist you can run before committing.

Is product sense the same thing interviewers test?

Partly. Meta's PM loop includes a product sense round, according to the Aced guide to the Meta PM interview, where you design or improve a product under time pressure, and the interviewer is sampling the same habits described here: choosing a user, framing the problem, and weighing trade-offs out loud. The format adds its own conventions, which the Meta product manager interview questions guide and the product manager case interview framework cover.

The honest limitation of interview prep is that it rehearses the performance, not the skill. Candidates who memorise a framework can pass one round and still struggle on the job, where there is no interviewer steering them and the consequences of a bad trade-off last for quarters. Build the day-to-day habit first and the interview answer gets easier as a side effect.

How does Builders Camp teach product sense?

The Product Sense bootcamp runs over 2 weeks with 3 live sessions of 90 minutes each, directed by Mihaela Draghici. It covers problem framing, decisions under uncertainty with weak or misleading data, trade-offs between user value, business needs and technical constraints, and stakeholder disagreement. Its practical challenge asks you to make a defensible call on thin data and write the decision memo; you can try a version of it in the product sense case study exercise. The bootcamp is part of the Product Leadership Track and included in the Builders Camp Membership.

Builders Camp runs live and self-paced bootcamps in product management and AI product building. See the Product Sense bootcamp for the next cohort and the self-paced version.