Why Design Matters: Lessons from Stripe, Lyft and Airbnb

and now Stripe. So I sat down with her to learn about how design played a role in their success and how you can build a culture of high quality design from the earliest days of your startup.

Katie, thank you for for having us today. Well, thanks for being here at Stripe, and thanks for having me on. So our audience is early founders, and I think you and I are very much aligned that we would love to see more great quality design in the world. Yeah.

So I am excited for them all to learn from you today about how to do that, what great design looks like, and how to bring that to their startups at the earliest stages. Maybe to start, why don't you tell us a little bit about your role here at Stripe and and a little bit how the design team operates here? So I lead the design organization, and what that means is that we have the product designers,.

researchers, content designers that work hand in hand with engineers, product managers, building the product. So for us, that's Stripe Billing. That's the checkout. That's pulling together all of the various products that show up in our dashboard or in our consumer interfaces.

But also a part of the design organization is the brand studio team that works on our advertisements, our events, our branding, the books we design at Stripe Press, and then lastly, the website team at Stripe. com.

Everybody watching this will probably be familiar with Stripe and Lyft and Airbnb and, you know, a number of other companies that you've worked at. And they're also known for having great design and a great user experience.

What is the role that you think design played in the success of those companies? It's really interesting if you think also, like, back to their early days. Right? So, like, Airbnb was creating a product that was, you know, pretty different at the time. Right? Very novel. Like, I'm gonna stay in somebody else's house. Like, I've never done that before.

I don't know. And so design was instrumental in making that something that people could identify with and gain confidence in, you know, the safety, security, and enjoyment of that experience. And so the founders did an incredible job bringing very thoughtful details to that experience, like how is this going to work? How is the money exchanged? How are they communicating?

How do we portray it on the Internet? And by doing that and really sweating over every one of those details, think they've made it more approachable for somebody to try something new. And I mean, you know, look at them now. That's just like, you know, grown in such wonderful ways, they're continuing to make design such an integral part of it. And that same thing for Stripe.

You know, Stripe, the founders, they were creating, you know, the early days of these products, it is, you know, also something new and different. Like, people were taking payments online, but they had never solved the problem in that way.

And, you know, these founders care a lot about every detail of the user experience, and they put that in to the early days of the work such that people could feel more confidence by seeing how much they cared about the details of, you know, just how the interface is portrayed.

That like, oh, maybe then you also are going to take very good care of my money and you're also going to take care of these other parts. It builds that confidence, builds that trust, and also makes the product more functional and easier to use. Yep. It's interesting from the outside. Bet a lot of people think of.

Airbnb as the UI that you interact with, Lyft, the app that you call a car, you know, Stripe, maybe the developer API or, you know, other tools that you have. And they don't think of the holistic experience of what goes on behind the scenes there. And I think one thing that all of those companies have in common is that you need incredibly high levels of trust.

More than like any other type of b two b software. Stripe, it's moving your money. With Lyft, you're getting in a stranger's car. With Airbnb, you're staying at a stranger's house. And if it didn't look trustworthy and the experience was not a well oiled machine that felt really friendly and approachable and trustworthy, I don't think those businesses would have worked. I don't know.

What do you think? I I absolutely.

agree that there is a huge part to that. I mean, you just think about the small details, and sometimes it's subconscious, right? It's like you see a typo and you're like, okay, that's like a little weird.

And then, you know, maybe, you know, something else is just like not really laid out correctly or that like you closed out that box and then you lost all your work and then you're like, oh gosh, how have to start again? You start to question, like, well, they haven't pulled that off right, if they haven't gotten that detail, what other detail aren't they getting right?

And I think people also have to consider, you you just pointed out that like these are companies that are reliant on that trust in that relationship. But if you think about just, like, competition in general, you are reliant on building that anyway. Right? Like, there's too many options out there.

Like, why would I work with the janky one when I can work with the one that's going to, you know, more reliably get it right both on the surface and and underneath. Yep. I'm curious, you know, in building these big companies and having design be so integral to what the companies do,.

