Skip to main content

PART I: THE NEW REALITY OF PRODUCT MANAGEMENT

Chapter 1: The AI Revolution in Product Management

You are sitting in a product review. The engineering team has just demoed a feature they built in two days using new AI coding assistants. It works, but it drifts from the original roadmap you spent three weeks getting approved. The sales team is asking if this new capability can be sold immediately. Your design lead is worried the UI patterns are inconsistent. Meanwhile, a competitor just launched a feature that makes your Q3 strategy obsolete. You feel the tension: the old way of managing product—rigorous planning, detailed specs, linear execution—is failing to keep pace with the reality of building software today. You are becoming the bottleneck.

The "Shipyard" Framework for Embracing Controlled Chaos

The core principle for navigating this era is to stop fighting chaos and start engineering for velocity. In high-growth, high-tech environments, chaos is not a symptom of failure; it is a byproduct of speed. If your organization feels perfectly calm, you are likely moving too slowly.

Vlad Loktev, a product leader at Airbnb, observed that chaos is often necessary to push an organization to think creatively and make leaps in product development. He describes a moment when Airbnb CEO Brian Chesky felt things were "too calm" despite numbers being up. Chesky forced a design sprint to be completed in 24 hours rather than four weeks. This artificial injection of chaos forced the team to abandon bureaucratic dependencies and rely on intuition.

This approach requires a mental shift. You must move from a "control" mindset to a "context" mindset. Geoff Charles at Ramp explicitly tells new hires that they signed an implicit contract where the company prioritizes velocity over almost everything else. This means things will be chaotic, features will ship that don't work perfectly, and products will change without full enablement. The trade-off is innovation.

Think of your product organization not as a factory, but as a shipyard in a storm. You cannot control the waves (the market changes and AI capabilities), but you can build a ship (your team and processes) designed to right itself when tipped. Elizabeth Stone at Netflix describes this as "Chaos Monkey" engineering—intentionally injecting failure to test resilience. In product management, you must build "thermal" teams—isolated units protected from the broader organizational bureaucracy—that can run fast and break rules to find the new path.

Practical Breakdown You must audit your current processes for "false stability." Are you spending weeks on roadmaps that change immediately? Are you holding back releases to ensure 100% certainty?

  • Embrace the mess. Accept that high-velocity environments will look messy from the outside.
  • Prioritize velocity over accuracy. You do not need high confidence on when specific features will launch; you need high velocity in shipping to learn.
  • Create "thermal" zones. Isolate specific teams to work on high-risk, high-reward AI projects without the burden of your standard compliance or planning cycles.

Action Checklist

  • Identify one project this week where you can cut the timeline by 75% by removing approval steps.
  • Tell your team explicitly: "We are prioritizing speed over perfection for this release."
  • Cancel one standing status meeting that does not result in a decision.

AI at the Core vs. AI at the Edge

Strategic positioning in the AI era comes down to a single question: Are you building an AI-native product, or are you bolting AI onto an existing workflow?

Jag Duggal at Nubank distinguishes between appending AI at the corners of a product versus building it at the heart. An AI-native mindset asks, "What would this product look like if these tools existed from the start?". This is the difference between adding a chatbot to a banking app and reimagining the banking experience where the AI is the banker.

Paul Adams at Intercom warns against simply having an "AI inbox team" that works in isolation. If you bolt AI on, you treat it as a feature. If you integrate it at the core, you treat it as a platform shift. Tomer Cohen at LinkedIn executed this by asking leaders to "let go of your roadmaps" and go back to the drawing board with the problem statement, asking how the solution changes now that AI exists.

Evidence from the Conversation Howie Liu at Airtable notes that every software product must be "refounded" because AI is a paradigm shift comparable to the move to mobile or cloud. He shifted Airtable from having an AI assistant in the sidebar to making the agent the default way of interacting with the app. The app becomes an artifact manipulated by the agent, rather than a static tool used by a human.

