Every PM has a version of this meeting. A VP walks in with a screenshot of a competitor’s product page, or a blog post from an analyst, or a slide from a board deck.
The message is some variation of: “We need an AI strategy.”
Not “our customers have a problem that AI might solve.”
Not “here’s a workflow where people are losing hours.”
Just: we need AI. Go figure out where it goes.
This is the meeting where product management, as a discipline, either holds or folds.
How the process broke
For most of software history, the job worked in one direction. You found a problem, validated it, explored solutions, and shipped something.
The solution was downstream of the problem—it’s in every PM curriculum ever written.
The AI gold rush inverted this: execs saw AI explode on the scene, heard competitors announcing AI features, realized 199 of the S&P 500 mention AI on earnings calls in a single quarter, and issued a directive: use AI.
The problem became the PM’s job to find after the fact.
Most leaders didn’t intend to break their product process.
They were responding to real market pressure—investors wanted AI narratives, boards wanted AI roadmaps, Microsoft’s 2025 Work Trend Index said two-thirds of business leaders wouldn’t hire someone without AI skills. None of that is irrational.
But it produced an irrational output: thousands of product teams working backward from a technology to find a use case.
An MIT study published in mid-2025 found that 95% of enterprise AI pilots deliver zero measurable P&L impact.
Not “underperformed expectations.” Zero.
The study analyzed over 300 public AI deployments and interviewed 150 leaders. The author put it plainly: organizations are failing because of how they adopt AI, not because of the models themselves.
Solutions looking for problems
Dedicated AI hardware
Humane spent $230 million building the AI Pin, a $700 wearable that projected a tiny screen onto your palm. It was “the worst product I’ve ever reviewed.” MIT Technology Review said it “seemed to be trying to solve a problem that did not actually exist.”
The Rabbit R1 had the same thesis—dedicated AI hardware—and reviewers quickly discovered it was essentially ChatGPT with a launcher.
Both products answered “What if AI had its own device?” without asking “What task are people failing to accomplish with the devices they already have?”
Features nobody asked for
Meta replaced Instagram’s search bar with “Ask Meta AI or Search.”
Kate Moran, VP of research and content at Nielsen Norman Group, wrote:
“I highly doubt that any actual Instagram user was sitting around and wishing that Instagram could tell them the best way to say sorry. The only thing worse than an unnecessary AI chat is an unnecessary AI chat that blocks a useful feature like search.”
In a separate interview with Euronews, she called it “technology-led design”—starting with the tool and working backward to find a problem.
She compared it to Flash plugins in the early 2000s. Jakob Nielsen wrote at the time that Flash was “99% bad.” Not because Flash couldn’t do useful things, but because 99% of the time it was being used for the wrong reasons.
LinkedIn launched AI-generated follow-up questions under posts, then quietly retired them. One generated the question “When should you use open-ended questions in user interviews?” underneath a post that specifically explained when to use open-ended questions in user interviews.
Spotify replaced beloved human-curated Wrapped features with AI-generated content for 2024—made-up micro-genres like “Pink Pilates Princess” and an AI podcast powered by Google’s NotebookLM that couldn’t even read numbers correctly. VP Gustav Söderström admitted “there was more negative feedback than we’ve seen before.”
Automation theater
McDonald’s tested AI drive-throughs for three years across 100+ locations before pulling the plug in mid-2024.
Viral videos showed the AI adding 260 Chicken McNuggets to a single order. Accuracy was stuck in the low-to-mid 80% range and operating costs were high.
Amazon’s “Just Walk Out” checkout—marketed as AI-powered autonomous retail—turned out to rely on roughly 1,000 workers in India manually reviewing transactions. In 2022, 700 out of every 1,000 sales required human verification—against an internal target of 50.
Every one of these started from the same place: we have AI, find a use for it.
What problem-first actually looks like
Most battle-scarred PMs have adopted a framework similar to:
- Personas — a specific human with a specific job and specific constraints. Not a marketing segment.
- Problems — what’s broken in their workflow. What they can’t do, what takes too long, what fails silently.
- Evidence — proof the problem exists with data. Not anecdotes from a sales call or a hunch from an exec offsite.
- Impact — what solving this would be worth, to the user and to the business.
- Hypotheses — proposed solutions (plural) that you can test.
AI shows up, if it shows up, at step five.
The answer could just as easily be a better API, removing a screen from a workflow, or discovering the problem doesn’t exist and you should work on something else.
When your VP’s VP has told the board there’s an AI roadmap, skipping to step five isn’t just the path of least resistance—it’s the path of career preservation.
“I investigated the problem and AI isn’t the right solution” is a real thing a PM has to be willing to say. Whether they actually say it depends on the org.
What you find when you start from the problem
More than half of enterprise AI budgets go to sales and marketing tools. But the biggest measurable ROI comes from back-office automation—reducing outsourcing, cutting agency costs, streamlining operations. The least glamorous applications produce the most value.
When you start from the problem, you rarely end up building the thing that looks impressive in a demo. You end up building the thing that saves someone forty-five minutes on a Thursday—automating a report that three people hate producing, or fixing the gap between two systems that a team has been working around for years with a shared spreadsheet.
Companies buying specialized AI tools from vendors succeed about 67% of the time, while internal builds succeed a third as often—not a talent gap, but a focus gap. Vendors started from a specific problem in a specific domain and built a focused solution. Internal AI projects are more likely to start from “the CEO wants something with AI in it.”
The 5% of pilots that work share traits the study’s authors explicitly name:
- They pick one specific pain point, not a platform play.
- They execute with domain specificity—deep workflow integration, not bolt-on features.
- They buy specialized rather than building internally (67% vs. 33% success rates).
- They measure business outcomes, not adoption vanity metrics.
Foundation model selection, prompt engineering, and vector database choices don’t show up anywhere in the MIT findings.
Discipline about the problem matters more than sophistication about the technology.
Where it works
Adobe Lightroom’s AI-powered object removal solves a specific problem: photographers spend absurd amounts of time manually cloning out unwanted elements.
Nielsen Norman Group highlighted it as a model of problem-first AI: “That isn’t a sexy or flashy feature, but it makes a big difference to anyone who edits photos.”
Cursor started from one observation: developers spend most of their time reading and navigating code, not writing it. It grew to a $29.3 billion valuation by solving that workflow problem well.
(Cursor also had its own AI incident—a support bot that fabricated company policy—which I wrote about previously. Starting from the problem doesn’t inoculate you from the personality problem. But it means the core product has a reason to exist when the AI misbehaves.)
The MIT study found the highest-ROI deployments in two areas:
- Healthcare, where AI models detect cancers that radiologists miss—a life-or-death problem with measurable false-negative rates.
- Back-office operations, where the problem is “we’re paying $2 million a year for a team of contractors to reconcile data between two systems.”
These projects didn’t start in a meeting about AI. They started with “our radiologists are missing 12% of early-stage lesions” or “this reconciliation process takes 4,000 person-hours a quarter.”
AI turned out to be part of the answer, but the problem is what kept the project honest.
Why this is hard right now
Product teams are being evaluated on whether they shipped AI features, not on whether those features solved problems.
The incentives run the wrong direction.
The SEC issued its first civil penalties for “AI washing” in March 2024—charging investment firms Delphia and Global Predictions for falsely claiming AI capabilities they didn’t have. The FTC launched “Operation AI Comply” the same year. Chair Lina Khan: “There is no AI exemption from the laws on the books.”
That regulators are prosecuting companies for claiming to use AI tells you how strong the incentive has become.
The California Management Review identified root causes: lack of technical AI knowledge in senior leadership, a culture that rewards announcements over outcomes, and pressure to attach the AI label to everything.
We’re in the Flash era of AI—the technology is powerful, but most of what’s being built with it is being built backward.
How I apply this
At Chrome Enterprise, I work on AI capabilities—MCP servers, Gemini integrations, enterprise identity infrastructure.
This is a team explicitly chartered to build AI features. The pressure to start from the solution is constant, and it comes from the right place.
But the Impact Stack still applies. When we evaluate where to invest, we start with the admin persona:
- What workflow takes too long?
- What decision do they lack information to make?
- What configuration task goes wrong because the policy model is too complex for a human to hold in their head?
Sometimes the answer is an AI feature—a natural language query interface, a diagnostic assistant. Sometimes it’s a better dashboard, a simpler policy model, or clearer documentation. The methodology doesn’t have a bias toward AI or away from it—just toward the problem.
Evidence is the hardest part of this.
Any PM can articulate a plausible-sounding problem. Fewer can who can prove the problem exists with data, prove it matters with impact analysis, and resist the temptation to skip to the solution leadership already wants. Especially when the solution leadership wants is “AI.”
Before you write a PRD
Write the problem statement before anything else. Not “users would benefit from AI-powered X”— That’s a solution wearing a problem’s clothes. A real problem statement has four parts:
- A specific persona (not “users”)
- What they’re trying to do
- Why they can’t do it (or why it takes too long, or why it fails)
- Evidence that the problem exists
Here’s what that looks like:
“Enterprise security admins spend an average of 3.2 hours per DLP incident investigating which policy triggered and why, because the policy evaluation logic is opaque and the logs don’t surface the decision chain.”
You can measure that, solve it multiple ways, and evaluate whether your solution actually made it better. AI might be the right tool—a natural language interface that explains policy decisions in plain English, say. Or maybe the right tool is a better log viewer. Hard to say without looking at the problem first.
The 5% that succeed pick one pain point, execute with specificity, and integrate into existing workflows. That’s the recipe for any good product, AI or otherwise.