how important is the role of the founder there? And, also, have you worked at companies where the founder did not care about design and sweat those details like you're talking about quite as much? Maybe they had another focus or, you know, another thing they're more interested in. And, like, how does that play out in in the role of the company too?

It definitely is a major component because it is part of the culture.

And so I think, hopefully, we can agree that design makes a difference in the value and the effectiveness of the product. Right? I mean, it's not hard to look around and see places where that example comes through. And so there, luckily, I think most would say like, yeah, we want to have a well designed product.

But if they are only thinking about it in terms of, well, it's going to move the numbers, then they're only going to do it when it moves the numbers. And there are plenty of times when you're making a design decision where you're not going to be able to prove it just yet. Maybe eventually, but not right off the bat.

What I think the, you know, founders that we're talking about here, right, like Brian Chesky and Joe and Nate and then, you know, the Collison brothers, is that it is so fundamental to how they think about building. And that they first and foremost care about who are the users, what do they need, how are they going to do it, and how do we build something with so much intention?

Like every detail, every part of that experience, how can we make sure that is meticulously thought about and executed on? And having that mindset and then hiring that mindset in every person that enters that company will end up creating this kind of X factor that is very different than the motivation of like, well, how is this thing going to move the numbers?

And so when you encounter one of those difficult decisions of like, is this thing worth it to do it or not? That, you know, you lean on the back of, like, well, our pride is telling us that we need to do it. How have you seen some of these companies build that culture from the earliest days.

to give the space and the permission.

to actually be able to go that extra mile and delight users and go above and beyond? Yeah. I think it is definitely something that, again, has to kind of come in in the early days in the culture and you have to instill it and you have to exemplify it, is showing that that is important and then, you know, having the courage to make those hard choices.

Like frankly, unfortunately, you know, the gravitational pull is to mediocrity. You know, there are, you know, I would imagine most companies on this planet want to do great work and they want to say that they will say they want product quality.

But what it really comes down to is those, like, micro decisions every day, and are you making the one that is, you know, actually moving the product into a better place, or are you letting it, like, slip back down to meh? And that courage, you know, is something that the founders can do and they can show that, right? It's just like, you know what? Actually, we're going to hold on this ship.

We're going to take another spin on it and we're going to ship it next week because it's important we get it right. And that, I think, is really hard to do. It can hurt the team. Like, but we've been working on it. You know, like, want to get it out. It's just like, yes. But it's more important that we get it right, and we're going to, you know, exemplify that.

How do you balance that with the ethos of ship early, ship often,.

you know, get it in front of users, get their feedback.

when you know it's not the best version that it could be. Yeah. And I I recognize that, you know, it's really just to say just like stop the ship and wait until it's like great. And that is just not a possibility, Especially, you know, when you're I absolutely understand the need for urgency at a startup, but also like, you know, even Stripe is a much larger organization.

Our users are dependent on what we are providing. And so like, yeah, we want to get that feature out. So I would say that, you know, it's never easy. There is no, like, right or, you know, black and white answer of, like, oh, you ship it when it's this or you ship it when it's that.

But I think it's best to always come back to, like, well, problem are we trying to solve and who are we trying to solve it for? And if this is going to hinder the user experience, if this is going to leave a mark, right, that, like, you know, potentially hinder that first impression that you might make, then that's serious enough that you do want to hold and wait.

But I think there's also attributes to moving fast and taking things down in maybe more bite sized ways. So we really leverage betas as a way of getting something out there and most importantly getting feedback.

Because if you're just like sitting there, like, crafting it all day long and taking your sweet time but never actually learning from folks, then you're you're not getting the product better.

and certainly you're leaving people waiting. How do you know when you've hit that bar? I mean, it seems like it's kind of a taste thing. But, like, in your own work, how do you know whether you should wait that extra week and, you know, do the extra stuff to go the extra mile maybe or whether it's actually hit the bar and you're ready to move on to the next thing?

