The Impact of AI on Product Management
AI is already coming for software engineering. It's coming for design. And it'll come for product management, too. In fact, it already has. It can write tickets, generate prototypes, write PRDs, prioritizing backlogs, getting better at making decks. If product management is mostly writing documents, pushing delivery forward, then yes, that job is going away—has gone away. But I don't think that was ever really the core job. Like, AI is forcing product management back into doing what it should have been doing all along: understanding, shaping, and improving the conversation between a company and its market.
Managing the Conversation
The product is where that exchange happens. The company makes a claim. The customer responds with their behavior. The company learns from that behavior, and the product changes—or it should. That's the loop. So if the product is the mechanism of conversation between the company and its customers, then product management is the management of that conversation. That's it. That's all it could be. You know, not controlling it, not forcing it, not manipulating it in a cheap sense. Listening to it. Clarifying it. Improving it. Just, you know, managing it. Making sure both sides are exchanging something real. This is why I don't think the job of the PM is to deliver customer value; that's way too one-sided. And it's also not to drive business value; it's also one-sided. The PM's job is to manage the exchange so that customer value and company value reinforce each other.
Product Discovery and Outcomes
So product discovery is not just getting out of the building and talking to users. It's not just research. It's not just ideation. It's not just figuring out what to build. Product discovery is figuring out how to make the conversation between your company and customers more valuable to the customer, more valuable to your company. And this creates a practical question: How do we know what kind of value we're trying to create? How do we know the product is actually improving the exchange? How do we know the conversation is getting better? That's where outcomes come into play. There are three types of outcomes that matter: user outcomes, business outcomes, and product outcomes.
User Outcomes
These are meaningful improvements in the user's own reality. Something about their life, work, control, decision-making, ability to act, or ability to accomplish something... it just got better. That's a user outcome. Customers can solve problems without needing to contact support. Customers can buy something the moment they decide they want it. Customers can complete a recurring task with less friction or less wasted effort. Customers feel more confident that the product will work exactly how they think it will. Customers understand what's happening, what to do next, and why. Those are all user outcomes because they describe an important improvement in your user's world.
Business Outcomes
These are the durable improvements in the condition of your business. Company, your organization, your group, whatever. They matter because they define what your org needs to become true. Higher revenue, lower cost to serve, better retention, reduced operational risk, faster speed to market, greater customer loyalty, stronger competitive position, improved margin, successful expansion into a new market, higher repeat purchase revenue from middle-aged men in that new market. Business outcomes. They describe the business getting healthier, stronger, faster, more resilient, in a better strategic position, more profitable.
Product Outcomes
They're really interesting. Product outcomes are the measurable changes in user or system behavior that drive user outcomes in a way that also satisfy business outcomes. I know it's a mouthful, but it matters because product outcomes, they're the bridge between the business outcomes and the user outcomes. That's where we are focused. Business outcomes are usually too far away from day-to-day product decisions. And user outcomes are often too broad to manage directly. But product outcomes, they give us something concrete that we can shape. It's the behavior change that shows how the product is turning user value into business value.
Examples of Product Outcomes
So if the business wants to lower customer support costs, and the user wants to solve their problems with less friction. The product outcome might be higher self-service resolution. If the business wants more repeat purchases, and the user wants to buy something the moment they decide they want it. So your product outcome might be something like more returning customers move from purchase intent to completing that repeat purchase in the same session.
This is the part where product management really becomes real. Because once you define the product outcome, you're no longer saying things like, "we need to improve the experience," or "we just need to launch this feature," or "we need to increase engagement." But instead you're saying, "these are the specific behaviors that need to change to satisfy both the user side of the conversation and the company side of the conversation." Those are product outcomes. They're measurable. They're behavioral. They sit in between the user and the business. They tell you whether the conversation is moving in the right direction. In the direction that we want it to move. I mean, we're managing the conversation, right? Where do we want it to go? Is it going that way or not? And if not, doesn't matter what we did. "Oh, we tried, oh! We finished the sprint on time, oh! We squashed this many bugs, oh! Sprint velocity went up by this many story points, ooooooh!" Lame.
The Problem with Lagging Indicators
There's another problem though. There's a problem that I haven't talked about. I kind of hid it. I didn't hide it. It's just, you know, product outcomes take time. That's it. They lag. Lagging, lollygagging. Right, they take time to manifest to show, to reveal themselves. It's a thing. I mean, business outcomes, they take even more time. Cost reduction takes time, right, retention takes time, revenue takes time. Like, hopefully you get them at the end of a quarter. But yeah, final results are slow. And if we only measure the final result, you know, it's too slow. The team might have moved on. Code may be expensive to change. Less so nowadays though, right? But the stakeholders may have already, you know, declared victory because the feature shipped. So everyone's like, why are we still working on this? "Oh, that feature shipped three months ago. Why are we touching that again?" Teams moved on.
The Value of Leading Indicators
Which is why leading indicators to those product outcomes, that's our jam. I mean, product outcomes are our jam, but like, leading indicators to those product outcomes, ooh. Those are the weeds that we get into. They tell us whether the conditions for the desired product outcome are getting better. Are they moving in the right direction?
If our product outcome is repeat usage of a particular behavior, the leading indicators might be more users reaching that first moment of value. Faster second use. Stronger week one return rates. And if our product outcome that we care about is fewer support escalations, leading indicators might be more self-service resolution. Fewer dead ends in help flows. Fewer repeat attempts on the same task. Fewer users bouncing between support articles before finding the right answer.
And that last one matters. When someone tries to solve a problem and they fail, and they try again and they fail again, and they go to, you know, your support articles and they navigate to say three, four, five different articles, can't find what they're looking for so they call up, right? That escalation, that did not come from nowhere. Right, there are signals, behavioral signals leading to that escalation. Those behavioral signals, those are your leading indicators. Right, which way do you want those to go? Right, the conversation, the product conversation, it was already breaking before that final failure, before that escalation. Leading indicators help you see that break before it happens, right? But that's the whole point of leading indicators, right? It's not just to observe reality. They help us, they give us time to respond to reality before reality punches us in our face.
Conclusion
This is what I think product management really is. Not vibes, not decks, not "we launched it; therefore, party." We're not just building features, we're making claims through the product and users are answering with their behavior. Our job is to understand those answers. That's real work, it's really hard, but that's the work. That's the job.