🎂 John Collison & Jen Taylor Fireside Chat

Hi, I'm Jen Taylor, Chief Product Officer at Cloudflare, and I am thrilled to welcome John Collison, co-founder and president of Stripe, to our fireside chats here for our birthday week. Welcome, John. How are you? I am great. Happy birthday. Fun to be doing this. Thank you. I really appreciate you making the time. As I think we mentioned, a big part of the celebration for us here has been inviting in the community. And our mission is to help build a better Internet. And the way that we do that is through partnership and community and the different folks within the industry that we work with. And so we're excited to have you as part of that community. Yeah, that'll be fun. Yeah. So we were just chatting a little bit before we went live here, and you were sharing that Stripe's actually just celebrated a special birthday as well. Yeah, September 30th, that was our ninth birthday. So we're coming up on the decade just like you guys. I'll be watching for the best ideas you have during the birthday week and stealing them for us next year. That's awesome. So one of the things we've been talking a lot with leaders here in these conversations is just really sort of looking back over the last decade, decade plus, really thinking about the technologies and the innovations and to some degree also the underlying challenges that have been the catalyst for the innovation we've seen. Can you kind of take me back in the way back machine? Can you talk to me a little bit about the origin of Stripe and what was the problem that you saw and what was the opportunity you saw that went with it? Yeah. I think the thing that's interesting about companies like Stripe, I'm sure you're probably feel this way with Cloudflare also, is there's a famous patent office quote from, I think it's the 1910s of everything that one of the patent commissioners or bigwigs of everything that can be invented has been invented. And there can be this real sense that it's hard without the benefit of hindsight to be able to kind of predict the future iterations. And certainly in 2009, which is when we started kind of hacking on the first version of Stripe, if you were to ask someone about online payments in Industry Observer, they'd say it's pretty mature, right? The web has been around for, gosh, more than a decade as broad consumer technology. We have other providers out there in the market. Hasn't this thing been solved? And certainly when we went to try and hire the first people or raise the first money for Stripe, it's, isn't this a solved problem? And of course, what you have to zoom out and look at is the fact that, you know, yes, we are, we have done some stuff, but we're really early on the Internet growth curve. And so as a result, there's the opportunity to go build something like Stripe. And you know, with us, we ended up. So again, I think there's probably a bunch of markets that people think are, you know, mature or, you know, they're, they're all played out and they're not, you know, zoom or having the zoom call. That's probably another good example of it. Right. You know, people thought we had solved this video conferencing thing just five or 10 years ago. And, you know, it turns out we haven't. Yeah. When, when you started hacking on, on Stripe and you thought about that, that moment to kind of innovate on, on what many would perceive to be a mature market. What, what was the, what was the toehold? What was the edge? What was the place where you're like, you know what, this, this piece, this piece here is still, this piece here is still not right. There seems to be two ways that people create companies. One is you know, very smart people analyze the markets, do a bunch of math, do a market analysis and think, oh, we're going to go address this segment of the market, you know, because all the, you know, the things aren't right for us. And, you know, my exam, my understanding is this happened somewhat in the, you know, in the consumer space where people just like, you know, really go and do a bunch of market analysis and, you know, determine this is where we're going to go try and build a winning product. We didn't do that. And, you know, we, we, we, we weren't far long enough. We didn't, you know, have good enough business instincts to be able to do that. And so instead we had the other relatively tried and true path of starting a company, which is, it was a problem that we had run into. We'd built a software as a service business before Stripe. And just the hardest problem that we had run into was, you know, we knew how to get customers aboard. We knew how to, you know, write code and how to host it. We could do all that. But then when it came to the other side of the value exchanges, accepting money for, for what we built, that part was still really, you know, needlessly difficult, especially given the number of people that were doing it. And so, I mean, we were pretty young at the time when we were starting out, you know, we were 19 and 21. And so, you know, I think with a bit of that youthful naivete, we're like, well, how hard can it be? You know, it turned out quite hard actually. But that's what got us started with Stripe. Now, of course, that's, you know, we started building Stripe in 2009. We launched in 2011. I think it's one insight that gets you going with a company. It's another that keeps you going. And then we've discovered all this interesting depth in the problem space. But that was really what got us started with it, is it was incredibly frustratingly difficult. The entities at the time just did not get technology, did not get APIs. Stuff that sounds basic, like, you know, if you were integrating on PayPal at the time, the API would just keep breaking. You know, all these, you know, non-backwards compatible changes would keep rolling out. And so, as a developer, you're tearing your hair out. Why am I spending time maintaining my payments integration rather than on something, you know, more useful, like feature development? And so, there were these wedges that we were able to, you know, to get in around developer productivity that actually proved pretty important in the strategy. Well, and I think that that's actually a really interesting thing for me when I look at what you guys have been able to build. Because being somewhat familiar with the payment space myself, like, you know, payment providers, those kinds of platforms are very focused on, you know, how do I sell into an existing organization? How do I sell into, you know, and it's selling into a buyer versus selling into a user. And I think part of the magic of what you guys have been able to do is really sell into the user and the developer in a way that I think has really kindled a level of passion and a depth of integration and adoption that I think has really enabled you guys to leapfrog. Yeah, I think that the consumerization of IT is probably a little overblown or a little, you know, sold too much. But there is something real there, which is previously companies sold based on the slide deck, based on the checklists, based on the requirements. And now, increasingly, we have products that are built by developers who are choosing those products based on developer ergonomics. And so, I think a lot of the cloud wars are being fought on this, you know, right now. I think Google and Azure and AWS all realize that how easy their product is to integrate for developers will, you know, that will determine which platform gets chosen for the day one build. And then that will actually kind of grow up into a quite interesting business. Again, same for you guys and certainly for us. We spend a huge amount of time thinking about how can we make it easier to launch a business? How can we take work off people's plates? And it's interesting because, you know, the traditional journey of companies is as they grow to go more and more enterprise, you know, so they start off, you know, building little white flyer and they end up kind of only selling an Airbus A380. But actually, what we've done is obviously we have lots of, you know, progress in the enterprise. We just announced a great partnership with Salesforce last week. And it's, you know, one of our fastest growing segments. But at the same time, if you were to come internally to Stripe and look at the product reviews and things like that, you'll still see huge amounts of energy being spent on, are we making it significantly easier than it was before to integrate Stripe? And so things like on our, you know, Stripe billing products, making it so you should be able to build a subscription business and all the subscription management and things like that without even writing any code. You know, we should be able to give you that portal and things like that. And again, that's a matter of strategy for us because if we make it easier to start a startup, two reasons. One, obviously, we're more likely to win those startup users, but also it grows our time. It grows our market. And the reasoning behind Stripe Atlas and products like that as well is to enable this explosion in Internet businesses, because we're very directly aligned with that. If we can create more business for ourselves, you know, the budget, you know, three years down the line, you know, is where you can pay for that. Yeah, no, it's, it's, it's fine. It's, it's amazing what happens when you do focus on kind of taking complicated things and making them simple and delivering that ease of use and making it kind of faster and easier. And you do, you kind of grow that addressable market. It's, it was a big part of the DNA, I think for, for Matthew and Michelle and Lee, when they founded Cloudflare. And it continues to be a big part of how we think about, you know, the products that we delivered today. We really pride ourselves on, you know, taking these complicated concepts and making them, them available and addressable. But one of the things I think about a lot when I think about your business is just, you know, the fact that you guys are able to deliver that simplicity, but the complexities of, of the scale, and then also just that you guys are operating in, you know, what is a fairly regulated space in, in many ways. What are some of the key technologies that you feel have been kind of critical, like pieces to enable you to, to kind of do what you've been able to do? Yeah, it's a, it's a great question. And one of the ways we think about it is this complexity exists regardless. And so it's just a question of, is the user managing the complexity or are we managing the complexity? So for example, and it's exactly as you say, we're operating a pretty considerable scale now. So in theory, we should be able to, what we're always pushing ourselves is we should be able to make improvements to Sprite and then push those out across the user base. So everyone benefits. And so for example, one of the things we do is secure, you know, credit card storage and tokenization. It sounds simple, but you know, as you probably know, exactly. It's not, it's not actually that easy a job to do super reliably, super high availability, incredibly securely. And previously, you know, if you rewind the touch thousand five or 2000, this is something that businesses would have to deal with themselves. You know, they were responsible for this. They were drowning in PCI audit work and things like this. And so Stripe being able to take that work off their hands, that was one of our big initial wedges. Another one, you know, I mentioned the API upgrades, but we have a platform is this, where you always have this problem as an API company, which is you're rolling out new versions. And so the fact that you essentially get API version drift. And so one of the technologies we built that was very enabling for us was a translator. And we blogged about this, a translation layer for the API where as your version of the API drifts, you know, if you integrate in 2015, you might be pinned on a version of the API in 2015, but we're still developing, we're adding all these new capabilities. And we're on the 2020 version, you can still send 2015 formatted API requests to us, and we will translate them forward for you. So we've built that translation layer rather than you having to build it. And we'll maintain that. But obviously, if you want the new thing, you know, we encourage you to upgrade if you want the new features, you're going to have to upgrade to a more modern version of the API. But that's example of an enabling technology where, you know, someone's got to do it, someone's got to manage the difference between the API versions. But it's probably a big economy of scale we can bring to bear where we take on that migration work and not you. Yeah, well, and also critical, right? Because so many, to your point, so many, so many developers, so many organizations will implement at one moment. And implementing Stripe is a part of a bigger, bigger, bigger puzzle, bigger solution for them. And they may need to move on and innovate in other ways. And to be able to kind of maintain that trust and that consistency for them to be able to continue to deliver that efficiency and that value over time without them having to worry about that managed overhead is a huge amount of value delivered to them. The other maybe big enabling technology was, I think previously payments companies really thought of themselves as a thin stateless layer that just charged the card and moved on. And with Stripe, we've always tried to have this user-focused mindset where we say, what problem are you trying to solve? And use that to drive our product roadmap. And so we basically ended up being a billing engine for most of our most successful customers, like the slacks of the world and people like that. And I think this is the classic, there are these kinds of problems that developers, if you ask them how much work it's going to be, they'll say, oh yeah, we can knock that out in two weeks. And then we'll be on to other things. And you find yourself three years later, person team staff together, still not done. And you're like, oh my God, how did we get roped into this Arctic expedition? And so, but again, it's one of these things where Stripe should be able to do this much more efficiently than every single one of our customers doing this. When you think about all the storing customer records, managing plans, managing pricing, even just the taxonomy design of how one designs a billing system, blow up in your face later on is surprisingly non -obvious. And so that's an area where it's actually been a very important adoption cycle for Stripe as people realize that like, oh man, the cron job on steroids I built back three years ago is not going to scale. It's time to put something more robust in place. Yeah. We were talking here about the technologies and stuff like that that have evolved over the last 10 years to really enable your business and the business around you. But I'm curious, what shifts and changes and evolution have you seen actually in your user base, in your developer community? Because they're such an integral part of both what you do at Stripe, but even just more broadly, the Internet and technology as a whole. Yeah. Look, the big difference this year, I would say is that there is a huge number of businesses that are dealing with demand spikes or really rapid scaling challenges on Stripe as so much of commerce gets pushed online. And again, these are trends that perhaps we had predicted happening over the long-term. They could have been expected, but they really just got accelerated in a very meaningful way. And so we have everything from notaries, a notarized platform for online notaries, to Doctolib, which is a French telemedicine company. And you can imagine the demand for telemedicine between January and April, huge scaling challenges, huge, huge scaling happening. And that's something we've seen amongst this space. And of course, the ability to, I think people in the tech world get this, but scaling doesn't just happen. It requires a huge amount of work to architect things well to be able to scale and just to be able to keep up with the increased demand. Doctolib also, one of the other things we see a lot in our user base that I find incredibly exciting is it really used to be the case, even to some extent, when we started Stripe in 2009, Silicon Valley was the center of the universe. And that is increasingly not the case. And I mean, it's especially not the case in 2020, where very many people are working from, we've seen people maybe move back home or something like that. But even more broadly over the past five or 10 years, we have seen amongst our user base, tons of successful companies popping up. Everyone from Matches Fashion, the UK, to again, Allen or Doctolib in France, to you name it, all over the world, Indonesia, Singapore, Australia. And that's really honestly motivating and exciting for me to the fact that these technology opportunities are available and not just to people in the 94107 zip code. Yeah. Well, and I think the other thing that is interesting, true, is that's something that I think Stripe was early on in adopting itself, right? I mean, so, one of the things that you guys did, I think, was really start thinking about how can you hire and grow your teams in a variety of different places and have a more distributed workforce? How did that decision go? I know many people today are thinking about sort of what is return to work look like and how did you guys make that decision and sort of what have you done to kind of help make it successful? Yeah. Well, I think despite the fact we more or less started Stripe or certainly when we started building out our office presence, that was in first Palo Alto and then San Francisco. I think the fact that Patrick and I are from Ireland originally, I think we've always viewed it more as outsiders and we've always maybe brought a bit more of the immigrant or Irish perspective such that it was never the case that from day one we always felt like this is the only place you can hire people. This is the only place you can build things. And so, we actually have very robust, our international headquarters is in Dublin. We have very robust presences in Seattle and Singapore and places like that. And we actually do, this is unusual for maybe some tech companies, we do lots of engineering and R &D there. So, we have engineering offices in Dublin or Chicago or Mexico City or Singapore or places like this because when you think about the product we are making, excuse me, the product you need to run a business in Singapore is going to be different than the product you need to run a business in the United States and you probably can't build it from San Francisco. You're off time zone, but you also just don't have the understanding, you can't spend time with customers, it's just not going to happen in the same way. And then further to that, we've always been a very remote-friendly company. I don't know the exact number right now, it was 20% of our engineering core is remote. I mean, obviously, now it's 100%, but I think steady state now it'll be more like 30% or something like that with a very significant remote engineering group. And I think you've probably found this too, there is a mode you have to be able to work in to support remote work broadly and remote engineering well, it's just like a different way of people working together. But if you are willing to pay that somewhat fixed cost investment, I would say most of the investment is fixed cost, then it's obviously fabulous from a recruiting perspective because it unlocks such a larger people who can work at the company. Now, one, it creates opportunities. We talk a lot in the and just by very nature of recruiting from more diverse places, you end up with a more diverse population, which is great. If you want to move those numbers, it turns out hiring again solely in San Francisco is maybe not a good place to be starting out. It's not going to create the change you're looking for there. Well, I think the other thing that I've really discovered in working in very engineering -driven companies is if you have a product, it is very helpful to have that kind of strong engineering DNA within the organization as you're building product to service that organization. So back to your sort of building a solution that provides an opportunity for Stripe in Singapore, building a solution from people who know what is actually happening on the ground and has a feel for what's happening in that market, I think is really, it's powerful. That has been a huge part of Stripe's product development. I mean, the very early days, Patrick and I would try to visit our users' offices, have them visit Stripe, see them integrate Stripe. And by the way, if you are building a product, you might think the product is good. You might think the product is acceptable. A great reality check for yourself and a great way for you to realize that your product is fricking terrible and completely incomprehensible is just a stand over the shoulder of someone's like you've been trying to integrate it and things that are so obvious to you. It's like, wait, so how do I change the, you know, how do I start making tests? But for anyone who's developing a product and has not done this, like user research studies have their use, but they're incredibly theoretical compared to the deep pain and shame of watching someone try to use your product and your product let them down. It will stick with you. It is my absolute favorite thing to do as a product person, right? To actually, because you have this vision of like, this is how it's supposed to feel in the lab. And then actually when you get out there, wow, that's, it's completely different. You know, and you can, you can tell yourself a story, right? You know, it's like this new, this new onboarding flow is much easier to use. Like is this, is this let's let's put this to the test. So we've always had that mindset. And again, there's something different around, you know, between having a, you know, a goal of serving European companies incredibly well, and then actually having people in Dublin and London and Paris and Berlin and Stockholm offices, as we do meeting with these people day in, day out, and, you know, wrapping on the heads of the product, people at the product, right. Well, and it's good. It's still true. It's like everybody conducts commerce, but people actually do it differently in different parts of the world. Yeah, very cultural. So, you know, one of the things that, that I'm really intrigued by is the fact that Stripe has been so successful in really building great product, but also really building a great platform. And one of the things you and I were chatting a little bit about as we were getting ready to get on the call is that every company I talked to is like, we're going to build a platform and we're going to be, and it's building a platform and actually getting adoption of it is, is no easy, easy trick. What, what are the, like, do you walk in and you're like, I'm going to build a platform. This is how I'm going to do it. Or how did you guys go about thinking about and conceiving of your platform and, and, and really kind of partnering with your community to drive the adoption of it? Without wanting to get too, you know, theoretical or abstract sounding, I mean, a platform is a way of life. I do think there's an element where there is a platform building mindset that is quite hard to wrap your head around because you're operating at such a, you know, at such degrees of abstraction. And so, you know, you imagine if you want to build a successful app platform as Apple has, and you want to build a really useful tool if they have in, you know, robust Xcode and, you know, iOS and Cocoa and everything like that, you have to, there's more hysteresis in the system. There's more lag in the system from the feedback you get. You can't just, some products, you can ask the customer what they want, go build it, and, you know, then have the working product. That's fine. With a platform, or especially a developer platform, there's that extra step, right? Because you have to build something that's good for developers. And you can't even just ask developers what they want, because it's such a large thing. You can't, you know, build it requirement by requirement. You need to have a specific vision for what it does. And the developers need to go build stuff on it, and then the users benefit from it. That is a really large amount of engineering work to do without intervening customer feedback. And so, as a result, I think you need to be able to come to the problem with more specific vision on how it should work than some other products. That'll be thing one. Thing two is, there's a real sweet spot of opinionatedness in platforms, I find, where, again, you look at iOS and how it kind of steers you developing in iOS. I mean, in theory, it's a, you know, it's a developer platform. You can kind of build whatever you want. But there's clearly a way of building iOS apps, both in kind of the specific HIGs that Apple might give you, the human interface guidelines, and in the kind of affordances and the ergonomics of the developer experience. I think getting that right is really important, because if you're building a developer platform, people can build the same product on it, you know, six different ways. Five of those, they're probably going to be pretty unhappy if they, you know, choose that, especially given the developer of the platform, maybe actually all six of them, they might be unhappy. And so, getting those ergonomics and kind of guardrails right. And so, you know, again, Stripe billing might be an example of that, where we need to be able to support everything from Slack to HBO to, you know, consumer, B2B, you name it, being able to kind of model their recurring billing logic in something like this. And so, it needs to have, you know, quite a lot of flexibility, but also the right guardrails for you. And I think getting those right in platforms is important. We haven't even gotten to the community sides, but I don't know, you all have been doing the same thing, and you're, you know, you have a year's experience on us. So, I mean, I just go back to what you were talking about before, which is sort of, you know, at the beginning of sort of watching the developers work and what they're building and just being kind of very, to have that point of view as to sort of how we anticipate this should work and will work, but having the flexibility and how we actually innovate on top of that and adapt with it as we go. And I think that it's, I think there's a temptation when you're doing something like a platform to want to go very quickly and be very like, and I actually think successfully building and delivering a platform and scaling a platform is a little bit of a longer burn, because you need those cycles with the community to be able to actually understand sort of where have you got it right, where is there still a little bit of a pinch, and kind of where does the community actually need you to go. So, yeah. So, we just have a little over three minutes left, and I wanted to just sort of say, okay, so we've been talking kind of looking back, you know, last 10 years, looking forward, what are you most excited about, most interested, most concerned about, from a technology point of view, kind of looking forward? Oh, man, so much. So, I mean, three minutes or less, right? Exactly, yeah. Look, the main font of my optimism is the fact that there is still so much to do in technology, you know, still so many unsolved problems, and even, again, I think problems that we think have been solved, I think we're going to see a lot of new companies created in those veins, a lot of new startups pop up, and, you know, things will get much better. And so, that's, you know, we are still early in the Internet trajectory, the Internet economy is about 10% of the global economy, you know, we're not there yet, and I think being part of that trajectory is awesome. I was actually just kind of following along on the Starlink progress, but, you know, that's an example, you know, we're going from terrestrial wired Internet to launching vast numbers of satellites in the sky to provide global Internet. It's like, wow, you know, it's such an amazing time from a technology point of view to be alive. We talked about the global spread of technology companies, that's very clearly going to continue, and that gives me, you know, very significant optimism, you know, Ireland's where I'm from is home for me, and seeing even the change in kind of the Ireland technology ecosystem over the past 10 years has been really motivating. So, I think that's going to be a delight. In terms of concerns, you know, one obvious one to touch on is we don't know how to regulate technology yet, and we're still figuring it out. And so, you see kind of those stuff starting to come in with GDPR, and, you know, CCPA, which is California's version of GDPR, which has had some benefits, some costs, I think tending to get countries getting into how they regulate data access beyond that, and, you know, various countries coming in with fairly specific rules. And even just, you know, I think we saw this in, with the spread of COVID, telemedicine was something that was very locked down, very regulated, whether you could practice telemedicine along state lines and things like that. And with the arrival of COVID, a lot of those rules were relaxed or kind of very quickly improved regulations were put in place. But it's like, okay, if we hadn't had COVID, how would those, telemedicine is clearly a fabulous thing for the world, is a huge productivity benefit, if you know nothing else, doctors not spending hours on the roads, and, you know, lowers cost of access to medicine, increases access to medicine. And so, if we hadn't had COVID, what was our plan there? How are we going to get around to that? And I think we really need to take these issues seriously, and more and more moves online, we're going to need to rejigger a huge amount of how we regulate all these areas, and telemedicine just being one example. And I'm not sure we have the appropriate energy behind that, everyone's getting involved enough, we're holding ourselves societally to high enough standards from the right regulation. So that's something that's on my mind. Well, John, I just want to say thank you so much. It has been an absolute pleasure chatting with you. Happy ninth birthday to Stripe. I look forward to celebrating many more Stripe birthdays with you in the future. And I really appreciate you joining us to celebrate our 10th. No, this was super fun. Happy birthday. Thanks. All right. Take care. Bye.