I learnt an important lesson early in my career as a PM. I made a mistake which traveled five levels up the org chart in less than 24 hours. It resulted in the Chief Revenue Officer calling me and leaving an irate voicemail that said:

“Why don’t you first take some time to learn how your product is sold?”

He was right. I had joined a new company in the middle of a quarter. About a month in, the quarter ended and Finance released bookings and customer data. I was still finding my feet, learning the product, meeting the team, meeting customers, figuring things out. But I was curious and eager to dive into the bookings data, so I pulled the numbers for one of my products.

Something didn’t look right. When I compared the SKU pricing to the actual number of licenses and bookings in the deal data, it appeared that the product was being discounted by 90%. How could there be such deep discounting on almost every deal?

I wrote up my analysis and sent it to my manager, the Director of PM. He forwarded it to his boss, the SVP, who forwarded it to the CTO, who forwarded it to the President, who forwarded it to the ELT.

When I came into the office the next morning, the CRO had left that irate voicemail. Of course, he was right.

What Had I Missed?

My product had two distinct GTM motions. The first was a standalone SKU, sold on its own terms, at its own price. The second was as a component of a suite, a bundle of products sold under a single SKU. The bookings data I had analyzed was from the suite SKU. The product’s bookings were an allocated percentage of the suite deal. That allocation looked like a 90% discount when measured against standalone SKU pricing. It wasn’t a discount, but it was an accounting allocation.

I had no idea this structure existed. I had been learning about the product As Built, the features, the roadmap, the backlog, and had never asked how the product actually went into the market.

There Are Always Two Products. Always.

This experience shifted something in how I started thinking about the PM role since that time.

Most PMs learn to manage one product, the product As Built. What the product does, how it works, what gets built and delivered, and what we should build next.

But there are always two products to manage. The second one is the product As Sold - how it’s packaged, how the SKUs are set up, how deals are structured, what the sales motion looks like, how bookings get attributed, and what the business actually needs to take the product to market commercially.

After that phone call from the CRO, I started asking questions I had never asked before. The first thing I started doing whenever I got ownership of a product was to look at the pricing and packaging. Is it sold standalone, as part of a suite, or both? When it’s bundled, how does Finance allocate bookings? What percentage of our bookings is coming from each selling motion? What does the renewal of the standalone and the suite product look like?

These answers weren’t readily available. I had to go find them from Sales, from Finance and the teams that were closest to the customers.

What Changes When You Understand the Product “As Sold”

Once I understood the commercial structure, my thinking about the roadmap changed. The suite GTM motion meant that the primary job of the product in the suite was not to win new deals. The product was not the primary reason the customer bought the suite. The primary job was to protect renewals. That reframing was important. A feature gap that came up repeatedly in QBRs created a renewal risk.

The question stopped being “what new features should we build to get new customers?” and became “what does this product need so that we keep and grow the customers we have, so that this product wouldn’t be the reason the suite renewal is put at risk?” These are different questions and lead to different roadmaps.

I also started building a Proforma P&L each quarter. The official bookings allocation was a Finance decision that I couldn’t control. However, I could track the R&D spend knowing the headcount and loaded cost, as a percentage of allocated bookings. It was not necessarily perfect. But it gave me a financial view of the product As Sold that I could bring to my cross-functional team, so that we could manage the business of the product.

I wasn’t just the PM thinking about what to build and ship next in feature-land. I became the PM that had a view on the economics of the product, and that changed how people engaged with me.

The Gap Nobody Talks About

Product Managers are accountable for how their product performs in the market. But most PMs learn how to manage only one half of what drives that performance.

The product As Built is ours to own. However, the product As Sold - the GTM motion, the pricing and packaging, etc., gets distributed across Sales, Finance, Product Marketing, Customer Success. And most PMs often don’t have visibility into this.

This gap shows up in business reviews when a PM cannot explain why bookings moved the way they did, in roadmap discussions when a PM can’t connect prioritization decisions to commercial outcomes. It shows up when the CRO is upset and calls to say you don’t understand how your product is sold.

Looking back, I was fortunate. I was barely a month into the company when this happened. That early lesson shaped everything that followed - what questions to ask, what you go looking for, how you think about what it means to actually know your product. A lot of PMs get this education much later, if at all.

It’s important to understand both versions of your product, the one you build, and the one that goes to market. They’re never quite the same product. The gap between them is where Product Leaders are made.

The Gap Gets Wider in the Agentic Era

Everything I’ve described above applies to software products. In the agentic era, this gap gets wider, and the reason is important to understand.

Traditionally software has always been sold as a tool, as a means to achieve the outcomes the customer has always wanted. That’s the reason they bought the product because they have a job to be done. The product got them closer to the outcome, but the last mile was always on the customer. The customer bought a CRM or an ERP, and someone still had to do the gymnastics to ensure the outcomes were achieved. The customer bought a learning platform, someone still had to drive adoption and measure the impact. The outcome has always been downstream of the product, and it was always the customer’s responsibility to close the gap between the two. Professional Services exists precisely to bridge this gap.

In the agentic era, this is different. For the first time, what’s being sold is the outcome itself. It could be a completed workflow, a decision, a process that used to require five people that now requires one. The product is no longer a tool the customer uses to pursue the outcome. It is the thing that delivers the outcome itself directly.

That changes the commercial structure of the product. An AI agent As Built is a set of technical capabilities such as tool calls, context retrieval, task execution, handoffs, and so on. An AI agent As Sold is a business result. It’s no longer about number of seats. These are completely different things.

There is still a product As Built and a product As Sold. But in the agentic era, the consequences of a PM not understanding both are even higher.

What do you think? Join the conversation with this post on LinkedIn.