I will say it is one of the hardest parts of the job where, you know, you're just like, oof, am I going to, you know, be a stick in the mud on this and ask for another iteration or not? And is it worth it? I think the ways to make that easier,.

but definitely not easy, is again, you know, going back to the users. Like, you know, what they think? How well is this solving their problem? You know, is it actually a net positive? Or, you know, is this not really actually moving the needle? Or is it maybe even, you know, having detrimental costs to it?

I think the other piece is that there is, you know, a number of things that you should think about, like almost like a checklist of things that you look for in product quality. Like a high quality product is highly functional, Right? First and foremost, it has to have utility. It has to serve a purpose and solve a problem for the user. Secondly, it has to be usable. Right?

So so you can imagine a chair, like, solves a problem. You can sit in it, but it's, like, extremely uncomfortable. Well, you know, that's not going to work out for you for very long. So usability is that second most important thing. And then third is craft and beauty. Obviously, and beauty is not, like, you know, a nice to have.

It's absolutely material to increasing the utility and usability of a product and also making it far more enjoyable, but there's no reason crafting something nicely if you can't actually sit in it, for example. And so if you use this kind of as a checklist as I look at this product, it's like, well, first and foremost, solving a problem.

If it's not, then you definitely should not let it go forward because what's the point? You're just adding cost to your maintenance later. And then the next pieces come along. And it seems like.

whether you value and to what level craft and beauty, like, it's there.

whether you make the choice to invest in it or not. Just sometimes it's not good. Yeah. I I honestly, I think a big, big, big part of, you know, design when we're talking about design is it's just intentionality. Right? It's just like, are you being thoughtful about how this thing is going to be perceived or not?

And if there's infinite options, why not choose the one that is most appealing and most easy to use and, you know, just like sparks a little joy? You know, we create software for people to run their businesses. And, you know, I think a lot of enterprise software out there doesn't put that first and foremost, which is fascinating given that those are human beings that work at those companies, right?

And like, why not bring, you know, the joy to the work for anybody? We do think about craft and beauty as definitely not a nice to have. It's must have. And, you know, thinking about those details, making sure that there is no defects that somebody might start to question whether or not the product is working overall and, you know, bringing a little bit more joy to the utility.

Yeah. Or founders maybe that don't consider themselves to have an eye for design or a design background or something like, how can they know what great design looks like? Yeah. I think part of it is going back to that kind of like a checklist and thinking, like, knowing what to look for. Yeah. I'm a pilot,.

and one of the things that my CFI taught me is that, you know, before you take off, you do what's called a preflight. And so you look at all the aspects of the plane, you follow a checklist to make sure that it's airworthy before, you know, you take off into the sky. And the checklist is a really great way of making sure you never miss a thing.

But the other aspect that my CFI has taught me is that you should be looking at it as if you know something is wrong with the plane. You're just trying to find it. And so that mindset is really helpful because it really requires you to take a different posture of that, like, there's something here I'm going to find. I'm not just going take it for granted.

And when you do that, when you think through, like, let's say you're about to launch an app for ordering coffee online and you're kind of going through and you yourself as the founder want to see whether or not the product is any good, and you start questioning every word, every pixel.

You know, it can be annoying for the team, but it is important that you do because when you start to question it, you wonder like, oh, yeah, it's a little weird that, you know, when I hit this button I end up here, but I have no context of where I just came from.

And like, actually, these words don't really communicate our brand, and actually, that's not really communicating what I'm supposed to do next. And so you start to think a little bit more about each of those details and observe, like, how is it making you feel? How is actually helping you along your way? And is it or is it not? And what are those gaps?

And, you know, that might not be taste, but it is certainly, you know, utility. And I think that's, like, obviously, again, a super important part. Developing taste, think, is also, you know, it's one of the harder things to develop, but you can certainly hone it and you can improve it.

One of the ways, of course, is to observe and, you know, see what do you like about the companies out there that you enjoy their products in. What seems to be working? You know, what are the details of it that are really nice? And just, like, taking note of that. And then of course you're going to hire well and, you know, listen to your people and, you know, observe.

