Growing Your Product Sense

Product sense is knowing which three of the thirty things you noticed actually matter, why, and what you would build instead. It is finding and framing the problem worth solving, and reading who you are really serving before you answer them. It is the difference between a team that moves the number and a team that stays busy, and it is the spoke that decides whether everything downstream, however well built, was worth building.

This page is how you move yourself up one rung on it. It is a mirror, not a scorecard: find the row just above where you sit, and put your reps there. The craft itself lives in Product Sense and its group; this is the path through it.

Where you are now#

Find the line that sounds like your last month, honestly. The gap to the next row is the work.

Level	The tell
Intern	You build what is asked and do not yet weigh whether it is the right thing.
Junior	You bring a problem you have felt firsthand, and you ask instead of guessing when a request is unclear.
Mid	You turn a symptom into a sharp problem, check it is worth solving, and reframe a request into what it is actually asking before answering.
Senior	You find the problem worth solving from vague direction, read the real need behind a stakeholder’s question, and kill low-impact work early.
Lead	You build the team’s instinct for impact and set what “worth solving” means.

What moves you up#

The jump from each row to the next is the same move, made earlier and with less prompting: stop answering the screen and start answering the outcome.

Start from winning, not from what is broken. If you cannot describe what “best in the world” would mean for this product, your list of problems has no reference frame. Winning first, gaps second. This is the instinct the whole Product Sense group is built to train.
Serve a named person, not “users.” “Users want faster checkout” points at nobody. “A shopper on a phone deciding in ten seconds whether to trust us with a card” points at a decision you can build for. See Personas & Jobs.
Treat every request as a symptom of a need. The literal ask is rarely the job. “Add an export button” is a screen; “finance re-keys these numbers into a spreadsheet every Monday” is the problem. Answer the second one.
Earn the opinion before you bet on it. An opinion you argued into existence is still a guess until it survives real users and real data. The bigger the build, the more you owe it to go reduce the uncertainty first. See Earning the Opinion.

The habits that keep you stuck#

Everyone starts as a symptom-collector. It is the default output of confusing “using the product and noticing things” with “understanding the product.” The reps below kill it. These are the shapes to catch yourself in:

Bad: “The filter forgets my selection, the images are small, the wishlist is hard to find, search is too narrow.” Six true things, weighted equally, aimed at nothing, from someone who never checked that orders have been flat for two halves.

Good: “One in five shoppers abandon checkout rather than re-type an address, roughly 190 orders a week. That is where we are weak, and owning checkout is how we win. The images and the wishlist are real and cheap and move zero orders, so ignore them for now.”

The tells that you are still collecting:

Everything is important, which is the same as nothing being important.
A feature request dressed as insight: “we should add X” with no problem underneath it.
Copying a competitor because they do it, not because you know why it wins.
Building the literal ask without once asking what the person is actually trying to do.

The reps that level it up#

To move a rung, do the next row’s work one step before it feels comfortable, then close the gap with review. For this spoke:

Before you build anything, write one line: who is this for, and what changes for them when it ships. If you cannot, you are not ready to build yet. Do this on the smallest ticket, not just the big ones.
Own Discover on a real problem before it is framed for you. Take a vague direction and come back with the sharp problem, not a solution.
Reframe a request out loud to the person who asked, before you touch it. “It sounds like the real need is X, is that right?” You will be wrong often at first. That is the rep working.
Sit in one “should we even build this?” call and argue the kill. Killing low-impact work early is a Senior move you can practice from any level.

The one question#

Before anything you build ships, ask: if this goes out exactly as asked, what number moves, and for whom?

If you can name the number and the person, you are thinking at the system level. If you cannot, you are still collecting symptoms, and that is the thing to fix before the code.