Perspective · Essay
Product and commercialization are becoming one system
AI is making it faster to build products. That makes the system connecting product decisions, customer value, adoption, and commercial learning more important—not less.
For a long time, companies could treat Product and go-to-market as largely sequential activities.
Product decided what to build. Engineering built it. Product Marketing translated it. Sales took it to customers.
The handoffs were never quite that clean in practice, but the organizational model was understandable: make the product, then take the product to market.
AI is making that separation increasingly difficult to defend.
When the cost and time required to prototype, build, modify, and personalize products fall dramatically, producing more functionality stops being the primary constraint.
The harder questions move elsewhere.
Which customer problem is worth solving?
For whom?
What value does the customer actually perceive?
What should be standardized and what should adapt?
How should the product be packaged?
What makes someone adopt it rather than merely admire the demo?
What does the field learn that Product needs to know?
What does product behavior tell the commercial organization?
And when the evidence changes, how quickly can the entire system respond?
Those are not exclusively Product questions or GTM questions.
They are one system.
Shipping is not the finish line
Product organizations naturally concentrate on the point where something becomes usable.
But a product can ship successfully and still fail commercially.
Customers may not understand why they need it. Sales teams may not know which customers to prioritize. Packaging may obscure the value. The buying journey may introduce friction. The product may solve a real problem but fail to fit the customer's operating environment.
Conversely, GTM teams can become very good at selling around product limitations without creating the feedback necessary to change the underlying product.
Both conditions are symptoms of the same structural problem: the organization has separated product creation from value realization.
The more useful question is not:
"Did we ship?"
It is:
"Did we create a repeatable system that turns a customer problem into product value, adoption, learning, and business value?"
That changes what Product leadership means.
Start with the value architecture
Before roadmap and launch plan become separate artifacts, there should be a shared understanding of the value architecture.
Who has the problem?
How costly or consequential is it?
What behavior needs to change?
What part of the solution is product capability?
What part is workflow?
What part is implementation or organizational change?
How will the customer recognize value?
Who needs to understand that value internally and externally?
What evidence will tell us whether the thesis is correct?
Those questions should shape the product and the commercial motion together.
A useful simplified model is:
Customer problem → value proposition → product / solution → packaging → adoption motion → customer outcome → business outcome → learning → back into Product
The important part is the loop.
Commercialization is not the conveyor belt waiting at the end of Product.
It is one of Product's most important sensing systems.
The field is part of the product-learning system
Enterprise products make this especially obvious.
Sales, implementation, customer success, solution consultants, and other customer-facing teams encounter information Product cannot obtain from telemetry alone.
They hear why the customer hesitated.
They discover which capability actually changed the buying decision.
They see where the product collides with an existing workflow.
They learn that what the company calls a feature may be perceived by the customer as part of a larger solution.
They discover that a theoretically attractive segment is expensive to serve.
But organizations often capture this information poorly.
It lives in calls, CRM notes, decks, Slack messages, anecdotes, and individual relationships.
AI creates an opportunity to make this feedback system dramatically better.
That does not mean putting an LLM on top of the CRM and declaring the problem solved.
It means designing the information loop deliberately:
What signals matter?
Where do they originate?
How do we distinguish a recurring pattern from one loud customer?
What decisions can those signals influence?
What should be automated?
What still requires human interpretation?
How do we connect commercial evidence back to product priorities?
That is a Product problem, an information-system problem, and an organizational-design problem simultaneously.
AI makes the boundary even more porous
AI products introduce another complication: the experience itself may increasingly adapt to context.
Different customers may use the same underlying intelligence in very different workflows.
The product may involve models, tools, data, permissions, policies, human approvals, and integrations rather than a fixed set of screens.
Value therefore depends not only on whether the technology works but on whether it works inside the customer's system.
This makes discovery, implementation, adoption, and product development harder to separate.
Some of the most interesting AI Product roles are already moving toward this model. Product leaders work directly with customers, identify high-value workflows, help translate ambiguous business problems into product behavior, and then determine which customer-specific learning should become reusable product capability.
That is not simply "customer-facing Product."
It is a tighter product-to-market learning system.
Commercialization should influence what gets built
There is sometimes discomfort with allowing commercial considerations too close to Product strategy.
That concern is reasonable when "commercial" means chasing every deal or turning the roadmap into a collection of customer requests.
But commercialization discipline is not the same thing as sales-driven development.
It means understanding:
market attractiveness, customer value, willingness to adopt, cost to serve, competitive differentiation, packaging, implementation friction, and the economics of the solution
while deciding what deserves Product investment.
Those are Product questions.
A technically elegant product with weak value economics is not necessarily a good product.
Neither is a commercially attractive opportunity that requires unsustainable customization.
The leadership problem is making those tradeoffs visible.
The organization has to close the loop
The companies that benefit most from faster AI-enabled building will not necessarily be the companies that produce the most software.
They may be the companies that learn fastest across the entire system.
Customer signal reaches Product.
Product behavior reaches the field.
Commercial evidence influences investment.
Product changes improve adoption.
Adoption produces better evidence.
The loop gets faster and more precise.
That requires more than technology.
It requires shared metrics, decision rights, operating cadence, and leaders who can work across traditional functional boundaries without erasing the expertise of those functions.
Product still matters.
Product Marketing still matters.
Sales still matters.
Customer Success still matters.
Design and Engineering still matter.
But the seams between them become increasingly important design problems.
The emerging Product leader
As AI lowers the cost of producing many forms of output, Product leadership becomes less about managing the production of artifacts and more about managing a system of decisions.
What problem deserves investment?
What customer creates the strongest learning?
What evidence changes the roadmap?
What should become product versus service?
Where should the experience adapt?
What should be packaged together?
Where does adoption break?
What economic result justifies further investment?
Those questions cross Product and commercialization because the customer never experienced those functions separately in the first place.
The organization did.
The opportunity now is to design the organization around the value loop rather than the historical handoffs.