Stop Building Features. Start Defining Outcomes: The Three Columns Every AI Product Manager Must Rewrite Now

I remember the exact moment my career as a product manager flashed before my eyes.

I was presenting a plan for an AI-powered customer service bot. The tech was solid — natural language processing, multi-turn dialogue, the works. My boss and the CEO stared at me. They didn’t ask about the model. They asked one question: “How many people will this replace, and how much will it save us?”

I had a spreadsheet ready. I calculated the cost per agent, multiplied by the number of seats I claimed the bot could replace, subtracted the implementation cost. The numbers looked beautiful. The project got approved.

But I knew the numbers were fake. The bot wasn’t deterministic. It could answer some questions brilliantly, but it hallucinated on others. It couldn’t consistently replace a human. My spreadsheet was a lie — a desperate attempt to fit a probabilistic system into a deterministic business case.

That boomerang came back and hit me square in the face when I started building AI agents. The same problem that haunted me then is now haunting every AI PM: you can’t price what you can’t define, and you can’t define what you can’t measure.

Fast forward to WAIC 2026. The big players — Huawei, Tencent, Alibaba, Baidu — all but buried their models in the back of their booths. The new star was the agent. Over 60% of exhibitors now label themselves as AI agent or smart application companies first. As one analyst put it: “Last year everyone was bragging about their engine. This year it’s about who can deliver the whole car.”

Models are becoming infrastructure — like electricity. No one sells a toaster by saying it runs on electricity. The value is in what the toaster does. In AI, the value is shifting from the model to the outcome. And that shift lands squarely on the product manager’s desk.

Here’s the truth: AI commoditization doesn’t make product managers obsolete. It makes them the most critical node in the value chain. Because someone has to define what “good” looks like, how to charge for it, and how to prove it happened. That someone is you.

But your old playbook — the PRD that lists features, the pricing that charges by usage, the acceptance criteria that checks for pass/fail — is useless. You need to rewrite three columns. Let me show you how.

Column 1: Deliverables — From Features to Outcomes

Your PRD has a section called “Functional Requirements.” You write things like: “User can click this button, system returns that data.” That’s the old world. In the agent world, the user doesn’t click buttons. The agent acts on their behalf.

Take the example from Manbang Group, a Chinese freight platform. They built an agent for truck drivers. Before, drivers would scroll through a list of loads and pick one manually. Now they tell the agent: “I want to go to Shanghai, need to earn at least $500, no empty return trips.” The agent does the rest. Usage jumped from 15% to 35%. Retention after first use: 71%.

What did the product manager deliver? Not a better scrolling interface. A result. The driver’s goal was achieved.

So the first thing to rewrite is the top of your PRD. Instead of listing features, start with a goal definition. Ask yourself three questions:

1. What is the exact outcome the user is entrusting to the agent? Not “intelligent Q&A,” but “resolve 80% of support issues without human transfer.”
2. What boundaries and permissions does the agent need? Can it issue refunds? Access inventory? When must it escalate?
3. What happens when it fails? Traditional software throws an error. Agents produce half-baked results. Design the fallback.

And then there’s the data. The Nile team, which builds e-commerce agent infrastructure, gave a killer insight: “The product information you write for humans is 300–400 times too sparse for agents. A human reads 30 characters. An agent can consume 100,000 characters.” You can’t feed an agent a typical product description. You need to expose structured data — parameters, edge cases, policies — written for machines, not people.

Your deliverable is no longer a feature. It’s a capability to achieve a defined outcome. If your PRD still starts with “The user can…,” you’re building the wrong thing.

Column 2: Pricing — From Usage to Outcomes, But Only If You Can Attribute

At the same WAIC, two CTOs publicly disagreed on pricing. Alibaba Cloud’s Li Feifei argued for pay-per-outcome: “Customers should pay for business results, not for compute tokens.” Tencent Cloud’s Wu Yunsheng pushed back: “We generally don’t charge by task because tasks are too hard to define precisely.”

They’re both right. The debate reveals the core tension: outcome-based pricing is the Holy Grail, but attribution is the gatekeeper.

You can only charge by outcome if you can attribute the outcome to your agent. The Nile team does this for e-commerce: they charge a pure CPS (cost per sale) — they only get paid when a sale is made. Zero risk for the merchant. Zero uninstall rate. Why does it work? Because in e-commerce, a sale is a clean, attributable event. The order came from the agent’s channel. No ambiguity.

But my customer service bot? Attribution was a nightmare. Did the bot solve the problem, or did the user figure it out on their own? Did it save labor, or was demand just low? When outcomes are fuzzy, outcome-based pricing is a pipe dream.

So the second column to rewrite is your pricing model. But don’t just jump to “pay per outcome.” First, assess attributability. If your agent’s output is cleanly measurable (e.g., a completed transaction, a ticket resolved without escalation), go for outcome-based. If not, start with a hybrid: usage-based pricing with an effect guarantee or a success fee overlay. And build the data infrastructure to track attribution from day one. Attribution is the new currency. Without it, your pricing is just a guess.

Column 3: Acceptance Criteria — From Pass/Fail to Attribution Clarity

Traditional acceptance testing is binary: does the button click? Does the API return? For agents, that’s meaningless. The same input can produce different outputs. You need to test three things:

1. Capability boundary. Where is the agent reliable? Build a test set of real-world, messy, edge-case queries. Measure accuracy and stability. Define the operating envelope.
2. Failure behavior. When it exceeds its boundary, does it hallucinate or gracefully hand off? This is a safety issue. A wrong answer is worse than no answer.
3. Attribution. Can you prove the agent caused the outcome? The Nile team built an attribution dashboard that traces every step from intent to click to sale. They even exclude ambiguous conversions. “If we can’t attribute it rigorously, we don’t count it,” their founder said.

Your acceptance criteria should now include a section called “Value Attribution Design.” How many tasks did the agent handle independently? How many escalations were avoided? Turn that into numbers. Acceptance is no longer about proving the feature works. It’s about proving the value is real.

Gartner predicts that nearly 40% of agent projects will fail due to governance and safety issues. I’d argue the real cause is that product managers didn’t define the boundaries, failure modes, and attribution models upfront. They built a black box and hoped it would work. It didn’t.

The New Job Description

Model commoditization is the best thing that could happen to product managers. When models were the star, PMs were just packaging. Now the star is the outcome — and only the PM can define, price, and verify that outcome. You are the person who turns the infinite ocean of model capability into a finite, sellable cup of water.

So next time your boss asks “How much does this save us?” don’t make up a number. Instead, ask three questions: What outcome are we delivering? How do we attribute it? How do we verify it? Answer those, and you’ll have a product that can be priced, sold, and trusted.

The boomerang won’t hit you again. You’ll be the one throwing it.