There’s a new PM role in B2B, and OpenAI is hiring for it. I came across it in a job posting for Deployed Product Manager, Codex.

Here are the roles and responsibilities from the job description.

  • Act as the product lead inside strategic customer accounts, helping customers adopt and expand their use of OpenAI products.
  • Identify opportunities for deeper deployment, new integrations, and broader product usage across teams and workflows.
  • Build trusted relationships with technical stakeholders, engineering leaders, and executives, including representing product vision to C-level audiences.
  • Partner closely with Deployment Engineers and GTM teams to drive successful implementations and long-term account growth.
  • Translate customer needs and technical blockers into clear product feedback and execution paths for internal teams.
  • Work hands-on with integrations, MCPs, tooling, and lightweight technical workflows when needed to unblock an account.
  • Own lightweight PM work needed to support enterprise deployment, then hand off the right insights and opportunities to core product teams.

Read this list carefully, then ask yourself: Is this actually a new job?

The role is not new. The title is.

The title may be new, but the embedded nature of the role and the responsibilities are not.

In a pre-AI world, this work was done by a Technical Account Manager (TAM), a Strategic Customer Success Manager (CSM), a Solutions Architect, or a Field Solutions Engineer, or some combination of a “dedicated account team”, depending on which company you worked for.

Enterprise software vendors have been doing this for years. Salesforce has a Signature Success plan that assigns a named architect who knows the customer’s org, their configuration, their priorities. SAP has a MaxSuccess plan where senior teams are dedicated to large enterprise accounts for the duration of multi-year transformations. Service now’s Impact Squad comprises of a Customer Success Manager, Success Architect, Platform Architect, and a Support Account Manager, all dedicated to help a customer realize the full potential of the ServiceNow platform.

And this is not just for software. A good friend of mine is in a customer-facing role at a semiconductor company, and is dedicated to large consumer electronics giants based in South Korea.

The best enterprise vendors have been doing this for a long time, albeit with different titles.

The TAM relays feedback. The Deployed PM owns it.

The CSM and TAM own the relationship with technical and executive stakeholders, identify expansion opportunities, and help the customer derive value from their deployment. They are the post-sale, customer-facing technical and market authority. But there is something the Deployed Product Manager does that the TAM and CSM classically could not.

The traditional B2B PM role has largely been an upstream function doing discovery, prioritization, roadmap, delivery. The feedback loop from customers runs through sales, customer success, and support. Most customer feedback or insight that arrives has been summarized and filtered, and the raw anecdotal visceral annotations of what the customer actually said are lost.

The CSM and TAM have to continuously beat the drum on what their customer keeps wanting. The Product Manager is inundated with these type of requests from multiple customer-facing teams. The backlog just keeps growing. The loop looks like this:

Customer → CSM/TAM → PM → Roadmap

The Deployed PM collapses this loop. The loop becomes:

Customer → Deployed PM → Roadmap

The Deployed PM now has a direct stake in the success of the account.

Recruiting from a PM candidate pool also matters. A TAM saying, “I’ll take your feedback to the product team,” does not carry the same weight as a PM who can have a credible roadmap conversation with an engineering leader who is evaluating a six-figure expansion.

For the first time, a B2B PM owns adoption, not just delivery.

Most PMs do discovery in order to build. They talk to customers, identify problems, prioritize features, deliver, and then move on to the next thing to build.

Whether the customer actually changed how they work, whether they realized the value that the product promised, or expanded their usage, all that becomes someone else’s problem. Customer Success, Sales, Support carry that burden.

The Deployed Product Manager changes this. The onus of successful delivery now sits with the Product Manager. Discovery now continues inside the customer account, in the real conditions of actual use of the product, with the real organizational resistance and real friction to workflow or process or behavior change your product needs to succeed.

The Deployed Product Manager is not there only to help support the customer’s use of the product. They are to also shape what the product becomes, learnt from living inside the account.

The embedded nature of the role is not new. However, the product authority, accountability for outcomes, and the acceleration of the discover-learn-build loop that comes with it is new.

Adoption has always been the hard part.

We’ve seen this movie before. A capable product gets built. Deals get closed. Bells are rung in the hallways. And then adoption stalls. Not because the product is bad, but because changing how people work is not easy.

Customer Success wans to retain the account. Sales teams want the expansion. Neither has the product credibility to drive the behavior change the customer actually needs to make. The PM is back at the office, two layers removed, wondering why usage metrics are flat.

The Deployed Product Manager is a structural fix to this problem.

AI makes shipping fast. It doesn’t make customers agile.

AI compresses the build cycle dramatically. What used to take months to ship now takes weeks. But accelerating how fast code ships does not mean that customer adoption will follow.

The bottleneck has shifted. It is not building. It is adoption.

And adoption is a field problem, that is not solved by sprinting faster.

Even in the pre-AI days of Agile, this was true. Just because product teams were agile did not mean that the customer was agile. With AI, this gap is exponentially wider.

This signals a broader shift, and not limited to AI coding tools like Codex. Anywhere that build cycles are getting compressed, the bottleneck is moving from building to adoption. That means the PM’s leverage is also moving with it.

The bottleneck has moved. The PM role needs to move with it.

The Deployed Product Manager role is a signal worth paying attention to. It is not just as a new job title, but as a reflection of where product work may be heading.

This is a good question that every product leader should be asking.

When did your PMs last own the adoption outcome, not just the delivery?

When building gets faster and faster, and customers stay just as hard to change, the PM who only ships and moves on is leaving the most important part of the job on the floor.

The Deployed Product Manager makes this visible. It is now on a headcount plan.

B2B Product Leaders, is your team set up to own adoption, or just delivery?

What do you think? Share your thoughts on this post on LinkedIn.