The half of the job AI can't do for you

AI is taking the parts of design and product work that used to make people look valuable. Mockups, first drafts, export buttons, error copy. It does the how. That leaves your team fighting over the what, and a fuzzy word, "product sense," gets thrown around like it settles the question. It doesn't. Let me catch you up on what the research crowd is actually saying and what it means for how you run your team.

Product sense is a loop, not a vibe

The common advice is to read teardowns, study great products, and absorb inputs until good judgment appears. Tanner Kohler at NN/g argues that collecting scattered inputs won't build reliable intuition. He offers a sharper definition: product sense is the ability to recognize when a current problem matches a past win or loss, and estimate how a similar solution will land.

The part that matters for your team: you build that skill by closing the full loop. Face a problem, pick a solution, ship it, measure the result, reflect. Skip the back half and you get the firefighter who takes the first half of every shift but never stays to see if the building collapsed. Plenty of hours logged, no idea what actually worked.

So the danger is not AI doing the drafting. It's people handing off decisions, moving on, and never seeing outcomes. That team feels experienced and isn't.

The pattern that lies to you

Kohler splits problems into three buckets, and one is a trap. High-validity situations look familiar and let a pro match a pattern fast, like fixing a checkout flow you've fixed before. Low-validity ones give thin cues, so at least you stay unsure. "Wicked" situations are the killers: they feel exactly like a sure thing but the old solution is wrong here.

His example is a team that copies a feature that won on another product, skips research because the pattern feels obvious, and watches it flop because the new audience wanted something else. Confidence was high, the match was fake.

For your reviews, this is a concrete question to ask: is this a real pattern match, or does it just feel like one? Strong product sense includes knowing when your gut does not apply.

Stop guessing, watch the tape

One way to close the loop faster is to stop waiting on the data team. Getter Chen spent two years using session recording to answer questions in 30 minutes instead of the usual week-long chain of PM to data team to SQL to report.

The workflow is plain. Pull the numbers, screenshot them, attach them to a proposal. "90% of users on this page use List Mode, only 10% use Grid Mode," so List Mode gets the design effort. In a spec review, when a dev raises an edge case, she queries the flow live and the team decides on the spot.

She's honest about limits. It can't replace A/B testing, it shows behavior not causation, and it won't tell you why someone hesitated. But it moves designers from waiting on reports to working data like a material. That's the measure-and-reflect half of the loop, running in minutes.

Writing UX down so the machine reads it

Here's the shift that hits your artifacts. When AI does more of the building, AI becomes the reader of your research and design work, not a human. Tony Alicea calls the response UX-context design: curating what your org knows into context the tools use every time they generate anything.

A persona with a stock photo helps a human empathize. A model doesn't need persuading, it needs the reasoning. The proof already exists: in April 2026 Google Labs open-sourced DESIGN.md, a text file that sits next to the code holding exact color and spacing values plus plain-prose do's and don'ts, so tools "know exactly what a color is for." Alicea's bigger idea, UX.md, would add research findings, interaction rules, a glossary, and context of use.

Two things make this different from a normal deliverable. It's judged by whether AI output improves, not by whether stakeholders nod. And it lives with the code, updated as the product and your research change. No handoff, no document rotting in a drawer.

The deep cut

These two moves point the same direction. If AI is generating your interfaces, your research only counts when it's written down where the tools can see it, in plain findings like "users abandon setup when asked for info they don't have on hand." And your people only build judgment when they stay long enough to measure what they shipped.

So the risk isn't that AI writes bad first drafts. It's that your team stops owning outcomes and stops recording what it learns. Both leave you with output and no wisdom. On Monday, pick one shipped decision from last quarter and ask what actually happened after launch. If nobody knows, that's the gap AI won't fill for you.

Three questions for your team

1. For the last three features we shipped, who stayed long enough to measure the outcome, and what did we learn? If the answer is nobody, you're building output, not product sense.
2. Where are we treating a "we've seen this before" as proof? Name one current bet that feels obvious and go check whether the pattern really holds for this audience.
3. Is our research written anywhere the AI tools can read it, in plain findings and machine-readable design standards? If not, every mockup a PM or engineer prompts is starting from the average, not from what we know.