The Most Important Product Management Skill in the Age of AI Isn't Product Management

I've been wrestling with the same problem since 2013.

Back then, I was working on early machine learning features for the Moto X — the "Active Display" stuff, the always-listening "Ok Google Now" wake word, contextual awareness that tried to figure out if you were driving, walking, or sitting in a meeting. Later at Nest, it was occupancy detection and the Auto-Away algorithm trying to guess whether you'd actually left the house or just walked to the mailbox.

We weren't flying blind. We had false positive and false negative rates. We knew, roughly, how often the wake word triggered when nobody said it, and how often it missed when someone did. We knew how often Auto-Away kicked in while someone was still on the couch, and how often it failed to kick in when the house was actually empty.

But those measurements were simplistic. A single FP/FN rate told you the system was wrong X% of the time — it didn't tell you what that meant for the product. A false positive that turned the screen on in your pocket was annoying. A false positive that left your heat blasting while you were on vacation was expensive. Both counted the same in our metrics, but they were not the same product experience.

That's the real problem, and it's not a new one: it's the quality of the inputs, the expectations for the outputs, and the gap between "the model works" and "this is a great product."

Twelve years later, I'm staring at the same problem. Except now it's about LLMs, the surface area is enormous, and the inputs and outputs are language instead of sensor data — which makes quality both harder to define and harder to dodge.

AI Changes the Job, Not the Problem

For most of my career, product management followed a familiar pattern. You identified a customer problem, wrote requirements, engineering built the feature, you shipped it, and then you measured adoption, retention, and business impact. Not a perfect process, but an understandable one.

AI doesn't replace that pattern so much as expose a weak point that was always there.

The biggest shift isn't that AI products are harder to build. It's that they're fundamentally harder to predict. In traditional software, a correctly written function behaves the same way every time. Inputs go in, outputs come out, the system is deterministic. That was mostly true of the Moto X's display logic, even with its false positives — the sensor either fired or it didn't. It is not true of large language models.

The same prompt can produce different outputs. A model upgrade can improve one task while quietly making another worse. A retrieval change can dramatically help some users while breaking things for others in ways nobody notices until support tickets start rolling in.

So the question every AI PM eventually has to confront is: what does quality even mean for a system whose behavior is probabilistic, and how do you hold the line on it?

The answer is the same discipline we needed back at Moto and Nest — just applied with far more nuance than a single FP/FN dial ever allowed.

You stop thinking like a traditional product manager and start thinking like a measurement designer.

Quality Starts With Inputs

Here's something that got buried in our old FP/FN numbers: a huge share of "model errors" were actually input problems. Sensor placement, noise environments, lighting conditions, how someone actually held their phone versus how we assumed they'd hold it. The model was often working fine given what it received — what it received just wasn't representative of real use.

The same is true with AI products today, arguably more so. Garbage in, garbage out is not a cliché, it's the whole game. If the context an LLM receives is incomplete, stale, or poorly structured, no amount of prompt tuning fixes that. Quality work starts before the model ever runs — with what data it has access to, how clean that data is, and whether it actually reflects what the user is trying to do.

Quality Means Defining the Job to Be Done

Most AI teams make the mistake of starting with capabilities. Can the model summarize? Can it search? Can it write emails?

These are implementation details. Users don't care about capabilities — they care about outcomes, and "great product" is defined entirely at the outcome level. A user doesn't want a summarization engine; they want to quickly understand what happened in a meeting. They don't want a retrieval system; they want to find information without burning thirty minutes searching.

The first step is naming the real job the customer is hiring the AI to do. For a personal AI assistant, those jobs might look like:

• Finding relevant information from your history
• Drafting emails
• Generating invoices
• Planning travel
• Analyzing financial decisions
• Summarizing meetings

Each of those becomes a measurable task category — and each one carries its own definition of "good output."

Build a Task Taxonomy

Once you've identified the outcomes people actually care about, build a taxonomy. Think of this as your product's operating system for evaluation — something like recall, planning, research, writing, analysis, and agent actions.

