Shipping something to someone always wins — Kenneth Auchenberg (ex. Stripe, VSCode)

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 a fundamental product principle of mine. Um, but really short background: I know the sign out there says Microsoft.

That's a long time ago I was at Microsoft, but I was at Microsoft as part of the early VSCode team. Building that left in '19, we became the market leader. I spent some time at Stripe running our developer platform, or building a big part of our developer platform, and everything we did for developers.

These days I'm a partner at Alley Corp, we're an early stage venture fund in New York. And this talk is really about applying my product builder lens of how I've been building products for the past many years. And it's really about, like, how do we build great products in the context of AI.

And as I was putting the talk together, I was trying to, like, what is my overarching product principle and how you build great products. And it really sums down to this: it's really 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 in a big company, it's always about, like, you do the big ship at the big conference and then the product is out there. But the reality is that it's really about the number of iterations you crank at a problem, and the number of iterations that you get in when you're building your product.

So 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. And I definitely think this is more relevant than ever in the age of AI.

We hear AI Engineer, we all talk about all the AI tools, etc. 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.

And, like, please, please bear with me here with this 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. 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.

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. 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.

The wired way is that you build a skateboard, then you make it a scooter, then you make it a bike, then you add the engine, and then you have a car. And it's really about, like, the way you should be building your products.

In particular, 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.

And the key thing here, when we think about feedback loops, is that you have a continuous feedback loop, that every time you land an incremental change, you have real users getting transported and you're getting feedback from them. And really, like, my experience, like, a continuously viable solution is many, many orders of magnitude more valuable than a solution that only gives you a viable option in the end.

And the reason for this is that it gives you feedback along the way. You avoid building in a vacuum, but you have feedback all the way that when you're iterating, and you most likely end up building something that's more meaningful and more relevant for your users.

So in many ways, this talk, this short talk here is really about, like, the older feedback loop and how we can accelerate this product feedback loop to be as fast as possible. And, you know, when I was at Stripe when we were kicking off a new project, before we locked in any major considerations, design decisions, or really made trapdoor decisions, we made sure that there was a feedback loop in place.

And what did that boil down to? Three things. We had real users that could see something, we had a way to get feedback from them, we could iterate and ship an improvement, and the goal was we could do this in less than a day, ideally faster.

If you ask Patrick, he would say hours. 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. And I know this is easy to say, and it 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.

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.

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've all been running our personas, we've all been, like, doing our UX/R and user studies.

And 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. And if you don't know any real people, but you only have your UX/R persona, you have a problem as well, because you need to get to know your users.

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 and how you're going to solve it and make it better.

And what we did at Stripe is that once we understood the problem, we had real people building with, we articulated our hypotheses, but we also wrote the PI for Q or the launch blog post. And I do think this is one of the easiest steps to miss.

And I think it's almost always a mistake not to sit down and write the launch blog post. 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.

If 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, when there was an API, we were 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 2025, we can vibe code this, we can ask ChatGPT or Claude to do it. But just going through this process was critical for us to sell in the feedback.

And when we were working with our early users, we were shipping this document to them, getting feedback before we even went out building. Before we even were doing a prototype in Figma or Bold these days. And this was how we made sure that from day one we had a product feedback loop and we had real feedback getting to us as we were building.

And another thing I learned over the years is that it's incredibly hard to do this, but you've got to design your best product before you start considering all the constraints like legal, compliance, financial, etc. And what I mean by this is that 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.

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 applying judgment over your product.

The way I've been working with my counterparts is really about, like, they are here to help me understand the legal risks, but they are not the shaping of the product. And I really think it's just important that you think about, like, working with your various counterparts and your organization, that they can help you understand the product space, but it's your job to actually make those calls.

And here in 2025, like, the reality is that we can actually build 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 the product shape.

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. And I just think this is important to internalize.

Regardless of whether you have a technical background, you're mostly focused on the strategy, you can go to Bold and you can hack something together very, very fast. And 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.

And what I mean by this is that it's very easy to slap on some metrics and build a dashboard, but that's going to help you get any quality feedback that can help you understand how things are really going.

So in the early days, when we did a prototype of something, we'd go to our customer's office, shadow them as they were integrating the APIs, and really get that visual feedback. I know it's not possible we can always go to our customers' 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. I'm available and I want to learn how you're using your product. And even when we were building our APIs, we would be monitoring rigorously the API responses and see where people got stuck.

And we would really work with a very few set of users and make them extremely happy. And I think that's probably the other thing is that I think

if you do this well, it should feel like you're running a professional services firm for your customers in the early days. 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, not because they're only useful for very few users, but because they're not useful at all. Because you built the wrong thing. So this is a thing 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, I would be understanding why people couldn't get theright completions for the CSS token or why the JavaScript debugger didn't work. I would be over and shadowing people so we could make a few users very, very successful.

And the other thing that I learned throughout 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.

It's much, much easier to move a button around. And 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.

At Stripe, we always 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. 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 change for you, but it might be a six-month-long migration for your customer because they're locked into your APIs and data structures.

So this is something to think about as you're building platforms. So, Kenneth, how the heck does all this relate to AI? We're at an AI conference. I saw some nice illustrations, some Claire Ruse talk, brilliant talk. And it's just, like, I think she had some really great illustrations here about, like, the reality is that EPD tripod is changing,right?

Like, design, product, engineering always been isolated functions. The reality is that they're all blowing together. We're all lifting various parts of our jobs here, whether you're a product leader, engineering leader, or design leader. With AI, we're all building, we're all iterating, and we're all in this team together building products.

So we're in this weird kind of reality where all our roles are kind of merging together. 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 in the tactical things you've got to do, whether you're using AI or not and you're building an AI product, it's the same process. 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're only going to get better tools. And sure, I am using ChatBD, Bold, Cursor, ListenLabs for customer research and Granola to take all my meeting notes.

These are the tools we're all using to kind of help us be more productive. But nothing has really changed when it comes to the product development cycle and you getting a very fast iterative loop going. And sure, one day we'll have an agent that's going to help accelerate this, but by the end of the day, it's the same job to be done.

And

I actually think, like, the product management aspect of building great products is just going to be much more important as we are now in a world where the cost of writing code is going to zero. 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. 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 put an emphasis on the spec instead of code, I actually think there's going to be a much more emphasis on knowing who you're building for, because you can just iterate incredibly fast.

And, you know, I am now on the venture side of things and I spent a lot of time thinking about early stage investment and what the new kind of bagable founders are and how they're building. And I did 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 keep an incredibly high iteration velocity. And breaking it down, it's really about taste. I know we're in SF and it's an overused kind of term these days.

But taste, deep customer knowledge, iteration velocity, you having distribution for your product, and you being able to sell. To me, this sounds like a lot like product management. And this is just going to be much more important going forward.

I pulled a tweet here from Michelle over at OpenAI. I think she captured it so well. Shipping is so hard because it's a low-entropy state. There are millions of ways your launch can get derailed, but only helpful ways that you can line everything up in order to ship.

The universe does not want you to ship, but you must do it anyway. And I think that's our job, to build theright products, have a feedback loop with our customers, and find a way to ship. 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 the debate when you get real feedback from real people instead of you being stuck in a high-level conversation.

And the main takeaway I want to give you all 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. Thank you.