Product leader at OpenAI tells us how AI is changing product management at the highest levels

I grew up in developer tools at places like Heroku, GitHub, and Vercel, which is a very specific flavor of product management. You're not just shipping features; you're building for people who immediately know when you've cut a corner. It's like being a chef cooking for chefs. The bar is high, and they will absolutely notice if your sauce is off.

Some of my favorite moments as a PM weren't traditional "PM work" at all. At GitHub, I rewrote parts of the documentation and even redesigned the site to mirror my DX principles approach. I've spent weekends refactoring my own website to shave off a couple of hundred milliseconds because the performance bothered me. I helped run a project called Papercuts, where we fixed hundreds of tiny annoyances, because those details add up to whether people love or tolerate your product.

That's kind of been the throughline for me. I don't think of PMs as just identifying gaps and filling them, or being the "CEO of your product." I think of it as getting uncomfortably close to the details. Close enough that you start to care about things that don't show up on a roadmap.

And now we're in this AI moment, which honestly feels a little like giving everyone a jetpack and hoping they don't fly into a tree.

I spend a lot of time vibe coding on nights and weekends, building scrappy little tools with AI agents. You can go from idea to working product in an afternoon, which is incredible. At the same time, the fundamentals matter more than ever. Understanding systems, tradeoffs, and how things actually work under the hood is what separates something that ships from something that lasts.

Otherwise, you end up with a graveyard of unfinished projects and mysterious bugs.

So my journey into this moment hasn't really been about changing how I work. It's been about doubling down on it. Staying close to the craft. And building things myself.

I don’t think of PMs as just identifying gaps and filling them, or being the “CEO of your product.” I think of it as getting uncomfortably close to the details.

Share This Quote on:

• Share on Twitter
• Share on LinkedIn
• Share on Facebook

Kathy KorevecOpens new window

Codex at OpenAI

You should also read

• AI in Product Lifecycle Management: Key Benefits & Trends

• AI in Product Operations: How AI Boosts Workflow Efficiency

• AI in Product Management: How AI Is Transforming the Field

Closing the distance between idea and validation

Up until very recently, I was leading product for a team at Google Labs called AIDA, which stood for AI Developer Assistance.

We were working pretty deep in the stack. Early coding models, training data for code that fed into Gemini, and then moving up the abstraction layer into products like Colab Composer and Jules. The shift was from "Can we generate code?" to "Can we actually help people build real software end-to-end?"

So the organization I led was very much a hybrid. Part research, part product, part “We’re going to ship something scrappy this week and see if anyone uses it.” Our users ranged from professional developers to people who had never written code before, which is a humbling audience because you have to serve both depth and accessibility simultaneously.

The delivery model reflected that. A lot of fast iteration, tight loops between model capability and product experience, and a willingness to throw things away if they didn’t stick. It’s less roadmap, more exploration with intent.

Now, I’m at OpenAI, working on Codex, which is kind of a full-circle moment. Codex started as a model, and now it’s evolving into an agent and an application layer inside ChatGPT that helps people actually get work done. Writing code, automating workflows, stitching systems together.

So in both cases, the throughline is the same. Building tools that close the distance between an idea and something running in the real world.

Why PMs should focus on prototype-driven product development

I stopped treating specs as the primary artifact of product work. It's a shift that I had already started, but AI accelerated it.

Early in my career, particularly at GitHub and Heroku, I realized how much momentum matters. Real usage matters. You learn more from something in production than you ever will from a perfectly written doc.

What AI has done is take that philosophy and compress it even further.

Now, instead of writing a long spec and debating it for a week, I’ll build a rough version of the product myself. Or vibe code a prototype in a day or two. Something you can click, break, and react to. That changes everything.

You go from “What do we think will happen?” to “What actually happens when you use this?” It collapses a lot of abstract debate into something concrete.

It also changes the role of the PM. You’re not just shaping ideas; you’re pressure testing them directly. You’re closer to the implementation, so you catch bad assumptions earlier.

The result is speed, of course. We ship faster, we kill ideas faster, and we refine good ones faster.

The most important change, though, is that our decisions are more honest.

Why downsides to AI are subtle, but important

But there are definitely downsides.

One is what I’d call "false velocity." You feel like you’re moving incredibly fast because you’re producing a lot. Code, prototypes, docs. But not all of it is actually good or usable. You can generate a lot of surface area without real depth.

