Product teams should optimize for the number of useful iterations with real users, rather than waiting for one large launch.
2
A continuously usable product, such as a skateboard that gradually becomes a car, creates feedback throughout development.
3
AI makes building and prototyping faster, which increases the value of customer knowledge, product judgment, and fast feedback loops.
Summary
Kenneth Auchenberg argues that product teams should ship something useful to a real person as quickly as possible, then repeat the cycle. He contrasts a car built from parts with a skateboard that becomes a scooter, bike, and car. Each version gives users a way to provide feedback before the team commits to the final shape. At Stripe, his teams aimed to put real users, a feedback method, and an improvement into one loop that could run in less than a day. He recommends naming specific users, understanding how they work today, writing a launch document early, prototyping before building, and using direct conversations rather than relying only on dashboards. AI speeds up code and prototype creation, but Auchenberg says the product work remains the same. As code becomes cheaper to produce, knowing the customer and deciding what to build become more important. His practical test is simple: when a team is stuck in debate, ship something to someone and use the response to move forward.
Product progress comes from repeated user feedback, not one large launch
Auchenberg says the important measure in product development is the number of iterations a team gets on a problem. A large launch at a conference does not tell the team whether the product works until the end. A rapid loop gives the team many chances to learn from real users and change direction. He says this is especially relevant with AI because teams have access to many building tools, but still need a practical way to turn those tools into useful product changes. The goal is to make feedback arrive quickly enough that the team is not building in isolation.
A skateboard gives users value before the final product exists
He uses a transportation metaphor to describe incremental product development. One approach builds the wheels, chassis, and engine before producing a car. That approach leaves the team without a usable product during development. The other approach starts with a skateboard, then evolves it into a scooter, a bike, and eventually a car. Each version lets a person travel from A to B. A continuously viable product lets users test every meaningful change, so the team receives feedback while it can still alter the product's direction.
A healthy product loop should be able to run within a day
At Stripe, Auchenberg's teams tried to establish a feedback loop before making major design decisions. The loop had three parts: real users could see something, the team had a way to get feedback, and the team could ship an improvement. Their goal was to do this in less than a day, and Patrick's preferred target was hours. Auchenberg does not say every team must ship every day. He says the team must be capable of shipping every day, because a slow loop prevents useful feedback from arriving soon enough.
Specific named users are more useful than abstract personas
Auchenberg recommends working with people the team can identify and contact directly. A useful early user has a name, an email address, and a phone number rather than existing only as a research persona. The team also needs to understand how that person solves the problem today. That knowledge gives the team empathy and helps it form a better hypothesis about what to change. At Stripe, the team wrote a product FAQ, launch blog post, or press release early. Sharing that document with users produced feedback before a prototype or full implementation existed.
Teams should shape the best product before applying organizational constraints
Auchenberg says product teams should first work out what the best product could be, then account for legal, compliance, and financial requirements before production. Legal and other partners can explain risks and constraints, but they should not make the product decisions for the team. The product leader or builder has to make those calls. He also argues that prototyping is now easy enough that product leaders and engineers have little excuse to skip it. They can use tools such as v0 to build a rough version quickly, even without a traditional technical background.
Direct observation produces better feedback than a metrics dashboard alone
When Auchenberg's teams prototyped something at Stripe, they visited customer offices and watched people integrate the APIs. When visits were not possible, they used Slack or Discord channels and built close relationships with customers. The teams also monitored API responses to see where users got stuck. In the early period, the team might focus on only a few users and work intensely to make them successful. Auchenberg says this can feel like running a professional services firm, but it reduces the chance of building a product that is not useful at all.
APIs require smaller, more trusted user groups because changes are expensive
Auchenberg says APIs are harder to change than user interfaces. Moving a button is relatively easy, while changing an API or data structure after release can force a customer into a long migration. A change that takes an afternoon for the provider might take six months for a customer. For that reason, platform teams should work closely with discerning users before committing to an API. At Stripe, the goal was to make a small group of developers very happy first and use that group to refine the developer experience.
AI speeds up product work without changing the basic craft
Auchenberg sees product, design, and engineering roles merging as AI lets more people build and iterate. He still believes the practical process is unchanged: talk to users, create a feedback loop, and improve the product. He mentions using ChatGPT, Claude, Cursor, Listen Labs, and Granola to help with coding, customer research, and meeting notes. These tools reduce the cost and time of building, but they do not decide who the product is for or whether the result is useful. As code gets cheaper, customer understanding and product judgment matter more.
Shipping resolves debates by replacing opinions with user response
Auchenberg's final test is to put a minimal product shape in front of real people. When a team is stuck in a product review or an internal debate, shipping something to someone creates evidence that discussion alone cannot provide. He connects this to a post by an OpenAI employee about shipping being difficult because there are many ways a launch can fail and few ways to get everything aligned. The team still has to find a way to release, learn from users, and keep iterating. His practical image is the skateboard, a small usable product that can improve over time.
"Shipping something to someone always wins and solves a debate when you get real feedback from real people instead of you being stuck in a high level conversation."15:35
Who should watch
You are leading an AI product and need a practical way to get user feedback before committing to a large build.
Your team spends weeks in design reviews or internal debates without putting a usable version in front of customers.
You are designing an API or platform where an early mistake could create a long migration for users.
