Becoming an AI-Era PM 08 | AI Can't Find the Real Problem for You

a16z published a piece for product managers, its title roughly “5 Principles for Product Managers Fending Off Obsolescence in the AI Era.” One line in it lands hard: a PM’s job has always been resolving ambiguity, and AI hasn’t reduced that ambiguity — it just swapped the tools.

String the earlier pieces together: AI can help you judge (really, it gives you options and you decide), it can help you build the thing, it can turn a sentence into a product. But there’s one thing it never touched, start to finish — finding the real problem worth solving. Where the user is actually stuck, whether it’s a real problem, whether it’s worth doing — it can’t hand you those answers, because the answers aren’t in its training data. They’re out in the real world, in one specific person.

That’s exactly why a16z says “the pure process manager gets phased out, the one with a builder’s mindset has leverage”: the person who chases deadlines and runs alignment, AI can replace part of that; the person who finds the real problem and dares to go build and verify, it can’t. This piece covers four moves you can run in the discovery phase.

1. Don’t let AI come up with the requirement — go watch where people get stuck

The easiest shortcut is to open AI and ask, “what feature should I add to my product?” It’ll give you a tidy, plausible-looking list — all common features it’s seen in other products, not a single one grown from your actual users.

AI can only recombine what it’s seen; it can’t see the pain point nobody has put into words yet. That part is on you: find a real user, sit beside them, watch them do this thing with your product (or with whatever clumsy workaround they use today), and watch which step makes them frown, pause, or curse. That stuck point — AI will never see it for you.

2. Separate “what they say they want” from “what they’re actually stuck on”

The biggest trap in discovery is taking what a user says they want and turning it straight into a feature to build.

There’s a classic line: the user says they want a faster horse, but the real problem is they want to get somewhere faster. The real problem is hidden inside what they say, but it rarely equals it. They say “can you add an Excel export,” and behind it might be “every week I have to shove this data into another system and copying it by hand is painful” — the real problem is that two systems don’t talk to each other, and export is just the fix they happened to think of. Build “add export” to spec, and after you ship it they’re still in pain once a week.

Listen to what they say, but watch what they do. Behavior is more honest than words.

3. Hunt for the workaround — that’s the hardest signal of a real problem

How do you tell whether a problem is genuinely worth solving? Look for whether someone is already getting by with a clumsy workaround.

When someone, for the sake of one thing, would rather export a spreadsheet by hand every week, spin up a messy group chat, dump a pile of notes in a memo app, or string three tools together the long way round — those workarounds are the hardest signal there is: the pain is real, real enough that they’ll spend extra effort on it. What you have to do, often, is just replace that workaround. Flip it around: if no one will spend any extra effort on a problem, it’s probably not as painful as you think, and no matter how fast AI builds it, nobody will use the result.

4. Probe with a builder’s mindset — don’t wait until the requirements are complete

Once you’ve found a suspected real problem, don’t stop at research and documents, and don’t wait until you’ve thought through every requirement before you start. The builder’s mindset a16z talks about gets very concrete here: using the speak-it-into-being approach from the earlier pieces, build a minimal, runnable thing the same day and put it in front of that user to click.

“Does this solve the headache you just described?” — asking that with something they can actually click is far more accurate than handing them a survey. They click around twice, say “this part’s wrong, what I really meant was…,” and your grasp of the real problem moves one step closer. Finding the real problem is something you converge on by building, not something you nail in one pass inside a document.

One thing you can do today: pick a feature you’re about to build, and before you open AI, go find a real user (a coworker works too) and ask how they did this thing the last time and what clumsy workaround they’re getting by with now. That workaround is your way in to the real problem.

Further reading

• a16z, “5 Principles for Product Managers Fending Off Obsolescence in the AI Era” (builder’s mindset vs. pure process manager): https://a16z.com/stay-relevant-in-ai/
• Piece 04 in this series, “Judging ‘Should We Build It’ Costs More Than ‘Can We Build It’ for the First Time”: /en/blog/judgment-over-feasibility/
• Piece 01 in this series, “Which PM Work AI Took Over, and Which Work Got More Valuable”: /en/blog/ai-pm-what-changed/