Another issue is quality and trust. AI-generated code can be surprisingly good and confidently wrong at the same time. If you don’t understand what’s happening under the hood, you can end up shipping things that are fragile, insecure, or hard to maintain.

And then there’s a subtle one. It’s easier than ever to start things. It’s not necessarily easier to finish them well. We’re going to see a lot more half-built products, abandoned prototypes, and systems that kind of work until they don’t. I’ve built a few of those myself.

So the overall result is a bit of a paradox. We’re faster than ever at getting to something. We’re not automatically better at turning that into something that lasts.

Kathy's Thoughts

It’s easier than ever to start things. It’s not necessarily easier to finish them well. We’re going to see a lot more half-built products, abandoned prototypes, and systems that kind of work until they don’t. I’ve built a few of those myself.

Why four principles turn products from flash to trust

I want to share a bit more about trust because I think product leaders underestimate the risk of invisible, low-quality software.

AI makes it incredibly easy to build things. You can spin up tools, features, and even entire apps in a fraction of the time it used to take. That sounds like pure upside, but what you get as a result is a lot more software that kind of works.

Half-finished features, fragile systems, things that were built quickly and never hardened. They don’t fail loudly. They just degrade over time. They break in subtle ways, create confusion, or quietly erode trust.

The risk isn’t just technical debt in the traditional sense. It’s trust debt.

Here are four principles I've found helpful:

1. Make the system legible. Users should be able to understand what the AI is doing and why, at least at a high level. Not full technical transparency, but enough that it doesn’t feel like a black box making arbitrary decisions. That can be as simple as showing steps, surfacing assumptions, or letting users inspect what changed.
2. Design for correction. The system will be wrong sometimes. That’s a given. What matters is how easy it is for a user to step in, fix it, and move on. If correcting the system is painful, trust drops quickly. If it’s easy, people will keep using it even if it’s not perfect.
3. Build for consistency over flash. A lot of AI products optimize for the “wow” moment. One really impressive interaction. Trust comes from the opposite —the system doing the expected thing, over and over again, without surprises. Especially in developer tools, predictability matters more than magic.
4. Show restraint. Just because the system can do something doesn’t mean it should. If you over-automate or take too much control, users feel it. They lose a sense of agency. The best products give you leverage without taking you out of the loop.

Why AI can't handle product differentiation or end-to-end automation

Here are a couple of other places AI is falling short.

There’s a lot of talk about agents that can just take a task and run with it end-to-end. In practice, most of the systems I’ve seen still require a lot of supervision. You’re guiding, correcting, and re-prompting. It’s more like managing an eager intern than delegating to a fully independent teammate.

That’s still useful, but it’s different from the expectation.

And then there’s product differentiation.

A lot of AI features today feel similar. You can add a chat interface, generate some code, and summarize something. That’s table stakes now.

What’s been harder is turning those capabilities into something that feels uniquely valuable and deeply integrated into a workflow. Something that people would actually miss if you took it away.

I think that’s where a lot of products fall short.

Why human judgment remains essential in AI product decisions

PMs must ask themselves, “Where does AI actually have good taste? And where doesn't it?”

There are parts of product work where AI is incredibly useful for me now — anything that benefits from breadth, speed, or iteration, I’ll lean on it heavily. Early discovery, exploring solution spaces, drafting different approaches, and even generating rough UX directions or flows. It’s great at helping you get unstuck or see more options than you would on your own.

I also use it a lot for prototyping, as I mentioned. Being able to go from an idea to something interactive quickly has completely changed how I work.

And then there’s all the “in-between” work. Summarizing user feedback, pulling patterns from data, drafting docs. Things that used to take a lot of time and context switching.

Where I don’t rely on AI is where judgment really matters. Prioritization is a big one. AI can help you list options, but it doesn’t actually understand tradeoffs in your business, your team, or your constraints. It doesn’t feel the cost of being wrong.

Same with roadmap decisions. Those are about conviction, timing, and sometimes making a bet that doesn’t look rational in a spreadsheet.

UX is another interesting one. AI can generate a lot of UI quickly, but it doesn’t have taste. It doesn’t feel what’s frustrating or delightful over repeated use. Especially when building for developers, the difference between something that works and something that feels good is everything.

And then technical tradeoffs. AI can suggest architectures, but it doesn’t own the long-term consequences of those decisions. Your team does.