That can certainly cultivate your taste too. It's interesting when you talk about that checklist. You know, I think one thing that technical founders are really good at is, like, finding the edge cases Mhmm. And, you know, finding all the ways that, like, the product or the code that they've written might fail and not work.

And it's really interesting to think about actually just applying that to the design side of things and trying to find those edge cases or the areas that it will break.

might be like a good way for them to think about it and to be able to level up their own design thinking and and paying attention to their own product. Yeah. Absolutely. I I think one of the hardest parts for any of us is stepping outside of our own viewpoint.

I mean, you're working on this thing, it's your baby, you think about it night and day, it is really hard to imagine, you know, to just like erase that what you know from your brain and experience it like somebody who doesn't see it every day. So obviously, you know, you can do a lot of the assessment yourself, but bringing users into it is really, really important. And, you know, it's never once.

It's not like, oh, we just did it at the, you know, we did user research in the beginning. It's ongoing. And, you know, work with the user, hear from them, have them talk out loud as they look at your product and recognize that, you know, they are operating with a very different context in mind and a lot less knowledge about the product. And what do they see?

And, you know, what does it make them feel like? What is their impression of who this brand is based on, you know, the colors or the way it's laid out or how it interacts? And and is it clear to them? What what happens next, and and how do I get there? Yep. You talked about hiring.

And I think one of the ways to get good at hiring is to see lots of candidates to to understand what good looks like. Mhmm. And it sounds like what you're saying is that one of the ways to get better at design is to see lots of good design, interact with it, and, like, see what good looks like, and then that can help you level up.

Are are there any other tips that you would have for people that are trying to level up their own design skills as a founder and Yeah. That they can bring to their company? We can learn a lot from observation. Pay attention to the products you don't like and why.

Pay attention to the products you do like. Certainly, you know, I recognize sometimes it's a little chicken and egg. It's like we want to get great designers, but without great design, they don't want to be here, you know.

So I think a big part of that too is, you know, getting out there in the community and also, you know, if you're trying to hire great designers to your team, like, help them understand what role they can have in the company. If you don't know how design works, don't presume to tell them how it works. Think about how you can learn from their ideas.

Design often does work differently than perhaps an engineering discipline. And so that is something that, you know, you as a founder can learn a little bit about by bringing folks on and maybe even just an advisory role to help you think about how you're going to hire or maybe even coach maybe a junior designer that's on your team.

And yes, I think just meeting people, learning from them, and seeing their examples is a really great way of cultivating that taste. Can you teach taste? I think you can make it better.

I think, you know, to be honest with you, in hiring, for example, I would certainly say that it is easier to teach somebody the tools or the domain and the, you know, the space that you work in than it is to teach taste. Yeah.

For example, if you see somebody's portfolio, it's like, oh, but like, you know, we're in the fintech space and this person's worked in fintech forever, but they don't exemplify great taste, I think that's dangerous. Because I think it would be not necessarily easy, but easier to help them learn your space.

Whereas taste, I think it's also like a passion for it, you know, that also can be difficult to teach because, you know, is their mindset there? Is it something that they, like, think about every day that they, you know, just want to make things more attractive, more actionable, more useful.

Like, you you want that, like, deeply in that individual if that's what their, you know, main job is at your company. Right. Let's talk about design and and your design process at Stripe. Tell us a little bit about your process and how that works. Yeah. I think first and foremost is actually even thinking about how we're organized and we work together.

We have a highly collaborative environment where designers, engineers, product managers, they work hand in hand. So like if you ask any designer on the team, like, what team are you on? They'd like, well, I'm on the connect team and I'm on the design team. So you're not like a service org that people just kind of reach out to like an agency to get work done and then kind of go back to your Yes.

Cave. Yeah. For a number of reasons. So number one, you know, all those functions that I talked about earlier are all a part of the design org because on purpose, we want all those teams working well together because we want the user experience to feel coherent.