Practical Breakdown You need to categorize your current roadmap items. Are they "AI at the edge" (incremental improvements, summaries, chatbots) or "AI at the core" (rethinking the fundamental value delivery)?

  • Don't just add a chat interface. Look for where the work happens. Can AI do the work instead of just helping the user do it?.
  • Revisit the problem. Strip away your current solution. If you were solving this customer problem today with GPT-4, would you build a dashboard, or would you build an agent that emails the user the answer?.

Action Checklist

  • Select your top product feature. Write down how it would function if no user interface existed and the user could only interact via voice or text instructions.
  • Kill one "bolt-on" AI feature that adds complexity without changing the core workflow.

Why PMs Are Becoming the Bottleneck (and How to Fix It)

The cost of producing code is dropping to zero. As engineers use tools like Copilot and Cursor, their output velocity increases dramatically. Brian Balfour notes that product managers are becoming the new bottleneck because the system is no longer constrained by how fast you can type code, but by how fast you can decide what to build.

Traditionally, a PM defines a spec, hands it to engineering, and waits. Now, engineers can prototype and build faster than you can write a comprehensive PRD. If you stick to the old "hub and spoke" model where every decision must pass through you, you will slow the team down.

Evidence from the Conversation Mike Krieger at Anthropic observed that when 90% of code is written by AI, the bottlenecks shift upstream to decision-making and alignment. The merge queues get clogged, and the strategy cannot keep up with the execution speed. Tal Raviv advises PMs to "seek to not be needed, but be valuable". If you are the conduit for every piece of information, you are the failure point.

Practical Breakdown You must shift from being a gatekeeper to an accelerator.

  • Stop writing tickets. Geoff Charles at Ramp notes that his team never writes tickets; they provide vision and priority, pushing the breakdown of work to engineering.
  • Decentralize decision-making. Give your team the "why" and the constraints (value and viability), and let them figure out the "what" and "how".
  • Automate your own work. Use AI to generate specs, summarize feedback, and draft updates. If you aren't using the tools your engineers are using, you cannot empathize with their speed.

Action Checklist

  • Identify a decision you currently make that can be delegated to an engineer or designer. Delegate it tomorrow.
  • Stop attending one meeting where your role is just to pass information from one group to another.
  • Use an LLM to write the first draft of your next strategy document.

The Three Critical Skills for 2025: Curiosity, Humility, and Agency

To survive this transition, you must cultivate three specific traits: Curiosity, Humility, and Agency. These are no longer soft skills; they are survival mechanisms.

1. Relentless Curiosity Chris Miller at HubSpot identifies "relentless curiosity" as the number one trait for growth PMs. You must be obsessed with the problem and the technology. In an AI world, you cannot be a passive observer of tools. You must understand how the models work, what "context windows" are, and why a model might hallucinate. If you aren't curious about the mechanics, you cannot effectively productize them.

2. Humility Christian Idiodi emphasizes humility: recognizing what you do not know. The "expert" PM who knows exactly what to build is a liability when the technology changes weekly. You must be willing to learn from everyone—engineers, customers, and even the AI itself. Katie Dill at Stripe notes that humility is essential for collaboration; arrogant builders miss the nuances of user friction.

3. High Agency Shreyas Doshi defines high agency as finding a way to get what you want without waiting for conditions to be perfect. Kevin Weil at OpenAI looks for this above all else: people who don't wait for permission. In a chaotic, high-velocity environment, you cannot wait for a roadmap to be handed to you. You must define the path and execute.

Practical Breakdown

  • Curiosity: Schedule time to play with new models every week. Don't just read about them; build something.
  • Humility: Ask your engineers to teach you how they are using AI. Admit when you don't understand a technical constraint.
  • Agency: When blocked, do not report the blocker. Remove it. If you need data, query it yourself. If you need a design, prototype it yourself.

Action Checklist

  • Build a simple app or workflow using a new AI tool (e.g., Replit, Cursor) this weekend.
  • Ask "Why?" five times in your next problem-solving meeting to practice curiosity.
  • Identify one area where you are waiting for permission. Act on it today.

How to Identify and Solve "Sharp Problems"

