Why Design Matters: Lessons from Stripe, Lyft and Airbnb

Today on design review, we'll be doing something a little bit different. I'll be interviewing Katie Dill, Stripe's head of design. The gravitational pull is to mediocrity. It's never easy. There is no black and white answer of like, "Oh, you ship it when it's this," or "You ship it when it's that." It's best to always come back to like, "Well, what problem are we trying to solve, and who are we trying to solve it for?"

Katie has led design teams at some of the most successful companies in Silicon Valley like Lyft, 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 having us today.

"Well, thanks for being here at Stripe, and thanks for having me on. 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."

Yes! 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 a little bit about 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 and 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, stripe.com."

Everybody watching this will probably be familiar with Stripe, Lyft, and Airbnb, and a number of other companies that you've worked at. 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 back to their early days, right? So like Airbnb was creating a product that was pretty different at the time, right? Very novel, like, ‘I'm going to stay in somebody else's house,’ like, ‘I've never done that before.’ I don't know. 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.

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? By doing that and really sweating over every one of those details, I think they made it more approachable for somebody to try something new. Look at them now; they've just grown in such wonderful ways, and they're continuing to make design such an integral part of it.

And that same thing for Stripe, you know, the founders, when they were creating the early days of these products, it is also something new and different. No, people were taking payments online, but they had never solved the problem in that way. These founders care a lot about every detail of the user experience, and they put that into 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 builds confidence, builds trust, and also makes the product more functional and easier to use."

Yeah, it's interesting from the outside. I bet a lot of people think of Airbnb as the UI that you interact with, Lyft as the app that you call a car, Stripe maybe as the developer API, or other tools that you have, and they don't think of the holistic experience of what goes on behind the scenes there. 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 B2B software, at Stripe, it's moving your money, with Lyft you're getting a stranger's car, with Airbnb you're staying at a stranger's house. 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 absolutely agree that there's a huge part to that. I mean, if you just think about the small details and sometimes it's subconscious, right? Is it like you see a typo and you're like, ‘H okay, that's like a little weird,’ and then, you know, maybe 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, I have to start again.’ You start to question like, ‘Well, if they haven't pulled that off right, if they haven't gotten that detail, what other detail aren't they getting right?’

People also have to consider, you know, you just pointed out that these are companies that are reliant on that trust in that relationship. But if you think about just like competition in general, you are relying on building that anyway, right? Like I—there's too many options out there. Why would I work with the janky one when I can work with the one that's going to more reliably get it right both on the surface and underneath?"

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? How does that play out in the role of the company too?

"It definitely is a major component because it is part of the culture. 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. Luckily, I think most would say, ‘Yeah, we want to have a well-designed product,’ but if they are only thinking about it in terms of like, ‘Well, it's going to move the numbers,’ then they're only going to do it when it moves the numbers.

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 founders that we're talking about here, like Brian Chesky and Joe and Nate and the Cison brothers, is that it is so fundamental to how they think about building 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? Every detail, every part of that experience, how can we make sure that is meticulously thought about and executed on?

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?’ 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?

"I think it is definitely something that again has to kind of come in the early days in the culture. You have to instill it; you have to exemplify it, showing that that is important. Then, you know, having the courage to make those hard choices. Like, frankly, unfortunately, the gravitational pull is to mediocrity. There are, you know, I would imagine most companies on this planet want to do great work, and they want to say that they want product quality. But what it really comes down to is those micro decisions every day. Are you making the one that is actually moving the product into a better place, or are you letting it slip back down to meh?

That courage is something that the founders can do, and they can show that. 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. That I think is really hard to do. It can hurt the team like, ‘But we've been working on it, you know, we want to get it out!’ Just like, ‘Yes, but it’s more important that we get it right and we’re going to 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 recognize that, you know, it's really 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 that the need for urgency in a startup. But also, you know, even Stripe is a much larger organization; our users are dependent on what we are providing. So like, we want to get that feature out.

