The new bottleneck in product is judgment, not research

The old center of gravity in product, months of deep research and bespoke design to guess at a solution, is losing its relative importance. Two forces did it: AI made building cheap and fast, and most product problems now have proven comparables and known dynamics. The bottleneck moved from gathering research to judgment. That is more opinionated understanding of your user, not less, and it does not take months to get there.

The most valuable skill in product used to be research. It isn't anymore. And I want to be careful with that sentence, because the obvious misreading is "understanding users matters less." It doesn't. The bottleneck moved.

Ten years ago the hard part of product was guessing. You ran months of deep user research and bespoke design to arrive at a solution nobody had built before, because there was nothing to copy and no cheap way to find out if you were right. Building was slow and expensive, so being wrong was slow and expensive. Research was the insurance policy against a build you couldn't afford to waste.

Two things changed that.

Two forces moved the center of gravity

The first is that AI made building cheap and fast. A working prototype that used to be a two-week sprint is now an afternoon. When the cost of trying a solution collapses, the value of a long research phase whose whole job was to avoid a wasted build collapses with it. You can just build the thing and look.

The second is quieter and matters more. Most product problems now have proven comparables and known dynamics. Onboarding, paywalls, referral loops, marketplace liquidity, activation, retention curves, these are not blank pages anymore. There is a decade of public teardowns, benchmark data, and pattern libraries for almost any consumer surface you are working on. Ten years ago you had to guess how to solve a product problem. Usually you don't. Someone has solved a version of it, and the shape of the answer is knowable before you write a line of code.

So if building is cheap and the solutions are mostly knowable, what's left to be hard?

The bottleneck moved to judgment

The scarce skill is no longer gathering research or guessing a solution. It's deciding. Who exactly is the user. What this product actually is. How you differ from what exists. Which problems actually move the metric. Where your real gap is versus the comparables everyone can see.

That is not less understanding of your user. It's more, and a more opinionated kind. Cheap builds and known patterns don't make the thinking optional. They raise the price of thinking badly, because the constraint on your product is now the quality of your calls, and not the speed of your hands. You can hold a sharp, well-argued point of view about your user and your market in a week. The old process treated a long calendar as proof of rigor, and it isn't.

Here is the judgment I actually run now.

1. Who exactly is the user, and who is this product for? Not a persona slide. A specific, defensible answer you would bet the roadmap on.

2. What is the product's identity? This is the one people get wrong. A product is rarely one clean category. It's usually a combination of a few products, and naming that combination is a real decision. Get it wrong and everything downstream aims at the wrong target.

3. How do we differ from what already exists, and what do we choose to differentiate on? With comparables sitting right there, your differentiation is a choice, not a discovery. And the choice is load-bearing, because it changes both the product you build and the user you build it for.

4. Which user problems are key, tied to the product, and most important to the metric, and where's our gap in solving them today versus other products? This is where most of the judgment lives, so it gets its own method below.

5. Then diverse, 10x thinking on solutions, build, test with your ICP, and prove or kill the hypothesis fast. By this point the thinking is done, and the build is the cheap part.

How to actually prioritize between problems

Step 4 is where teams stall, because every problem looks important when you list them out. Size them instead. Two axes.

Relevancy: what share of your users actually have this problem. Severity: how much it blocks them or matters to them. The trick on severity is to force the ranking, a 1-to-5 scale or a forced-rank or MaxDiff, so users can't rate everything "very important." If people are allowed to call everything a priority they will, and the ranking you get back tells you nothing.

Then get it direct. Poll your users with the bluntest possible question: why do you come back, or why don't you. You will learn more from a hundred of those answers than from a month of inferred journey mapping. Run probing tests and small bets across a few of the top areas, watch what actually moves the needle, keep collecting feedback, and hone in on the handful of problems that matter. The prioritization isn't a one-time ranking, it's a loop you tighten.

This isn't theory. It's how the work goes now.

A returning client came back recently wanting more user control in the product, more options, more configurability. Comparables and a few JTBD interviews said the opposite. Their users didn't want more control, they wanted it done for them. So we cut the option menu and fronted a single core path, one AI-driven flow that did the work instead of asking the user to. Activation doubled. The insight was the entire job. The build was an afternoon.

I'm running the same playbook on my own product right now, a zero-to-one build I'm testing with real users. I named my hypotheses about the space up front, mapped them to product combinations and to comparables that already exist, and I'm testing them with the actual target users to prove or disprove each one fast. There was no six-month research phase, just a point of view and then evidence against it.

And it holds outside consumer apps. Diagnose a marketplace that's short on supply, and you don't start from a blank page. Marketplace liquidity has known patterns. You can reason about it as a product-identity problem, a trust-first marketplace, say, and ask where its gap is versus the incumbent everyone compares it to, rather than commissioning net-new research to rediscover dynamics the category already understands.

The takeaway

Building is cheap and most solutions are knowable, so the edge isn't in the research or the build anymore. It's in the calls. Who the user is, what the product is, how you differ, which problems move the metric. That is more opinionated understanding of your user, not less, and you can get there in a week if you're rigorous instead of slow. The research was never the moat. The opinion is.

Common questions

Does user research matter less now?

No, the opposite. What changed is the bottleneck, not the value of understanding users. You no longer need months of research to guess a solution, because building is cheap and most problems have proven comparables. So the scarce skill moved to judgment, which requires a sharper and more opinionated understanding of your user than a generic research phase ever produced.

How do you decide which user problems to work on?

Size each problem on two axes: relevancy (what share of users have it) and severity (how much it blocks or matters, asked with a forced-rank or MaxDiff so users can't call everything important). Prioritize the high-relevancy, high-severity quadrant, confirm it by asking users directly why they do or don't come back, then run small bets and keep the ones that move the metric.

What replaces the long research phase in product work?

A fast, evidence-backed point of view. Name your hypotheses about the user, the product's identity, and your differentiation up front, map them against known comparables, then build a cheap version and test it with your ICP to prove or kill each hypothesis quickly. It is a faster process, not a shallower one.