So whether you see us on the billboard or the website and then into the product, that should feel like one coherent story that's building on itself. Yeah. So that's why we're all in one org. But of course, we don't want, you know, the designers to be just like popping in and out of projects and not having the context of the product, really the deep expertise, and also not the same goals in mind.

So they are embedded in the teams. They have the same shared goals as PMs and engineers, and they're working on these things together from start to finish. And that makes a big, big difference in how the work gets done. And so in terms of process, you'll not be surprised, but we of course always start with like, well, who is the user and what is their need?

And that's where, you know, all of these, you know, kind of ideas for new products and things come from is that we're often hearing from our users and they are very much like engaged in working with us and vice versa. And so we, you know, potentially learn about a need for a product. I just mentioned Connect. So this is our product for platform businesses and marketplaces.

And so it allows them to create essentially a relationship with other businesses so that they can help them grow their own business and even offer financial services. And so these organizations that worked with us, one of them was Lyft for early days, for example, they, you know, came upon this need. They wanted to pay out drivers, and so they built the product with us.

I can talk about another product that I'm super excited to show you, which is called Workbench. Similarly, like we worked with Slack and Notion on, you know, how to make that product better every day. And so we are doing prototyping and iterating, and they are giving us feedback almost on a weekly basis.

And that real, like, tight feedback cycle and iteration of the product really helps us kind of stay away from going down faulty assumptions and creating things that just won't work in real life. And this spectrum of users that we serve, and this is probably the case for most of your founders too, like, there's not going be one type of user, you know, that they're going to be interacting with.

And so to work with a range of users and have that iteration cycle really helps reveal things that you might otherwise never have thought about, And that really persists straight on into the execution and the shipping, and then we keep learning and iterating.

Because one thing that I think, you know, never ceases to surprise us is that, you know, you could design this perfect little product, and you get it out into the world, and then what do you know? Like, three months later, it's full of bugs and, you know, the interaction points with your next new product aren't great.

And so you really got to stay steadfast into learning about your product and seeing also how it continues.

And so we actually have this part of our process, and it's almost like a culture of using the product and doing walk the store exercises where people from, you know, honestly anywhere in the company, but especially, you know, in the product teams, engineers, product managers, designers, trying the product like a user would in the journey aspect, right?

Not just that moment in time where the product shows up, but thinking about it from, you know, how do I learn about it in an email? How do I oh, and then I go into the website. Oh, and then I go into the product. How does that feel? What are the moments where it doesn't make sense? Because, you know, the day it shipped for the first time, it may have been all perfect.

But over time, like, it starts to, you know, potentially erode with the creation of new things. So you got to continue.

to evolve it too. I think every founder has had that experience of.

trying to nail the product, launching it, focusing on other things, and then coming back and trying your product six months later and being like, oh my god. What has happened here? How did this happen? And, yeah, I mean, it's a it's kind of funny. One of the team members had given this analogy.

It's like when you're working on your house and you redid the dining room and so you added nice new molding and like little light plates and painted the walls. And now all of a sudden the dining room next to the kitchen looks horrific. And, you know, you have to think about how you're continuing to push and pull different parts of your product and never lose sight of how it fits across all of them.

How often do do that, walk the store with all your products? I mean, I bet you someone is doing it right now. It is it's just a it's a cultural norm. We have a program where it is, like, very organized and established. It's called our Essential Journeys.

And so what we did was we identified what are the, you know, top 17, you know, most important user flows that many of our users go through, you know, daily. And it's not a comprehensive list by any means, but we just needed something kind of digestible. And so there's 17 and we have DRIs and team members assigned that every quarter they review that experience.

They score it, they friction log it, so that's like kind of writing down your experience as you go, and noting where like, well, that felt weird, and this is kind of that preflight thing that I mentioned of like using a checklist to like, does this make sense or not? And noting that down, scoring it. We keep it on a scoreboard.