I would say that, you know, it's never easy. There is no like right or 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, what problem are we trying to solve? Who are we trying to solve it for?’ If this is going to hinder the user experience, if this is going to leave a mark, right? 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 crafting it all day long and taking your sweet time but never actually learning from folks, then 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 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, ‘Oh, am I going to 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 do they think? How well is this solving their problem? Is it actually a net positive or is this not really moving the needle or is it maybe even, you know, having detrimental costs to it?

I think the other piece is that there is a number of things that you should think about, like almost like a checklist of things that you look for in product quality. A high-quality product is highly functional. 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. So you can imagine a chair that 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, craft and beauty is not like, you know, nice to have; it's absolutely material to increasing the utility and usability of a product. There's no reason, you know, crafting something nicely if like you can't actually sit in it, for example. If you use this kind of as a checklist as I look at this product, as like, ‘Well, is it first and foremost solving a problem?’ You know, 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.

Then, you know, the next pieces come along, and it seems like, you know, whether you value and 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."

I honestly think a big, big part of, you know, design when we're talking about design is just intentionality. 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. 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 in 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 a must-have. Thinking about those details, making sure that there are no defects that somebody might start to question whether or not the product is working overall, and bringing a little bit more joy to the utility."

For founders maybe that don't consider themselves to have an eye for design or a design background or something, how can they know what great design looks like?

"I think part of it is going back to that kind of like checklist and thinking—like knowing what to look for. 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 pre-flight. So you look at all the aspects of the plane; you follow a checklist to make sure that it's airworthy before you take off into the sky.

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. That mindset is really helpful because it really requires you to take a different posture of that like there's something here, and I'm going to find it. I'm not just going to take it for granted.

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 if the product is any good, you start questioning every word, every pixel. 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. You start to think a little bit more about each of those details and observe like how is it making you feel? Is how is it actually helping you along your way, and is it or is it not, and what are those gaps?"

That might not be taste, but it is certainly utility. I think that's, like, obviously again a super important part. Developing taste I think is also, you know, 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, what do you like about the companies out there that you enjoy their products? What seems to be working? You know, what are the details of it that are really nice? Just like taking note of that. And then of course, you going to hire well and, you know, listen to your people and, you know, observe, and 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 finding the edge cases and, you know, finding all the ways that the product or the code that they've written might fail. 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 paying attention to their product.

"Absolutely! I think one of the hardest parts for any of us is stepping outside of our own viewpoint. I mean, if 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 erase 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. It's never once; it’s not like, ‘Oh, we just did user research in the beginning.’ It's ongoing. Work with the users; 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.

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

You talked about hiring, and I think one of the ways to get good at hiring is to see lots of candidates to understand what good looks like. 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 see what good looks like, and then that can help you level up. Are there any other tips that you would have for people that are trying to level up their own design skills as a founder?

"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, 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 in 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.

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. For example, if you see somebody's portfolio, it's like, ‘Oh, but 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? Do they, you know, just want to make things more attractive, more actionable, more useful? Like, you want that deep down in that individual if that's what their main job is in your company."

Let's talk about design and your design process at Stripe. Tell us a little bit about the 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, and product managers work hand in hand. So like if you ask any designer on the team, like, ‘What team are you on?’ They'd be like, ‘Well, I'm on the connect team, and I'm on the design team.’

You're not like a service that people just kind of reach out to like an agency to get work done and then kind of go back to your cave. Yes, for a number of reasons. 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. 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 start to finish. That makes a 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's the user and what is their need?" That's where, you know, all these kind of ideas for new products and things come from is that we're often hearing from our users, and they are very much engaged in working with us and vice versa.

So we potentially learn about a need for a product. I just mentioned Connect. This is our product for platform businesses and marketplaces, and 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. So these organizations that worked with us, one of them was Lyft in the 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, we worked with Slack and Notion on, you know, how to make that product better every day. We are doing prototyping and iterating, and they are giving us feedback almost on a weekly basis.

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

