David Singleton: preference

Transcript context

…Genius. And that is a really good example of being meticulous in the craft. So it's pretty uncommon, it's certainly very uncommon back then for companies to do this, like your error messages or your API, who's ever going to look at them? Well, turns out developers while they're building and if they're running into problems, they will look at them. It's actually a really high stakes moment because it's a time that matters. So that is an example of where we've been meticulous in the product. And the way that we kind of figure out where to be meticulous, where to really sweat the details and go above and beyond is again, we try to be as user first as we possibly can. So we have a process that is widely used across product teams that even like folks building stuff internally for Stripes to use, which we call friction logging. The way this works is you need to put yourself in a particular user's shoes. It's actually important to have a very clear idea of who is the person I am kind of modeling the friction for right now. So for instance, I might be integrating the Stripe billing API and I might put myself in the shoes of an engineer at, I don't know, let's say Atlassian, which is one of the world's largest SaaS platforms and using actively Stripe billing for automating all the revenue today, I might put myself in the mindset of that person. I might have met them recently and kind of understood a little bit better than otherwise doing this particular thing. And then I will go through the process of actually using the product, starting off in the dashboard, hopping over to the particular page in the docs that I need to follow, starting to write code and so forth in order to do my integration and make really careful and meticulous notes of what the experience is. So stream of consciousness notes, but paying particular attention to the places where I ran into friction that I think that particular user mental modeling would find difficult. And then those are the places where we will tend to go and invest a tremendous amount in really thinking how could we solve this problem? And then putting a lot of attention into detail into making it right. And by the way, the example I gave you on the error message is there's actually more code in the jobs that serve the Stripe API to handle those edge cases than in the actual main flow. And I think that's quite remarkable. Most people wouldn't do that, but it turns out not only was it something I was impressed with, but when I talk to Stripe users, this is very frequently something they tell me and delights them about the product. It's a reason that they can adopt it more quickly and it's a reason that they keep adopting other Stripe products because they know that it's going to be easier than doing anything else. So it really matters. So the point is like we are intentional about where the places where being particularly meticulous matters and then when we are, try to do it in quite a systematic way. ing else. So it really matters. So the point is like we are intentional about where the places where being particularly meticulous matters and then when we are, try to do it in quite a systematic way. It's great business as well. So for instance, we actually just earlier today put a blog post up that explains we've been tuning both what we call our payment element, which is our kind of morph kind of batteries included UI for putting payment integrations directly on your website. You can style it to fit with the rest of your page, but it has a lot of powerful features. And we also have a set of hosted services called Stripe Checkout. And the point here is we've gone and scarred a whole bunch of checkout flows on the internet over the course of many years and we look out for all of the little broken edges and we've been working hard on these products to tune those and then not, we don't just stop there. We've also been really obsessing about what are the things that we can do in the flows that we've already built that will remove latency or remove a click or whatever. And what we found, we've recently measured the difference between, so with a bunch of actual users who've migrated from a fairly vanilla integration where they built their own checkout flow to one of these surfaces to our payment element or to Stripe Checkout, it turns out that it increases the average user's revenue by 10.5%. And that's huge. So this is an industry where little changes that you might go about making or even big changes that you pour blood, sweat, and tears into will typically deliver uplifts in that you measure in basis points that's hundreds of a percentage point and this set of small changes compounding over time ladders up to 10.5%, it's huge. And the point is you only get there by knowing that this is a thing that might ultimately matter and being meticulous in every single step along the way and that it compounds to a dramatic impact in the end. So I think that that particular set of experiences is one where this operating principle has really mattered. Thinking about those kind of flows is what led us to build Link, which is our product for making one click checkout available. And that has had a tremendous impact both on convenience for customers of our users and also on their conversion rate and so forth. So it really matters. And then one final other area, if I may, I think Stripe is relatively well known for putting a lot of care and attention into our website, a lot of our marketing or product explanation pages. And I think for a business like ours, it's not immediately obvious that it makes a tremendous amount of sense to be super meticulous in building those experiences. But we are, and again, I think it really matters for us and for our users. So the way that we got into this mode was we recognized that we are building a lot of infrastructure. So we build what we call our global payments and treasury network.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.