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

Channel: aiDotEngineer

Published at: 2025-07-28

YouTube video id: mHzJhXppwUA

Source: https://www.youtube.com/watch?v=mHzJhXppwUA

[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. Um really
short background I know the sign out
there says 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 spend 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
Alico we are early stage venture fund in
New York and this talk is really about
applying my product builder lens uh of
of 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 the the 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
you are 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 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 an 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 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 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 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. 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 land
land an 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 gets you feedback
along the way. You you avoid building in
a vacuum, but you have feedback all 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 here is
really about like the Oda feedback loop
and how we can accelerate this product
feedback back loop to be as fast as
possible. 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 decisions or
really made made trap door 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 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,
your product for. And I know like we all
been running our personas. We all been
like doing our our 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
hypothesis on 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 uh building with we
articulated our hypothesis, 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 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 FAQ or the
press release or the blog post forces
you to write something specific.
specific to your audience is 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 would drafting the API. It'd be
a rough outline, but we have an idea and
we would get in front of our users.
Heck, it's 2025. We can v code this. We
can ask at GPT or CL 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
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 immature 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 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 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 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 to actually make those
calls.
And here in in 2025, 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 bite code
iterations of 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 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
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 is that it's very easy to
slap slap on some metrics and build a
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 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. And I
think that's probably 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. 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 build the
wrong thing. 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. 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 would
be over and shadowing people so we could
make a few users very very successful.
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. What I mean by this is that
once you have an API and a data
structure out there and is shipped, it's
incredibly hard to change. 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. 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. 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 you're locked into
your APIs and data structures. So, this
is something to think about as you're
building platforms. So, so Kennet, how
the heck does all this relate to AI? We
had an AI conference. Um I saw some nice
illustrations from Clare Rules talk
brilliant talk and it's just true to
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 all building
we're all iterating and we all in this
team together building products
So we are 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 you got to do
whether you're using AI or not and
you're building AI product is 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
chatbold 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 we all are using
to 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 iter 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. Um, and
I I actually think like
the product management aspect of
building great products is just going to
be much more important as we 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 spend a lot
of time thinking about early stage in
investment and what the new kind of
bagable founders are and how they're
building. And I 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're in in SF and
it's a overused kind of term these days,
but taste, deep customer knowledge,
iteration veloc 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.
Um, I pulled a a tweet here for from
Michelle over at OpenAI. And I think she
capt. Shipping is so hard because it's a
low entropy state. There are millions
ways your launch can get derailed, but
only a helpful ways that every 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 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.
Thank you.