Every user interaction should land somewhere inside that framework. This is the fix for what our FP/FN rates got wrong: instead of one blended error rate covering everything from "screen turned on in my pocket" to "thermostat ran while I was at the airport," you're evaluating specific classes of behavior separately, against specific expectations of quality.

Build Golden Datasets — Your Definition of "Good"

Here's where AI product management really diverges from the old playbook. Instead of writing requirements documents, you start building examples of what a great output actually looks like. Lots of them.

• "What happened with the OpenWeb acquisition?" → a good answer includes escrow details, tax withholding requirements, share allocations, and payout status.
• "Draft an invoice for a coaching client." → a good answer has the correct session count, pricing, and payment terms.
• "What did we discuss about Portugal?" → a good answer covers Lisbon, the Algarve, Porto, train routes, housing preferences, and flight details.

Collect hundreds or thousands of these, and you've got a golden dataset — a concrete, working definition of product quality. It's the spiritual successor to our FP/FN logs, except each example carries its own context about what "correct" looks like, instead of collapsing everything into a single error percentage.

Measure Outcomes, Not Model Stats

One of the easiest traps in AI is measuring things that don't matter to users: tokens, latency, cost, context length. These matter operationally, but they're not what people feel, and they're not what great product means to a customer.

Users care about whether the task succeeded, whether the answer was accurate and complete, whether it saved them time, and whether they had to rewrite it. An answer that arrives in three seconds instead of two is rarely transformational. An answer that's correct instead of incorrect usually is.

This is the lesson hiding inside our old FP/FN numbers that we never fully acted on — a false positive on Auto-Away wasn't just "wrong," it was "wrong in a way that cost the user money and trust." We had the rate. We didn't have the expectation it was failing to meet.

Run Offline Evaluations — Every Time

Prompt change? Run evaluations. Model upgrade? Run evaluations. Memory architecture change? Run evaluations. Retrieval update? Run evaluations.

You should know whether a change improves or degrades quality before it reaches a single user. A simple eval dashboard might look like:

Baseline: 82% → Prompt revision: 87% → Retrieval upgrade: 91% → Memory improvements: 94%

Now product decisions are evidence-based instead of intuition-based — which is what our simplistic FP/FN tracking was reaching for but never quite delivered, because it was one number trying to describe quality across a hundred different situations.

Run Online Evaluations Too

Offline evals are necessary but not sufficient. Users always find edge cases that benchmarks miss — that was just as true of Auto-Away as it is of an LLM. The best teams combine offline and online evaluation, tracking things like acceptance rate, regeneration rate, follow-up clarification rate, manual editing rate, and thumbs up/down feedback.

If users rewrite every email the system drafts, it doesn't matter what the benchmark says. Real-world behavior is the ultimate evaluation — and the ultimate definition of whether you've built a great product.

The New Product Management Stack

I've started thinking about AI product management as a hierarchy:

Business Goal → User Outcome → AI Task → Evaluation → Metrics → Product Decisions

For example: the business goal is increasing coaching revenue. The user outcome is reducing administrative overhead. The AI tasks are drafting invoices, drafting emails, and managing scheduling. The evaluations are 100 invoice tests, 100 email tests, and 100 scheduling tests. The metrics are accuracy, acceptance rate, and time saved. And the product decisions — prompt changes, model changes, workflow changes — fall directly out of that.

This framework draws a straight line from business outcomes all the way down to model behavior, and at every layer it's answering the same question: does this meet the expectations of a great product? That's the structure our early FP/FN work was missing — not because we didn't measure, but because we measured one flat thing instead of a hierarchy connected back to what users actually expected.

The Future of Product Management

For years, product managers were primarily requirement writers. Then we became experiment designers. Now we're becoming evaluation designers — and quality designers, whether we use that title or not.

The best AI product managers aren't necessarily the people who write the best prompts. They're the people who design the best measurement systems, because quality isn't a feeling — it's the gap between what users expect and what they get, made visible and trackable.

Without evaluation, AI development feels like magic. With evaluation, it becomes engineering, and the product gets to be great on purpose instead of by accident.