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 and 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 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 Alicorp we are early stage venture fund in New York and this talk is really about applying my product build the 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 banks you do when you're building a product and I know like whether you're in a startup or you're you are in a big company it's always about like you do the big ship at the big conference and then the part is out there but the reality is that it's really about the number of iterations you crank out a problem and 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 had AI engineer we all talk about all the AI tools etc but but really what does this mean in practice what does it mean in practice to you 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 they're the tired ways that you start 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 that the wide way is that you build a skateboard then you make it as a scooter then you make it a bike and 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 loop is that you have a continuous feedback loop that every time you like it landed incremental change 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 viable option in the end and the reason for this is is that it gives you feedback along the way you you avoid building in a vacuum but your feedback or 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 the short talk 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 of a new project before we logged in any major considerations design decisions or really made maybe 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 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 now 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 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 your product for and I know like we all have been running our personas we all been like doing our UXR 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 UXR 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 and understand and build that empathy because it helps you navigate and actually build out hypotheses and how you're gonna solve it and make it better And what we did a stripe is that once we understood the problem we had real people building building building wealth we articulated our hypotheses but we also wrote the PIFQ 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 PIFQ or the press release of 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 when there was an API we put drafting the API it'd be a rough outline but we have an idea and we were in front of our users Heck it's 2025 we can bytecode this we can add chat GPT or Claude to do it but just going through this process was critical for us to selling the feedback And when we are working with our early users we push shipping this document to them getting feedback before we even went out building Before we were doing a prototype in Figma or Bolt 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 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 as financial viable compliant ticks all the boxes But you cannot let your legal counterparts be the ones that are this applying judgment over your product The way I've been working with my counterparts and it's really about like they are here to help me understand the legal risks But they are not the shaping the product and I really think it's just important that you think about like working with your various counterparts in 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 bytecode 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 bolt 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 a high quality feedback And high bandwidth feedback from our users and what I mean by this is that it's very easy to slap slap on some metrics and pull the dashboard But doesn't help you get 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 the our customers 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 API's I 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 put this if you do this well you 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 And not because they're only useful for very few users but because they're not useful at all Because you build 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 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 And the other thing that I learned throughout the years is that Just a side note APIs are much much harder than UI 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 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 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 for 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, so, Kenneth, how the heck does all this relate to AI?

We had an AI conference And I saw some nice illustrations from Claire Roux's 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 and 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 And you 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, Listen Labs for customer research in Granola To take all my meeting notes These are the tools we all are 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 It's 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 putting emphasis on the spec instead of code I actually think that'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 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 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 is really about taste I know we are 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 kept 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 a 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 the right 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 a 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 Thank you We'll see you next time.