AI Engineer World's Fair 2025
Shipping something to someone always wins
Read the talk
Shipping something to someone always wins
A useful product starts a feedback loop before the big launch: give real people something viable, learn where it fails, and keep the next improvement easy to ship.
From a talk by Kenneth Auchenberg
How do you build a great product in the age of AI?
How do you build a great product when AI makes it easier to build almost anything? Kenneth Auchenberg approaches that question through his experience on the early VS Code team, which he left in 2019, and his subsequent work on Stripe’s developer platform. At the time of this talk, he was a partner at AlleyCorp, applying that product-building experience to early-stage investing.
A conference launch is a visible milestone, but it is a poor unit for thinking about product progress. What matters is how many times a team can try an improvement, put it in front of real users, and learn enough to make the next attempt better. Optimize for iterations with users, not the number of big launches. AI makes that principle more relevant by expanding the opportunities to build and revise.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keep every increment useful
Consider the question of how to build a car. One approach starts with wheels, adds a chassis, then an engine, and finally produces a functioning vehicle. Each step advances the construction project, but none of the intermediate steps gives the customer transportation. Until the end, there is no functioning product through which to learn whether those improvements solve the user’s problem.
The alternative starts with a skateboard, improves it into a scooter, then a bike, adds an engine, and eventually reaches a car. The important continuity is the user’s ability to get from A to B.
| Approach | Intermediate deliverable | When users can try transportation |
|---|---|---|
| Assemble components | Wheels, chassis, engine | At the completed car |
| Evolve a viable product | Skateboard, scooter, bike, powered transport | At every stage |
The intermediate products differ substantially, but each preserves the outcome that makes feedback possible. A continuously viable product gives every increment a chance to teach you something.
Auchenberg regards that continuity as vastly more valuable than reaching viability only at the end—an experiential judgment, rather than a measured multiplier. Real users are getting transported while the product evolves, so the team can learn from their experience instead of building in a vacuum. The practical design problem becomes how to make this product feedback loop as fast as possible.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Build the loop before locking in decisions
At Stripe, Auchenberg’s teams established a feedback loop before committing to major design choices or decisions that would be difficult to reverse. The loop had three requirements:
- Real users could see something.
- The team could get feedback from those users.
- The team could iterate and ship an improvement.
The first deliverable did not have to be the finished product. It had to make this sequence possible.
Auchenberg reports that Stripe’s goal was to complete this loop in less than a day, ideally faster. He says Patrick would push for hours. That is a process target: if the loop cannot run quickly, investigate what prevents users from seeing an improvement and the team from learning from it. Larger organizations make this harder because there is more complexity to manage. The distinction is being able to ship every day, not requiring a release every day.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Find reachable customers, then test the promise
A fast loop needs specific people at its other end. Personas and user research can help describe an audience, but they do not substitute for knowing someone’s name, having an email address, and being able to call. If the team knows only a persona, it still lacks the direct relationship needed to build with users.
Before proposing improvements, understand how those people solve the problem today. Seeing their existing workflow puts the team in their position and gives its hypotheses a basis in actual behavior. Once Auchenberg’s teams understood the problem and had people to work with, they articulated their hypotheses and wrote a PRFAQ—a press release and frequently asked questions document—or a launch blog post.
Writing the launch post early forces specificity. Can you explain what is being built to its intended audience? Can you describe its shape, communicate its value, and position it in terms users understand? For an API product, the team also drafted a rough API outline so customers could react to the proposed interface.
At Stripe, the team sent these documents to early users for feedback before building the product or making a prototype. The document itself gave the team something to ship and customers something concrete to respond to, establishing feedback from the beginning. In his 2025 tooling examples, Auchenberg names ChatGPT and Claude as drafting aids and Bolt as a prototyping option. Those newer tools can help produce the artifacts; the document-first feedback mechanism does not depend on them.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Explore the best product, then resolve its constraints
Early product exploration can become dominated by legal, compliance, or financial constraints. Auchenberg’s preferred sequence is to first design the best product, then work through the constraints required to deliver it. Starting with every restriction can narrow the product before the team has understood what would make it valuable.
This does not remove the conditions for production release: the product still needs to be financially viable and compliant. It separates responsibilities. Legal counterparts help explain legal risks; other specialists help the team understand their parts of the problem. Product builders remain responsible for judging and shaping the product, using that advice to make informed decisions.
Once there is a product shape to explore, prototyping should be accessible across roles. Where teams previously relied on paper prototypes, AI-assisted coding now makes it easier to try working versions of an idea. In the talk’s 2025 context, Auchenberg points to Bolt as a way for product leaders, engineers, and people focused on strategy to make something tangible quickly. The expectation to prototype no longer belongs only to people with a technical background.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make a few users successful
Once users have something to try, the quality of feedback matters as much as its speed. A dashboard can show activity without explaining what a customer struggled to do. In early Stripe prototypes, the team visited customers’ offices and shadowed developers integrating the APIs. Watching the integration work exposed difficulties that aggregate metrics alone could not explain.
When an office visit was impractical, the goal remained direct access and detailed understanding:
- Shared communication: Bring customers into Slack or Discord so questions and problems can reach the team quickly.
- Personal availability: Texting made some of Auchenberg’s strongest customer relationships immediate and accessible.
- API observation: Monitor API responses closely to see where customers get stuck, then work with those customers to understand the difficulty.
These channels supported intensive work with a small set of users, rather than shallow feedback from an indistinct audience.
Early product work, in this account, should feel like running a professional services firm. Auchenberg illustrates the focus as delivering a piece of functionality to five people. His diagnosis is that the greater early danger is building something that is not useful at all, rather than something useful to only a few people. Narrow attention gives the team a chance to make the product work exceptionally well for someone.
The same approach applied to VS Code. Auchenberg worked through direct messages and shadowed users to understand why a CSS token did not receive the right completion or why the JavaScript debugger failed. Those are specific failures in specific workflows. Making a few users successful required investigating them at that level of detail.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
An API commits your customers, too
The cost of changing a product depends on what customers have built around it. Moving a button is comparatively easy. Changing a shipped API or data structure can force customers to change their own systems. For platform products, this makes early feedback on interfaces and abstractions especially consequential.
Stripe’s focus on the discerning developer meant working with a small group capable of helping the team build a surprisingly good developer experience. A trusted customer group gives the team people with whom it can closely iterate on API design. Auchenberg illustrates the asymmetry with an API change that takes its provider an afternoon but could require a six-month migration for a customer. This is a hypothetical contrast, not a reported migration benchmark: the burden comes from the customer’s dependence on the provider’s APIs and data structures.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
AI accelerates the work without removing the loop
How does this apply specifically to AI? Referring to illustrations from an earlier conference talk, Auchenberg describes the engineering, product, and design tripod changing shape. Responsibilities that were more isolated are blurring as AI lets people across all three functions build and iterate together.
His position is that the underlying craft of product building remains the same. Whether a team uses AI to build or is building an AI product, it still needs to talk to users and maintain a feedback loop. AI can accelerate the activities inside that loop without replacing the need for it.
His toolkit includes ChatGPT, Bolt, and Cursor, alongside Listen Labs for customer research and Granola for meeting notes. These tools help with different parts of product work. A future agent might accelerate more of the cycle, but the job remains getting useful changes in front of people and learning from their responses.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Cheaper implementation raises the value of judgment
Auchenberg predicts that as the cost of writing code approaches zero, product management becomes more important. That is a directional prediction about implementation costs, not a measured cost result. If building becomes less of a bottleneck, deep customer knowledge and the ability to get feedback quickly become more consequential in deciding what deserves to be built.
The same applies to AI-native development that puts more emphasis on specifications than on code. Faster implementation does not supply the knowledge needed to write a useful specification. Knowing whom you are building for becomes more valuable when you can iterate faster. The tools need to support that understanding and the feedback loop around it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Turn product judgment into something people can use
From his investment perspective, Auchenberg connects these requirements to the AI-native founders he has written about. His proposed capabilities apply to product leaders as well as founders: taste, deep customer knowledge, high iteration velocity, distribution, and the ability to sell. Together, they describe more than the ability to produce software. They describe the ability to shape a useful product, reach its customers, and keep improving it—work that closely resembles product management.
Shipping still requires aligning many conditions. Auchenberg cites a post attributed to Michelle at OpenAI that describes shipping as a low-entropy state: there are many ways for a launch to be derailed and relatively few ways for everything to line up. Its challenge is direct: “The universe does not want you to ship, but you must do it anyway.” Product work includes finding that path while keeping the customer feedback loop intact.
In a heated product review, another abstract argument may leave the team exactly where it started. Shipping something to a real person creates evidence the discussion did not previously have. Return to the skateboard: identify the smallest viable product shape that someone can actually use, put it in their hands, and let their experience inform the next iteration.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
An AI builder for exploring websites, applications and prototypes.
An AI research platform named in the talk's customer-research toolkit.
The meeting-notes tool Auchenberg names in his product-building workflow.
Further reading
- Making sense of MVPArticle
Henrik Kniberg explains the skateboard-to-car metaphor and how early product increments generate customer feedback.
Historical developer survey covering development environments, including VS Code's leading position among respondents.
Read the complete timestamped transcript
- 0:00
[upbeat music] So I am here to talk about how building products is really about shipping something to someone always wins, and that's kind of been, been a fundamental product principle of mine.
- 0:24
Um, but really short background, I know the sign out there say, say Microsoft. That's a long time ago I was at Microsoft. But I was at Microsoft as part of the early VS Code team, building that, left in '19, we became the market leader.
- 0:36
Spent some time at Stripe running our developer platform or building a big part of our developer platform and everything we, we did for developers. These days, I'm a partner at AlleyCorp.
- 0:45
We're an early-stage venture fund in New York. And this talk is really about applying my product builder lens, uh, of, of, of, uh, of how I've been building products for the past many years.
- 0:55
And it's really about, like, how do we build great products in the context of AI? And as I was putting the, the, the, the talk together, I was trying to, like, what is my overarching product principle in how you build great products?
- 1:10
And it really sums down to this. It's really, uh, not about the number of big bangs you do when you're building a product. And I know, like, whether you're in a startup or you're, or you, you, you are in a big company, it's always about, like, you do the big ship at the big conference, and then the
- 1:25
product is out there. But the reality is that it's really about the number of iterations you crank at a problem and number of iterations that you get in when you're building, uh, uh, your product.
- 1:36
So i- in other words, it's all about, like, how you can enable rapid iterative loops and how you can get feedback from your real users and just get as many shots at the goal as possible.
- 1:47
And I definitely think this is just more relevant than ever in the age of AI. We had an AI engineer. We all talk about all the AI tools, et cetera.
- 1:54
But, but really, what does this mean in practice? What does it mean in practice to have a rapid iterative loop? And here I have an answer. It's really about skateboards.
- 2:04
And, like, please, please bear with me here and with this m- metaphor. It's really about, like, asking the question: What's the best way to build a car? And there's, like, two ways you can build a car.
- 2:20
The, the tired way is that you start out building the wheels, then you build the chassis, then you add the engine, and then you have a car.
- 2:28
But the reality is that if you do it this way, you don't have a viable product until the very end. You have no way to get feedback along the journey.
- 2:38
You don't know if what you're doing with the incremental improvements that you're landing actually works because you don't have a functioning product until the very end.
- 2:49
The, the wired way is that you build a skateboard, then you make it a, a scooter, then you make it a bike, then you add the engine, and then you have a car.
- 3:00
And it's really about, like, the way you should be building your products, and particularly in the world of AI, is that you need to have a continuously viable product that enables, in this particular case, a person to go from A to B and have a means of transport, and then you evolve the product from there.
- 3:16
And the key thing here when we think about feedback loop is that you have a continuous feedback loop, that every time you land, land an incremental change,
- 3:26
you have real users getting transported, and you're getting feedback from them. And really, like, my, my experience, like, a continuously viable solution is many, many orders of magnitude more valuable than a solution that only gives you a, a viable option in the end.
- 3:43
And the reason for this is, is that it gets you feedback along the way. You, you avoid building in a vacuum, but you have feedback all, all, all the way that when you're iterating, and you most likely end up building something that is more meaningful and more relevant for your users.
- 3:58
So in many ways, this talk, this short talk here is really about, like, the order feedback loop and how we can accelerate this product feedback loop to be as fast as possible.
- 4:08
And, you know, when I was at Stripe, when we were kicking off a, a new project, before we locked in any major considerations, design cons- decisions or really made, made, made trap door decisions, we made sure that there was a feedback loop in place.
- 4:21
And what did that boil down to? Three things. We had real users that could s- see something. We had a way to get feedback from them. We could iterate and ship an improvement.
- 4:31
And the goal was we could do this in less than a day, ideally faster. If you ask Patrick, he would say hours.
- 4:39
And, and really, like, the reality is that if you cannot run your loop in a day, your process is broken. You have a problem. You cannot get feedback fast enough.
- 4:50
And know-- I know this is easy to say, and this gets exponentially harder as you're in a bigger company, and you have a lot of complexity to manage, but this should be your goal.
- 4:58
And I'm not saying that you need to ship every day, but the key thing is that you need to be able to ship every day. You need to be able to get this feedback loop going as fast as possible.
- 5:10
And this might sound very basic, but you need to be very specific about the customers you're building your feature or your product for. And I know, like, we all have been running our personas.
- 5:19
We all have been, like, doing our, our, our UXR and user studies. And w- what I mean by being specific is that you should actually work with real people that you know, people that have a name, an email, somebody you can call.
- 5:33
And if you don't know any real people, but you only have your UXR persona, you have a problem as well because you need to get to know your users.
- 5:43
And the other thing is that you actually need to understand the real people you're working with, how they're solving the problem today. You need to be in their shoes to understand and build that empathy because it helps you navigate and actually build out hypotheses on how you're gonna solve it and make it better.
- 6:00
And what we did at Stripe is that once we understood the problem, we had real people building, uh, building width, we articulated our hypotheses, but we also wrote the PI for Q of the launch blog post.
- 6:12
And I do think this is one of the easiest steps to, to miss, and I think it's n- almost always a mistake not to sit down a- and write the launch blog post.
- 6:23
Because you writing the PI for Q or the press release or the blog post forces you to write something specific to your audience as to sanity check things. You can communicate the product, you understand what's being built, you know how to shape it, you know how to, like, position it to your users, and you know, w- when
- 6:41
there was an API, we put drafting the API. It'd be a rough outline, but we'd have an idea, and we would get in front of our users. Heck, it's twenty twenty-five, we can vibe code this.
- 6:49
We can ask ChatGPT or Claude to do it. But just going through this process was critical for us to selling the feedback. And when we were working with our ear- early users, we'd be sh-shipping this document to them, getting feedback before we even went out building.
- 7:04
Before we even were, uh, doing a prototype in Figma or Bolt these days. And this was how we ensured that from day one, we had a product feedback loop, and we had real feedback getting to us as we were building.
- 7:17
And another thing I learned over the years is that it's incredibly hard to do this, but you gotta design your best product before you start considering all the constraints like legal, compliance, financial, et cetera.
- 7:29
And what I mean by this is that it's, it's very easy to sit down and when you kick off a product to understand all the legal constraints, all the financials, but that's not how you build the best product.
- 7:39
Sure, like, by the day you ship in production, you need to have a product that's financially viable, compliant, ticks all the boxes, but you cannot let your legal counterparts be the ones that are dis-- applying judgment over your product.
- 7:54
The way I've been working with my counterparts and, uh, it's really about, like, they are here to help me understand the legal risks, but they are not the shaping the product.
- 8:04
And I really think it's just important that you think about, like, working with your various counterparts, you know what I'm saying? That they can help you understand the product space, but it's your job to, to actually make those calls.
- 8:17
And here in, in, in twenty twenty-five, like, the reality is that we can actually build in- an incredible amount of things. And I think back then we were doing paper prototypes, we were doing a lot of things, but today we can just vibe code iterations of, of the product shape.
- 8:33
And the reality is that you have really no excuse, whether you're a product leader or you are an engineer, you have no excuse not to do a prototype because it's gotten so easy to do.
- 8:46
And I, I just think this is important to internalize, regardless of whether you have a technical background, you're most focused on the strategy, you can go to Bolt and you can hack something together very, very fast.
- 8:58
And the, the other thing that we learned over the years is that the key thing that helped us navigate things was to get high quality feedback and high bandwidth feedback from our users.
- 9:06
And what I mean by this is, is that it's very easy to slap, slap on some metrics a- and build a dashboard, but it doesn't help you get, get a- any quality feedback that can help you understand how things are really going.
- 9:19
So in the early days, when we did a prototype of something, we'd go to the-- our customer's office, shadow them as they were integrating the APIs, and really get that visible feedback.
- 9:29
I know it's not possible we can always go to our customers', uh, offices, so get them into a Slack channel. Get them into Discord. The best customer relationships I've had is people I'm texting with.
- 9:39
I'm available, and I wanna learn how you're using your product.
- 9:43
And even when we were building our APIs, I would-- we would be monitoring rigorously the, the API responses and see where people, uh, got stuck. And we would really work with a very few set of users and make them extremely happy.
- 9:58
And I think that's probably the, the, the other thing is that I think, um, um, if you put this-- if you do this well, it should feel like you're running a professional services firm for your customers in the early days.
- 10:11
Like, you should really feel like I'm delivering this piece of functionality to these five people, and that's all I do. Because the reality is that most products fail, um, not because they're only useful for very few users, but because they're not useful at all, because you built the wrong thing.
- 10:28
So this is a, a, a thing that, that we learned early on as we were building out various products. And when I was building VS Code, I would be in people's DMs.
- 10:37
I would be understanding why people couldn't, uh, get the right completions for the CSS token or why the JavaScript debugger didn't work. I'd be over and shadowing people so we could make a few users very, very successful.
- 10:51
Um, and the other thing that I learned throughout the, the years is that, just a side note, APIs are much, much harder than UI. And what I mean by this is that once you have an API and a data structure out there and it's shipped, it's incredibly hard to change.
- 11:05
It's much, much easier to move, move a button around. And it's-- this just-- when you work on more platformy kind of things that has APIs and other abstractions, it really just puts emphasis on that you need to work with a small set of users that are discerning.
- 11:22
At Stripe, we always were, were talking about the discerning developer and how we could build a surprisingly great developer experience and make very, very few users happy to begin with.
- 11:32
And when you work with APIs, you need to have that trusted group of customers you're working with that you can iterate with. And it's just like, just for context, you know, once you have an API out there, it might be an afternoon for change for you, but it might be a six-month-long migration for your customer because they're
- 11:46
locked into your APIs and data structures. So this is something to think about as you're building platforms. So, so, Kenneth, how the heck does all this relate to AI?
- 11:55
We're at an AI conference. Um, I saw some nice illustrations from Cl- Claire Rue's talk, brilliant talk, and it's just to-- like, I think she had some really great illustrations here about, like, the reality is that EPD tripod is changing, right?
- 12:09
Like design, product engineering always been isolated functions. The reality is that they're all blurring together. We're all lifting various parts of our jobs here, whether you're a product leader, engineering leader, or design leader.
- 12:21
With AI, we're all building, we're all iterating, and we're all in, in this team together building products. So we're in this weird kind of reality where all our roles are kind of merging together.
- 12:32
But my hot take here is that I don't think anything is changing with AI when it comes to the craft of building products. What I've outlined here and the tactical things you ha- you gotta do, whether you're using AI or not and you're building an AI product, it's the same process.
- 12:47
You need to talk to users, get a feedback loop going. And the reality is that AI will accelerate all aspects of product building. All the things I just talked about, there's a lot of tools available, and we are only gonna get better tools.
- 13:00
And sure, I am using ChatGPT, Bold, Cursor, Listen, uh, Listen Labs for, for, for, for customer research in Granola to take all my meeting notes. These are the tools I'm, uh, we all are using to, to kinda help us be more productive.
- 13:13
But nothing has really changed when it comes to the product development cycle and you getting a very fast iter- iterative loop going. And sure, one day we'll have an agent that's gonna help accelerate this, but by the end of the day, it's the same job to be done.
- 13:27
Um, and I, I actually think, like, the product management aspect of building great products is just gonna be much more important as we m- as we are now in a world where the cost of writing code is going to zero.
- 13:43
The building piece here is no longer the critical thing. What's much more critical is that you have deep customer knowledge, and you know who you're building for, and you can get feedback as fast as possible.
- 13:56
And you need to leverage all the various tools to get these feedback loops going. But in a world where we talk about AI-native development and putting emphasis on the spec instead of code, I actually think that's gonna be a much more emphasis on knowing who you're building for because you can just iterate incredibly fast.
- 14:13
And, you know, I am now on the venture side of things, and I spend a lot of time thinking about early stage in investment and what the new kind of backable founders are and how they're building.
- 14:23
And I, I did, uh, this, this essay recently about what I call AI-native founders. And I think the traits also for product leaders is that the winners will be the founders who can build tastefully, understand customers deeply, and k- keep an incredibly high iteration velocity.
- 14:40
And breaking it down, it's really about taste. I know we're in, in SF, and it's o- overused kinda term these days. But taste, deep customer knowledge, iteration velocit- uh, velocity, you having distribution for your product, and you being able to sell.
- 14:55
To me, this sounds like a lot like product management, and this is just gonna be much more important going forward. Um, I pulled a, a, a tweet here for, for Michelle o- o- over at OpenAI.
- 15:08
I think she captured it so well. "Shipping is so hard because it's a low entropy state. There are millions ways your launch can get derailed, but only a handful ways that everyth- that you can line everything up in order to ship.
- 15:20
The universe does not want you to ship, but you must do it anyway." And I think that's our job, to build the right products, have a feedback loop with our customers, and find a way to ship.
- 15:32
So really, like, next time you're stuck in a discussion with your team, you're sitting in a heated product review, or you're just debating with your team, I'm trying to remind my teams when I was operating is that shipping something to someone always wins and solves a debate when you get real feedback from real people instead of you
- 15:52
being stuck in, in a high-level conversation. And the main takeaway I want to give you all from, from this talk is that, think about that skateboard. Think about how you can build the minimal viable product shape that you can iterate on with real users.
- 16:10
Thank you. [outro music]