There's a little social pressure of like, let's get these things to green. And our scoring mechanism, it's nothing fancy. It's literally, it's just like red, orange, yellow, yellow, green, and green. And we pay careful attention to it. It's a company goal to get these things to green and keep them at green.

And so, you know, as I mentioned, like regressions can happen, so how do you stay steadfast on that, improve it quickly, get it back out there?

And so, it's definitely happening a part of that program, but I think what's super cool is when, you know, somebody from the, you know, sales team does a walk the store of the, you know, billing product and then sends their friction log to the billing team because those are those great moments of hearing what somebody thinks who's not living in it day after day and, like, see that, like, oh, that actually doesn't make as much sense as we thought for somebody who doesn't have the context.

I love that cultural norm of measuring these things and.

having effectively, like, leaderboards and calling it out publicly and making that visible to everybody. That's a really great way to emphasize this in the culture. Yeah, absolutely.

So we have several examples that I'd love to show you. Yeah, we'd love to check it out. Yeah. So one of the things that I think actually came out of the walk the store exercises that we do is that you get to experience the product firsthand, you really get to feel it. Like a prototype might not always show you how is it going to show up in the real world. So using it real world is very helpful.

And the other thing I didn't mention is that we have a bugs at email alias that anybody can send a bug to in the company and outside the company. Because of that, we can hear from various people in the company that have tried the product and seen an issue, and it's like, if you see something, say something, which is super helpful.

So one of the things that came out of that was that we have this product called Blink, which is our extremely fast way of checking out online. But what we also provide with it is a way to buy crypto really quickly. And so in this website here, it's a nice, easy tool where you can quickly buy crypto.

And what we found is that when you then proceed and somebody types in their email address, what was happening I'll tell you what the problem was because it's gone now, so I kept telling you. But you would type in your email address, and before you would stop typing in the email address, there would be an alert that it was Wasn't valid. Wasn't valid.

And that I'm sure, you know, maybe in the Figma file was like, great, we're going to do this and it's going be fine. But what you're like, actually it's different when you feel it, it's just like that's really annoying. You're yelling at the person before they even finished.

And so what we did was just, you know, we saw that issue that was a bug file, And so now as I type it in, it doesn't yell at me. And what's cool is even then I hit a space, right? The space is not needed, but it's just like a natural thing a human does that is not on purpose. It's not yelling at me. Now it will yell at me if I give it a second. So now it alerts me when it's appropriate, right?

It's just like a little bit delayed. And that microsecond, that matters. And so I'm super glad that was filed and taken care of. Another example that I think is going to be useful as a point of to how much design can really impact the bottom line is this great one about an email. So we had this one email that was trying to communicate to a user what to do with the product after they have signed up.

And as you could see, it's just like there's not a lot of hierarchy. It's not a real clear call to action, what to do. If you read it, you know, the words are just like not super clear. It's kind of a wall of text. It's easy to delete that and ignore it. Yes, exactly. And it's just like, what is the role of that versus something else? Yep.

So we redesigned it. And we thought about the words, of course. We thought about what happens after you hit this button. Is this button clearly communicating what happens? We certainly added more hierarchy, a little bit more visual interest, which also communicates better. And doing that increased product conversion by 20%.

from this email, which is pretty huge. And I can see why. There's a clear call to action. There's a headline that, you know, I can't read the sub paragraph there, but I can read that headline from here and it immediately gets my attention. Yes. Yes. Okay. So let's talk some product stuff.

So.

I'm so thrilled about this product that we launched this year that is called Workbench. And so we were hearing from the developers about some of the challenges they have with working with the integrations and continuing to maintain and grow, one of which was essentially breaking their flow state.

So they would be working in the Stripe dashboard, and then they would be going back to their code editor and a lot of switching of what do you call them? Contact switching. Or going to the docs and context switching, lots of tabs, etcetera. And we had a, you know, we've had a developer area, but that was kind of getting like a little too jam packed in a small space.

