Jason Lemkin explains how OpenAI split its tiny API team to launch ChatGPT Enterprise as a dedicated GTM org, then merged 500 people back together months later. The moves cut duplication and sped execution. His takeaway: design sales orgs around the product, not legacy structures, and use small focused teams to move fast in AI.
Chapters
So this next and last section is intentionally punchy. It's a rapid-fire set of the most common go-to-market mistakes that I see founders make or ask us about. Think of it as a practical checklist to help you avoid missteps and accelerate what's working. It was early 2023. OpenAI had hired me in to help build our ChatGPT Enterprise go-to-market team from scratch. Our early team at OpenAI of our sales and go-to-market team was less than 10 people. No SDRs, no SEs, no CSMs, no sales ops, rev ops, marketing enablement, and not even a working Salesforce instance. We had about 6 account directors and 1 technical success partner who, they were all on fire, but they were focused on selling the API. And we had the hypothesis that ChatGPT would have a distinct fire. And a distinct sales motion different from our API. So, we made a deliberate choice to build a dedicated go-to-market org from scratch. That approach gave us speed, clarity, and deep customer focus during a critical window, and it worked. OpenAI already had the fastest-growing consumer application in history, and then this brand-new team that we built, we believe, launched the fastest-growing enterprise application in history. But despite this success, we saw an opportunity to go even further by evolving our structure. So earlier this year, we basically collapsed both of these orgs. We took 500 people, most people who had only been at the company for a few months, and we brought them into one single unified go-to-market org. Everyone had new roles, new workflows, new managers, and every single person had to learn a new product. They had to learn the opposite product they weren't selling. This was a hard change, but ultimately it drove faster execution, less duplication, and most importantly, a better customer experience. The key lesson here is that old playbooks don't always apply in AI. You need to design around orgs and product, not around legacy structures. So an example here might be, let's say you're releasing a new AI product at your company. An old way of doing it probably would've been teach and enable everybody how to sell it, and then everyone kind of bolts it on. Maybe the new way to do this might be create a small dedicated tiger team to really go focused and launch that product. Move fast, be willing to make mistakes and bold, uncomfortable decisions, and they will pay off in the long run.