In the noise of AI hype, it is easy to solve problems that don't matter. Oji Udezue argues you must focus on "sharp problems"—pain points that steal time, energy, and money from your customers.

A sharp problem is not just an annoyance; it is a blocker to the customer's livelihood or leisure. If you solve a sharp problem, customers will tolerate bugs and rough edges. If you solve a dull problem, even a perfect product will fail.

Evidence from the Conversation Jen Abel suggests a litmus test: Is the customer measuring or managing this problem today? If they aren't, it's not a priority. Oji Udezue provides a method to validate sharpness: draw the customer's current workflow and the workflow with your product. If the line isn't 2x or 3x shorter, the problem isn't sharp enough.

Practical Breakdown You need to be ruthless in validation.

  • Measure the pain. Ask customers, "How much are you spending to solve this right now?" If the answer is zero, move on.
  • Map the workflow. Visualize the steps the user takes. Your AI solution should delete steps, not just make them faster.
  • Ignore the "cool" factor. Just because AI can do something (e.g., summarize a meeting) doesn't mean it's a sharp problem for your specific user.

Action Checklist

  • Draw the "before and after" workflow for your current feature. Measure the reduction in steps.
  • Ask three customers what they are currently paying (in time or money) to solve the problem you are addressing.

Prompt Sets as the New PRDs

The Product Requirements Document (PRD) is changing. When the product is a model, the "requirements" are the behaviors you expect from the AI. Brendan Foody from Mercor states this clearly: "If the model is the product, then the eval is the product requirement document".

You cannot deterministically specify how an LLM should behave. You can only specify the ideal output for a given input. This means your "spec" becomes a dataset of prompts and expected responses (evals).

Evidence from the Conversation Karina Nguyen at OpenAI describes creating a "spec of the behavior of the model" which serves as the PRD. This involves creating a spreadsheet with tabs for current behavior, ideal behavior, and notes. It's about defining the boundaries of the model's personality and accuracy. Hamel Husain advises using LLMs to help organize these thoughts and create the codes for what you want to build.

Practical Breakdown Stop writing long prose documents about how the feature should work. Start building datasets.

  • Curate examples. Collect real user inputs and write the "perfect" AI response for them. This is your acceptance criteria.
  • Define failure. Explicitly write down what the AI should not do.
  • Iterate on the prompt. Your work is now "prompt engineering" at a strategic level—guiding the model to the right outcome through instructions and examples.

Action Checklist

  • Create a "Golden Dataset" for your AI feature: 20 rows of Input -> Ideal Output.
  • Replace your next feature spec with a system prompt and a set of test cases.

Why Prototyping with AI is Now Non-Negotiable

The era of abstract specification is over. You must show, not tell. With tools like v0, Replit, and Cursor, a product manager can generate a working prototype in minutes. Guillermo Rauch at Vercel notes that tools like v0 make you a "powerful generalist" capable of creating full-stack applications without deep coding knowledge.

Ben Horowitz famously said, "It doesn't matter if you write a good spec... What matters is that the product works". Today, the distance between an idea and a working product is shorter than ever. If you are writing a document to describe a UI, you are wasting time.

Evidence from the Conversation Amjad Masad at Replit sees CEOs building future concepts directly, unblocking themselves from engineering resources. Kevin Weil at OpenAI emphasizes that teams should move from designs to prototypes because static mocks don't capture the reality of AI interactions. Jiaona Zhang at Webflow discusses a shift to prototyping ideas immediately rather than waiting for design cycles.

Practical Breakdown You need to become a builder.

  • Learn the tools. Spend time with v0 for UI, Replit for logic, and Cursor for code editing.
  • Prototype to communicate. Instead of a Jira ticket saying "Add a button here," send a link to a working prototype with the button added.
  • Validate with reality. Put a working prototype in front of a user, not a Figma mock. AI products are non-deterministic; you can't feel the experience from a static image.

Action Checklist

  • Use an AI tool to build a functional prototype of an idea you have this week.
  • Present your next idea as a live demo, not a slide deck.