Key Takeaways

  • Tara Seshan, product lead for ChatGPT Work and Codex at OpenAI, stopped writing long reasoning documents in favor of immediate functional prototyping.
  • Predictable markets reward theoretical planning, but fast-moving sectors break static roadmaps before the ink dries.
  • The product manager's primary job has centered on identifying the single core hypothesis that determines product success or failure.
  • Prolific execution beats academic rigor: build a prototype, test it directly on users, and feed observed behavior back into the next test cycle.

The Death of the Academic Strategy Memo

For years, tech companies taught product managers to write like graduate students. You wrote thirty-page strategy memos, mapped out quarterly milestones, and defended five-year roadmaps in review meetings before engineers wrote a single line of code.

Seshan discarded that playbook when building frontier AI tools at OpenAI. As she put it, “When a market is more static or a market is more slow moving, you have the chance to actually do some grand strategy work because it's more predictable or you can at least understand all the pieces.”

In fast spaces, that predictability vanishes. The underlying models improve every few months, user expectations shift weekly, and multi-quarter plans collapse under reality. Seshan noted the mental shift required on her team: “It was a real switch to go from rather than writing out some long reasoning doc, almost like a PhD thesis of what I think should be the plan for the next amount of time, instead it's like how do I get to something I can try out and test with users as fast as possible.”

Isolate the Eigenquestion and Ship the Test

Abandoning long strategy memos does not mean building without thinking. It means shifting your intellectual effort to a different part of the problem. Instead of planning a distant roadmap, you concentrate on isolating the single testable question that matters.

Seshan explained the standard: “What that means is the thinking you need to do is being as pointed as possible about what your core hypothesis is. And that hypothesis definition is the most important thing.”

You have to ask what single factor decides whether users keep or abandon the feature. Once you identify that specific variable, you build the fastest possible working prototype to test it in the wild.

“Like what is the thing that will determine whether your product works or doesn't work? How do you test that? How do you look at the results? And how do you feed that back into a loop of refining your hypothesis and running it again? That truly has always been the PM job,” Seshan said.

Theory produces debate; empirical tests produce data. If your team spends three weeks arguing about whether customers will use a feature, you have already lost. Build a rough version in forty-eight hours, give it to ten people, and let user actions settle the argument.

What to Do With This

Open the longest strategy or specification document your team is currently writing. Delete everything except the core hypothesis about user behavior, write down the one metric that proves whether that hypothesis is right or wrong, and build a rough prototype to test it with five users by Friday.