Is This Maximally Accelerated Approach

Nick Turley's Approach to Product Development at OpenAI

Nick Turley, head of ChatGPT at OpenAI, has developed a philosophy of urgency and pace that has become central to how OpenAI builds products. His approach centers on constantly questioning if work is moving at maximum speed, which has become embedded in OpenAI's culture.

The "Is It Maximally Accelerated" Framework

• Core question: "Why can't we do this now?" or "Why can't we do it tomorrow?"
• Used as a forcing function to understand what's truly critical path versus what can happen later
• Became so central to OpenAI's culture that it's now a Slack emoji (a pink Comic Sans emoji that says "is this maximally accelerated")
• Applied selectively and contextually - not appropriate for all situations

When to Apply Maximum Acceleration

• When you need to learn through real-world usage rather than theoretical planning

  • "This is a pattern with AI - you won't know what to polish until after you ship"
  • "The only way to find out what people like and what's valuable is to bring it into the external world"
  • Especially important when product capabilities are emergent rather than predictable

• When you need to collect real failure cases to improve models

  • Benchmarks become saturated, so you need real-world scenarios where your product isn't working
  • These real failures help articulate to ML teams what to improve

• When you're working with rapidly evolving technology

  • Models are constantly changing, revealing new capabilities
  • Shipping quickly helps you discover what's newly possible

When Not to Apply Maximum Acceleration

• Safety-critical processes

  • "One of the areas where we have an immense amount of process is safety"
  • High-stakes situations require rigorous processes
  • Need to prepare for exponential capability increases

• When you've already learned what needs polishing

  • "Shipping is just one point on the journey towards awesomeness"
  • Once you understand what people are doing, there's "no excuse not to polish your product"

Implementation Principles

• Set the "resting heartbeat" for your team

  • Establish a baseline pace that becomes the default operating rhythm
  • Make urgency part of the team culture rather than an exception

• Cut through blockers by reframing the question

  • Especially effective with people from larger companies used to slower processes
  • "If this was the most important thing and you wanted to truly maximally accelerate it, what would you do?"

• Balance speed with follow-through

  • "You better follow through" after shipping quickly
  • Velocity is a tool, especially early on, but not the end goal

• Separate product development velocity from safety processes

  • "It's been really important to separate out the product development velocity which has to be super high from... frontier models [where] there actually needs to be a rigorous process"

Real-World Examples

• ChatGPT went from decision to ship in just 10 days

  • "It was ten days from when we decided we were gonna ship to when we shipped"
  • Many features didn't make it in (like conversation history)
  • Enabled rapid learning and iteration based on real usage

• Model chooser UI was intentionally unpolished

  • "We get a lot of crap for the model chooser... it's this giant drop down in the product that is literally the anti-pattern of any good product"
  • Shipped raw to get feedback rather than waiting for polish
  • "Is it better to wait until you got a polished product or to ship out something raw even if it makes less sense and start learning?"