So to work with a range of users and have that iteration cycle really helps reveal things that you might not otherwise never have thought about and that really could persist straight on into the execution and the shipping. 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 the interaction points with your next new product aren't great. So you really got to stay steadfast into learning about your product and seeing also how it continues."

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 in the product teams, you know—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, and 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?"

"Yeah, I mean, it’s kind of funny. One team member 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 little light plates and painted the wall, and now all of a sudden the dining room next to the kitchen looks horrific. You know, you have to think about how, you know, 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 you 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 cultural norm. We have a program where it is very organized and established; it's called our Essential Journeys. What we did was identify what are the top 17 most important user flows that many of our users go through daily. It's not a comprehensive list by any means, but we just needed something kind of digestible, and so there's 17.

We have DRIs and team members assigned that every quarter they review that experience, they score it, they friction log it. 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 pre-flight 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.

We pay careful attention to it. It's a company goal to get these things to green and keep them at green. As I mentioned, regressions can happen, so how do you stay steadfast on that, improve it quickly, and get it back out there?

Yeah, it's definitely happening as a part of that program, but I think what's super cool is when, you know, somebody from the sales team does a walk-the-store of the 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, would love to check it out.

"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, and you really get to feel it. A prototype might not always show you how it's going to show up in the real world, so using it in the real world is very helpful.

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. It's like, if you see something, say something, which is, you know, super helpful.

So one of the things that came out of that was that we have this product called Link, 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. So in this website here is a nice easy tool where you can quickly buy crypto.

What we found is that when you 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 have to tell 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 invalid.

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

So what we did was just, you know, we saw that that was a bug filed and so now, I type it in, it doesn't yell at me. What's cool is even when I hit a space, right? The space is not needed, but it's just like a natural thing a human does that is not, you know, 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 micro moment— that matters. 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 how much design can really impact the bottom line is this great one about an email. We had this one email that was trying to communicate to a user what to do with the product after they have signed up.

As you could see, it's just like there's not a lot of hierarchy. It's not a real clear call to action about what to do. If you read it, you know, the words 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? 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. I can see why; there's a clear call to action. There's a headline that you know I can't read the subparagraph 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 thrilled about this product that we launched this year that is called Workbench. We were hearing from developers about the, you know, some of the challenges they have with working with the integrations and continuing to maintain and grow, one of which was, you know, essentially breaking their flow state.

So they would be working in the Stripe dashboard, and they would be going back to their code editor and you know a lot of switching of—what do you call it?—context switching, or going to the docs and constantly opening lots of tabs, etc. We had a developer area, but that was kind of getting like a little too jam-packed in a small space.

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. You can see you could pull it up, you could change how much of it it takes over this screen, and what it provides for you is basically, it's both like a microscope and a telescope of what's going on with your integration.

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.

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—what? 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 are the issues?’

And 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, you know, kind of fuels the developer’s ability to go further with it and build potentially, you know, new innovations on top of that.

Let’s say, ‘Okay, I want to learn about the customer. What's going on with them? What happened in the event?’ 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.

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

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, you know, your editor, and really being able to like bring the power of the CLI right into the dashboard. 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 in real time and hearing from them how to make that better."

"This is great. I don’t know that I’ve ever seen something like this before, 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.

Even recently, the designer on this Workbench back in May posted about it, and 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 like, ‘This is really great.’ No matter what size the company is, that regular touch with users is so critical to actually make a product for users."

I think one of the things that I take away from this conversation is how deeply integrated the entire company is with your users. 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. You've got forums like this that help you connect really closely with your users.

I think that probably clearly explains why Stripe builds such great, well-designed products. 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. I think 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 users.

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 do think like the Cision brothers did such a fantastic job instilling that in the culture. It does move the needle, you know, design certainly does make business sense, but even if it didn't, they would still do it, and I think that that's that X Factor— that's the thing that's going to make, you know, hard decisions along the way possible and certainly worth it."

Awesome! Well, thank you so much for having us.

"Yeah, of course, thanks for having me!"