Product Sense

Product sense is the ability to look at a product and know what’s good, what’s missing, and what would win. Not a hunch. A formed opinion you can defend, built from who the product is for, what they’re trying to do, and what “great” would actually mean for them.

This is the group’s anchor. Strategy tells us where we’re going. How We Build is the machine that ships it. Product sense is what happens in between: it turns a direction into the right thing to build, and it’s the difference between a team that moves the needle and a team that stays busy.

It is also the skill that is easiest to fake and hardest to actually have. You can walk a product, write down everything that annoyed you, and produce a long, confident-looking list. That list feels like work. It is not product sense. Product sense is knowing which three of those thirty things matter, why, and what you’d do instead.

The Failure Mode This Group Exists to Kill#

Here is real output from a product person asked to walk our online store, the Storefront, and tell us how to make it the best.

What we got:

• The product images on the listing page are too small.
• The filter sidebar forgets my selection when I hit back.
• The wishlist button is hard to find.
• The search bar is too narrow.
• The category menu could use icons.
• A few links in the footer are outdated.

Every item on that list might be true. A couple are real bugs we should fix. But read the whole thing and ask: who is this store for, what are they trying to do, and would fixing all six sell one extra order? The list can’t answer any of those questions, because it was never asking them. It’s a walk-through of surface friction, sorted by nothing, aimed at nothing, from someone who never checked that the store’s orders have been flat for two straight halves.

Now here is what good looks like. Same store, same prompt, same afternoon, a product thinker hands back this instead:

Same store, same hour. One produced a to-do list; the other produced a plan to move the number. The difference is not effort or talent, it’s that the first collected symptoms and the second understood the system. (The full worked version is the case study.)

That’s the whole split, and it has a name. The first response is the symptom-collector: the default output of anyone who confuses “using the product and noticing things” with “understanding the product.” We are killing that habit. This group is how.

None of this is about online stores. Point a symptom-collector at a hiring tool, an analytics dashboard, a delivery app, or a chat product and you get the same shape of useless list: real-ish, unranked, aimed at nothing. The discipline here applies to every product you will ever touch. We use one running example, the Storefront, the same online store the Strategy group uses, so the ideas stay concrete and the two groups tell one story. The example is a vehicle. The thinking is the product.

The tell is the same one from Discover: a symptom is not a problem, and a complaint is not a direction. “The search bar is too narrow” is an event. “One in five shoppers who reach checkout abandon rather than re-type their address” is closer to a problem. “We have never designed the checkout around what a shopper with a full cart is actually trying to do, pay and leave” is the system. Product sense operates at the system level.

What Product Sense Actually Is#

What’s expected: When you look at a product or a feature, you can say what it’s for, who it’s for, where it’s weak, and what you’d change to win, and you can defend each of those against a challenge.

What good looks like: You lead with an opinion, not a list. You can name the two or three personas the product serves and rank them by who matters most to the goal. You know the job each one is hiring the product to do. You can point at the one seam where the product could be best in the world and explain why that’s the place to bet. When someone pushes back, you either hold the line with a reason or update, but you don’t retreat to “well, it’s just my opinion.”

What good does not look like: A long even-weighted list. Feature requests dressed as insight. “Users want X” with no user named. Everything marked important, which is the same as nothing marked important. Copying what a competitor does because they do it.

How to get there: Product sense is built, not born. It comes from three habits:

• Use the product as each persona, not as yourself. You are not the shopper on a phone, on the train, deciding in ten seconds whether to trust this store with a card. You are not the operator who lives in the admin all day. Get into their situation before you judge the screen.
• Ask what winning would look like before you list what’s broken. If you can’t describe “best in the world” for this product, your bug list has no reference frame. Winning first, gaps second.
• Form the opinion, then attack it. Write down what you’d do. Then argue the other side hard enough to break it. What survives is product sense. What doesn’t was a preference.
• Earn it before you bet on it. An opinion you argued into existence is still a guess until it survives contact with real users and real data. The bigger the thing you’re about to build, the more you owe it to go reduce the uncertainty first, talk to the persona, watch the journey, pull the numbers. Conviction without evidence is just confidence, and confidence ships the wrong thing. See Earning the Opinion.

The Scaffold#

You will not always have the opinion ready. When you don’t, work through a fixed structure so you reason your way to one instead of jumping to the first fix you see. Work the five steps below in order. (Product people sometimes call this shape CIRCLES; the name doesn’t matter, the discipline does.)

The rest of this group walks each step and gives you the fundamentals underneath it:

• Personas & Jobs — who you’re building for, and how to pick the one that matters.
• Pain Points & Winning — real needs vs. surface complaints, quality attributes, and how we decide to be the best.
• Earning the Opinion — how you know: reducing uncertainty with evidence before you commit.
• Goals & Success Metrics — how to set a goal that can’t be gamed, and measure the thing that matters.
• Constraints & Cost — why we can’t build everything, and the bar for spending scarce capacity.
• Prioritization — deciding what to build when everything looks worth building.
• Case Study: The Storefront — the shallow list above, reworked into real product thinking, end to end.

The scaffold is a crutch for when the opinion isn’t obvious. The goal is to internalize it until you don’t need it: until you can look at any product and know, in an afternoon, who it’s for, where it’s weak, and how it wins.

The Standard#

We measure product people on impact, the same as everyone. A hundred logged observations that change nothing is worse than one reframe that changes what we build next quarter. Your job is not to have opinions about pixels. It’s to know what would make this product the best in its category for the people who depend on it, and to be right often enough that the team follows you there.

Be critical. Be specific. Have a point of view. If you can’t defend it, it wasn’t one.

Next: Personas & Jobs