How AI disrupts traditional product assumptions

I think the biggest assumption I’ve had to let go of is that the ground you’re standing on is stable.

For a long time in product, you could assume a few things were relatively fixed. The interface, the workflow, even what the product is. You’d iterate within that. AI breaks that.

I think the biggest assumption I’ve had to let go of is that the ground you’re standing on is stable….You’re not just building on shifting ground. You’re constantly questioning whether the ground should exist at all.

Share This Quote on:

• Share on Twitter
• Share on LinkedIn
• Share on Facebook

Kathy KorevecOpens new window

Codex at OpenAI

The model improves, and suddenly, your product surface is wrong. A new interaction paradigm shows up, and what felt like a solid roadmap becomes irrelevant. Things you thought were constraints disappear, and new ones show up that you didn’t plan for.

So, you’re not just building on shifting ground. You’re constantly questioning whether the ground should exist at all. That’s been a big mindset shift for me.

The second assumption I’ve let go of is that the best products are the most well-defined. In the past, there was a premium on clarity early. Define the problem, define the solution, execute cleanly.

Now, a lot of the value comes from staying in exploration longer than feels comfortable. Letting the product be a little undefined while the underlying capabilities are still evolving.

And the last one is around where value lives. I used to think a lot of product value was in the interface. The UI, the flow, the pixels. Now, a lot of the value is in behavior. How the system responds, adapts, and collaborates. The interface is still important, especially for developers, but it’s no longer the center of gravity.

How AI is collapsing roles

Roles are collapsing. The boundaries between PM, engineer, and designer are getting a lot thinner.

With AI, you can prototype, write code, explore UX, and pressure test ideas much more directly. That means more people can operate across what used to be very distinct roles. And that changes the shape of the team.

You need fewer handoffs. More people who can take an idea and push it forward themselves, at least to a meaningful level of fidelity.

I’ve felt this pretty personally. I recently shifted back into being an IC PM, and it’s been incredibly fulfilling. I’m much closer to the work again. Building things, testing ideas, getting into the details. It reminds me that a lot of product judgment comes from actually making things, not just orchestrating them.

That doesn’t mean managers or specialization go away. You still need deep expertise, especially in areas like systems design or high-quality UX. But you also need more “full-stack product thinkers” who can move fluidly across the stack and use AI as leverage.

Why AI has changed user expectations

AI doesn’t just improve your product. It resets what users expect from all products. So, you’re not just competing with your direct competitors anymore. You’re competing with the best AI experience someone had anywhere that week.

I think I underestimated how fast that expectation shift would happen.

What that means in practice is that “good enough” windows are much shorter. Something can feel magical on Monday and outdated by Friday. If I’d known that, I would have optimized more for adaptability and less for polish.

Kathy's Thoughts

I think I underestimated how fast that expectation shift would happen…What that means in practice is that “good enough” windows are much shorter.

Why product leaders must view AI as a discipline shift

My advice is to treat this moment less like a tool shift and more like a discipline shift.

The most important skill right now is the ability to see clearly. AI generates a lot of output. Ideas, code, directions. The risk is that you start mistaking that output for truth. So as a product leader, your job is to stay grounded in what’s actually happening. What users are doing, where things break, and what holds up over time.

The second thing is to build what you depend on. If you’re working on AI products, you should be using them deeply. Not just in demos or reviews, but in your own workflows. You’ll feel the gaps immediately. Where things are slow, where they’re confusing, where they almost work but don’t quite. That kind of firsthand experience is hard to replace, and it changes the quality of your decisions.

The third is to get comfortable with tension. There’s a real pull right now between speed and quality, exploration and discipline, what’s possible and what’s actually useful. That tension isn’t something to resolve. It’s the work. The best teams I’ve seen don’t try to eliminate it. They navigate it intentionally. They move fast when they’re learning, and they slow down when something needs to be right.

And lastly, don’t let AI turn you into a manager of outputs. It’s very easy to sit back and orchestrate, to prompt, review, and move on. But the best product leaders right now are still very close to the craft. They build, they test, they fix things that bother them.

Because ultimately, the job hasn’t changed. You’re still responsible for making something that works, that people trust, and that fits into their lives. AI just changes how you get there.

Follow along

You can learn more from Kathy on her product craft blog or her personal site. Or follow her on X.

More expert interviews to come on The CPO Club!