And so we wanted to create a tool that would make it a lot more powerful and easier for developers to use and stay in their flow state. And so with Workbench, it comes in here at the bottom of the product, and you can see, you can pull it up, you can change how much of it takes over the screen.

What it provides for you is basically, it's both like a microscope and a telescope of what's going on with your integration. And so you can debug it, you can prototype it, you can make changes, and all of that stuff is right there for you. So I can give you an example. So let's minimize this for a second.

And so let's say I'm in the dashboard, and maybe somebody in the company let me know that a user called and the invoice didn't work out, and so we got to debug it. Why didn't it? Why didn't they get charged? So we come over here, we go into invoices, and I take a look, and it's like, okay, here's the user. What happened here? What are the issues?

So you see here in Workbench, it's offering this little information to inspect. I could also see whether or not there were errors related to it, but it looks like not right now. But if I click on the inspector, I can come in here.

Now I can see the background of what is involved in this invoice, which is also helping my mental model of how the API is constructed, which then kind of fuels the developer's ability to go further with it and build potentially new innovations in top of that.

And so let's say, Okay, I want to learn about the customer, what's going on with them, what happened in the event, and I can go right into the API Explorer to then, you know, if I need to understand what's happening in the API and make changes. And so this is almost like a little coach for you to be able to see how this works, what's behind all of these various parameters.

And, you know, what you would normally be doing today would be going to docs, also reading about it, and it's just like, again, context switch, so that information is now here. I can make, oh, okay, that's what's wrong. It's their email is wrong. So I'm going to just get rid of that error. Let's do that. Let's run it. Okay, it's updating.

Let's get the code snippet so I can just bring that into my editor. It's right there in my language, which I could switch out. And now, if I go back to that spot there and see this user, it's already updated right into the dashboard.

So it's really kind of like lowering that hurdle between the dashboard experience and your editor and really being able to bring the power of the CLI right into the dashboard. And so we've gotten great feedback. And this is that example I told you about where we were working directly with Notion and Slack and iterating Yeah. In real time and hearing from them how to make that better. Yeah.

This is great. I I don't know that I've ever seen something like this before. That's great. And it seems like you came up with this from some first principles thinking.

It's like a web inspector, but specific to Stripe and for all the tools that you would need to manage and improve.

all of your Stripe integrations. That's super cool. It's really cool. And thank you for saying that. I think the team crushed it on this one. And, you know, one of the other things that I love about this is so check this out. So part of this process of working with users on it was that we created this forum, this community called Insiders.

And so we can, you know, continuously hear from developers about their experiences and learn from it. And so even recently, the designer on this work back in May posted about it, it's like, hey, here, we did this. What do you think? And you get the commentary right on it.

It's like, actually, this isn't working, and this is really And no matter what size the company is, that regular touch with users is so critical.

to actually make a product for users. Yep. I think one of the things that I take away from this conversation is how deeply integrated the entire company is with your users. And you've got founders talking to users and sharing that with everybody. Everybody's encouraged to be a user of the product and report feedback and things that they learn on a regular basis.

And, you've got forums like this that, help you connect really closely with your users. And I I think that probably clearly explains why Stripe builds such great well designed products. And so, you know, kudos to you for leading a lot of that. And, the other thing that stands out to me is pride.

It's very clear that you and the founders and everybody that works at Stripe takes a lot of pride in the products that you put out. And I think that that shows, and you hold that high bar for yourself. And I think that's a lesson that all founders can take away, the level of pride and the level of detail that you go to to make something incredibly great for your users.

So I've learned a lot about that today, so thank you. Well, that is all very, very nice to say. I appreciate that. And, yeah, honestly, I I I do think, like, the the Carlson brothers did such a fantastic job instilling that in the culture. It does move the needle. You know, design certainly does make, you know, business sense. But even if it didn't, they they would still do it. Yeah.

And I think that that that's that x factor. That's the thing that's gonna make, you know, hard decisions along the way possible Yep. And certainly worth it. Awesome. Well, thank you so much for for having us Yeah.

Of course. Thanks for having me.