Adora Cheung:
Patrick, welcome. So Patrick is the co founder and CEO of Stripe, he launched the startup, or now pretty big company in 2010, correct? With his brother John.
Patric...llison:
Well actually we started working on it full time and 2010. But it actually, to your comment just there about companies launching, it took us quite a while to launch because we had to get all these kind of banking partnerships in place, and so on. And so we didn't launch until September 2011, we've been working on for almost two years at that point. And every time we saw a PG or really anyone else from YC, all they would ask us is why we have not launched yet. Some things don't change.
Adora Cheung:
That's interesting. So two years until you have to-
Patric...llison:
Yeah, it was I think one year and 11 months from sort of first line of code to public launch. Which to be clear, I don't recommend, that is not a good idea. Just we had to, because we have to kind of get all these other things in place. And because it sort of took us so long to publicly launch, we tried to be very disciplined about sort of gradually expanding the number of users every month. And so even though we weren't publicly available ... We got our first user, like, first production user, just kind of three months in and then have every month we tried to add at least kind of a handful of users. And so by the time we publicly launched, we did have about a hundred users, which I mean, back then that seemed like a big deal. It's very, very large.
Adora Cheung:
Speaking of, actually, when I was preparing for this interview, I was trying to jog my memories. And I remember specifically because your office was near here in Palo Alto. And I remember back then people would always talk about the Collison brothers running around going to people's offices, and like, installing their AVI into the web apps. And in true do things don't scale fashion. And I assume you are not only trying to make sure they installed it, but also get user feedback. And it happened so much that actually, I don't know if Paul Graham, PG, now calls it the calls it the Collison installation. And this is actually something we give, we tell founders to go do this, do the calls and installation. Because obviously in hindsight, it seems so obvious to do.
Patric...llison:
Well, it sort of served two purposes. One is to your point, I mean, it's a really good way to kind of get sort of, do user research and to get kind of UX feedback and so on. And I mean, if you've done this, I'm sure you've had the experience where you design what you are absolutely certain is the most streamlined, user friendly, straightforward, frictionless way to do whatever it is the product does. And then you kind okay, you kind of put it in front of a user, and you just kind of ask them to do whatever it is, and they find it completely impenetrable and they're clicking all the wrong links, and they can't find the next button, even though the next button is there blinking in green and stuff. And invariably, incredibly painful, the sort of nothing as sobering as watching somebody use kind of that the first version of some new product. But the other reason for us was we would suggest to somebody, they use Stripe, or they switch to Stripe, whatever. And invariably their response is "Oh, yeah, sure, that sounds awesome." But it can be postponed and postponed again, and just like, there's never a moment where it's like, okay, this is the evening where I'm going to switch to Stripe. And so us going and sort of accosting them in person sort of helped ... People talk about in sales, it's always like a why you, and a why this, why now, and these kinds of questions. And going in person kind of created a why now moment, it's like, well we're here at your house.
Adora Cheung:
Did you just show up? How did you-
Patric...llison:
I don't think we ever actually just showed up, although, perhaps we should have. But we to be kind of, at least semi invited.
Adora Cheung:
Got it. So, so Stripe now today. I mean, you've come a long way since back then. I mean, it's not even then it's really been a decade, not even. But I mean, today, you're you have 1,300 employees across nine offices across the world. You're doing ... I have a list here. You manage 200 million API requests a day, you process billions a year for millions of companies across 130 companies, your [inaudible] funding Stripe is now worth 20 million dollars. Billion. Anyway, the list could go on. I'll stop there. Otherwise, people are gonna think I'm your PR agent. But anyway, you've clearly done something right. And so I want to spend a lot of the time today talking about running your startup from the perspective of the startups you, you yourself ... And it's kind of like zoom, like, what what do you think about from zooming in on the day to day operations, to zooming out to the long term strategic decisions. So maybe to help us ease into the discussion, one thing is when you start off one from the very beginning, a lot of friends get together and they come up with an idea, and they're super excited, and they start working on it. And then at some point, they need to decide, we need a CEO for this company. And some people aren't meant to be CEOs. But for you and John, I've met both of you, you're very smart, ambitious people with great qualities and attributes that correlate to becoming great leader. How did you and John decide you would be the CEO?
Patric...llison:
Well, I think Stripe is unusual for John and I are obviously brothers, we've known each other for a long time. And because of the relationship, we sort of place a lot of trust in each other. And we really do run the company together, there's no major decision that sort of Stripe has made that sort of, that we've not both been a part of. And it's not always the case that despite being the CEO that kind of I'm the person who ... Like in the case of disagreement it's not always the case that I prevail. Our kind of dispute resolution framework is kind of much more round which of us cares more, than kind of which of holds this title or that. John's title is president, there's kind of some, both are significant roles. And so in that regard I think we're kind of an anomaly. The fact that I became CEO was honestly, semi random. And I would say, yeah, I think because we're brothers [inaudible] get to this unusual situation where we really do run it together. Which may not be a helpful answer, because perhaps you're trying to encourage all these companies like shit, one of guys has got to be the CEO, but-
Adora Cheung:
Well, do you think there's like a rubric for this? Here are five questions you should answer. And maybe then you decide.
Patric...llison:
That's a good question.
Adora Cheung:
Maybe not.
Patric...llison:
Yeah, I'm guessing it quite okay. I think it is important to just have an efficient mechanism for reaching a decision. And it can't be sort of simply [oriented] around consensus, right? If there's sort of three co founders and sort of, none of you sort of quite want to, or nobody's a clear CEO. And you don't have some kind of efficient mechanism first for having decisions get made, I think that is a recipe for failure. And, and even doing some kind of sort of quasi democratic voting is probably not a great idea either. And so for myself John, we kind of both of areas we kind of respectively specialize in. And so that doesn't mean we kind of have absolute autonomy and authority there. But so we kind of bias in that direction. So he spends more time for example, working externally with users, I spend more of my time working sort of internally on product and engineering things. That's not to say that he doesn't make decisions there, or I don't here. But again, there's a bias in that direction. And then second we have this kind of additional aspect where in the case of it being a major decision, and we sort of respectfully disagree, then, then we really do sort of try to make it based on sort of which of us is going to, is just more passionate about it. And because that will correlate with the outcome. One of us really wants to do something, or thinks that X or Y is the right thing to do. Simply sort of wanting [inaudible] so passionately is more, I mean, that can become a sort of self fulfilling prophecy. And so I think it's kind of not irrational to have that be a consideration.
Adora Cheung:
Yeah, I also see, like, the best teams that work well together are the ones in which everyone, they all want the best idea to win, not their idea to win. And so there's a stepping back and an unselfish kind of way to, to get to that conclusion.
Patric...llison:
Definitely. And I think that something that we're kind of lucky about that I think is very ... Well exactly to your point, I think is definitely present in sort of the most successful co founding relationships that I've seen, is some degree of sort of dispassion in disagreement. And for us it was kind of easier to get to, because we'd been disagreeing with each other for 20 years. And so it had lost some of the emotional charge. But I think that sort of finding other mechanisms whereby you can get there such that it's not sort of this, this kind of ... But the notion of disagreeing strongly is not sort of a scary phenomenon, and kind of both parties are multiple parties if there are more than two are kind of suppressing their feelings for fear of there being this divergence.
Adora Cheung:
How many more siblings do you have? Do you have one more brother?
Patric...llison:
One more sibling? Yes.
Adora Cheung:
Okay.
Patric...llison:
Three of us in total.
Adora Cheung:
Would you guys, would he join the, or is it just you and John, it's a special match there?
Patric...llison:
Well, Tommy, my youngest sibling, he's sort of quite a bit younger than myself and John. And so John is approximately two years younger than I am, and when we started Stripe I guess I was about 21 and I think I guess therefore John was 19. And Tommy was still kind of definitively midway through high school, and so just wasn't quite practical of the time.
Adora Cheung:
Yes, finish high school.
Patric...llison:
And now I think if you asked him he'd probably say he'd never throw his lot in with miscreants like us.
Adora Cheung:
Cool. So in terms of the role of CEO, often people say there's a threshold and time in which ... And it's related to product market fit, where you have a role as a pre product market fit CEO, which is completely different from your role as a post product market CEO. So I want to spend most of our time talking about pre product market fit. But just to calibrate those questions. What in terms for Stripe what was product market fit for you? Like, how did you define it, metrics to it, number of employees you're at when you reached it and so forth?
Patric...llison:
Yeah, that's a really question. And I think you're exactly right to kind of divide things into sort of those kind of ... The story of a startup is two stories. And it's a story of getting to product market fit. And then the story of kind of what happens subsequently. And obviously, there isn't like a totally definitive binary line between them. But I think it's kind of helpful to frame the narrative in that regard. For Stripe, and actually, around the time we launched publicly I think is basically when we had it. In that when we launched publicly in September 2011, we kind of rebuilt significant components of Stripe kind of multiple times in response to user feedback, like, we're kind of on the third version of our dashboard. And the second or third, depending on how you count, major version of our API. And so we'd kind of gone through a lot of iteration in response to kind of the evidence challenges that users had, or the deficiencies the product seemed to possess. And when we launched, we were basically immediately bottle necked on sort of being able to serve user demand rather than generate user demand. And I think sort of directionally that's kind of the inversion that happens, versus sort of in the early days, you're sort of really trying to figure out well, okay, kind of conditioned on, or given to some user, how do I make sure that it does what they need, and they end up a happy retained user in a sufficient fraction of cases or whatever. And then kind of at some point it floats, where okay, the sort of, well I think it's kind of very different, do you sort of take a hundred users, and some fraction of them on board and some smaller fraction remain engaged or whatever. And so, kind of a hundred users, the curve sort of asymptotes downwards. And then you take a hundred users and kind of, again, a meaningful fraction have engaged, then they actually tell more people about it, or they sort of invite people. I don't mean strictly just in a viral sense, but just kind of generally speaking, just that kind of leads to and generate more demand, such that things seem to be sort of, sort of in super linear fashion kind of growing. And I think when you sort of like being kind of less than one is just very different to being more than one. And it sort of seems again when we launched I mean, that didn't generate that many users. I mean, I don't exactly remember, but let's just pretend that sort of 500 businesses signed up on the day we launched. But sort of immediately those 500 businesses told other businesses, and people heard about it, and all the rest. So kind of the next day we had a lot of businesses as well and so forth, such that from the day we launched, the challenge became keeping up with demand rather than tweaking the product to somehow serve the market.
Adora Cheung:
When you launched, how many people were you at that point, employees?
Patric...llison:
We were about ten.
Adora Cheung:
So, I guess before you launched your day to day sounds like it was just like what we were talking about earlier, just running around talking with users and fixing issues. Was that literally every single day was like that? Or what were you doing every day?
Patric...llison:
Okay, so not literally every single day. But I would say we really tried very hard to understand in very granular detail and what exactly it was that people were doing, where they were tripping up, and so on. So, just to give you some examples, we had a chat room for sort of providing support when people were integrating Stripe. And it was actually a public chat room, which can have had some downsides because if we'd broken something, or somebody had some kind of embarrassing issues, everyone would see it. We thought that was kind of good, because it would actually kind of put more pressure on us to sort of have the product be good. And we had, literally every time for the first call it ten years of Stripe, every time somebody sent an API requests to Stripe, like it sent an email to us. So we were like, looking at every single API request. And if we saw users do something weird, why did they do that? Where were our docs confusing, or whatever. And I'd go to dinner in the evening, it seemed like a lot at the time, I'd have maybe ten emails, because Stripe was not handling a lot of API requests back then. But so you're literally looking at sort of each individual action. And actually Stripe, we just kind of celebrated or at least passed, we're not very good at celebrating. But we passed our seventh anniversary just a few days ago, on September 29th. And so I was looking at our sort of, we had an hourly stats email that we use to send. And so on the day we launched we handled sort of 22 payments in the previous hour. Which again, sort of seemed huge to us back then. But I was noticing in that email, I'd actually forgotten this, that we had things like in the email we literally had a list of businesses that had submitted three or five or something API requests. But had sort of not gone live, they'd not launched their businesses, we literally had the emails of all these businesses. The idea was that we would then kind of literally individually reach out to them, it's like, "Hey, you kind of seem to use Stripe little bit. But you didn't, you didn't go live, like, did we screw up? Or was the product somehow inadequate, or whatever?" We did things like every time anyone ever hit an error of any sort that generated like, a high priority email to us. And so we sort of tried to immediately go solve it. And that also kind of generated sort of, I think this pleasant kind of user experience, where I mean it's frustrating when you hit an error in some service. But we could then often sort of 15 minutes later, reach out to them and say, "Hey, we saw that you have encountered this problem, it's all fixed now." And sometimes we did that even in the case where sort of the users made a silly mistake. And they kind of mistyped an API parameter or something, and we just reach out to them, they're like, "Hey, I noticed you had a typo in your code," which perhaps to some of them was a little bit unsettling, right? But at least going to help us increase the kind of the throughput product feedback. But so, I mean, these are all kind of examples, I would say, of the sort of general pattern of sort of really trying to be kind of hyper attentive to all the micro details of sort of what people were doing the product and kind of iterating rapidly in response to it. And generally speaking I think that sort of pre product market fit metrics are actually relatively unhelpful, and I think you sort of, you really want to bias very strongly towards kind of as much sort of inspection and kind of high throughput qualitative feedback as possible, because probably not that many people are using your product, right? And so if it's 20 users, you can kind of, in some sense, afford to just like, look at everything they're doing, and try to understand kind of what's working what isn't.
Adora Cheung:
Yeah, in some sense, it's how much do they, you can tell subjectively, like, how much they love your product, how much are they going to probably be really upset if it just disappears.
Patric...llison:
Totally. And actually, on this point we had a thing, at the bottom of every web page we had a little sort of text box and kind of anchored to the bottom of the browser frame. And sort of one line "Hi," sort of text input, and, we had placeholder text in it to sort of try to prime people to tell us things. And so it had, "My favorite part of Stripe is ..." And people just fill it out. And can hit enter now. But also, of course, most of the problems were negative. It was, you know, like, "The worst thing about Stripe is, or the worst thing that this page is, or, I really hate the way Stripe does," or whatever. And, and again, we'd sort of, sort of at that stage you have to be kind of masochistic. And so again, we'd be sort of always waking up to all these emails telling us all the terrible things about Stripe, but that was helpful to do list for the day ahead.
Adora Cheung:
How did you stay happy, if, like, in the early days [crosstalk] complains.
Patric...llison:
What makes you think we did? So it was, it was ... Happy is such a squishy concept, right? And because, like, there are lots of things that we, I guess, when I look back and look, maybe it's the rationalization I taught myself, but when I look back through life at the things that I'm sort of most glad I did, I wasn't exactly happy while I was doing them. Often I was very stressed out, or had to work really hard or whatever. But they're the things that kind of post hoc brought the most fulfillment. And I think that part of it is there's rich literature here. And so I won't kind of dive too deeply into it. But I do think kind of happiness is a tricky concept to kind of pin down. Is that kind of happiness in the moment? Is that sort of the sense that you have a year later, looking back, and then so on. And so, I think ... Language is squishy, and it's not completely specifically defined, but I think, generally speaking, kind of a better utility function, and kind of gradient to try to climb is that of fulfillment. And so I would say kind of the experience of doing Stripe was, it was not especially happy, because we were sort of constantly, incredibly aware of all the ways in which the product was severely deficient. And all the challenges we faced. And, I mean, it seems like, there was no FinTech category, back then, it was just like two teenagers, or just over teenagers trying to compete with PayPal. Which many people told us was not an especially kind of promising avenue to pursue. And so not especially happy per se. But it didn't feel kind of fulfilling. And I enjoyed working with John and the kind of people we subsequently hired. It was really fun working with the kinds of customers we were serving. They're just sort of businesses doing all these kind of wonderful things. And they were kind of really smart people. And it felt like if it worked, it could be kind of consequential in the world. And so I would say, kind of, it sort of felt like, I mean I don't know what it feels like to be sort of a scientist or something. But I'm guessing when you're sort of pursuing, you have this kind of big question, and you're pursuing all these kind of avenues to sort of try to better understand. I'm guessing day to day, it's sort of not especially happy because most of your experiments don't work or whatever, but sort of, perhaps there's some analog there in terms of it still feels in some sense meaningful.
Adora Cheung:
Yeah, there, in some sense, I mean, day to day, like you said, you're just you're running around with your head cut off. But maybe on a weekly or at least monthly basis is just taking a step back and seeing like, what progress have I actually made? Because week to week it's like 1% here, 1% here doesn't seem much. But from a monthly basis, or maybe longer than that it seems like there's movement.
Patric...llison:
Yeah, and I think that's true. And I think, I don't know, like, I think it's almost certainly a bad idea to sort of work in a company or to work on anything, if you're, like, truly unhappy working on it, right? And so there's kind of a [curious] balancing act there. And I think I mean, a lot of ... There are sort of so many different sort of difficult judgment calls to try to make in a start up. But of course part of it is if something is making you unhappy, or if it just didn't seem like an especially promising avenue, or it's not really working or whatever, your time has relatively high opportunity costs. Like, you don't get to start that many startups in your life, right? And so kind of knowing when to sort of call it quits, I think is actually ... I mean, sort of in startupdom we really extol, and sort uphold the virtues of sort of determination at all costs. Never quit and so on. And that's clearly not the right answer. Sometimes you should quit. And so I think kind of what you're getting at is true and right. Where I think there does need to be sort of some happiness, satisfaction, fulfillment. There's a good book of that name, "Satisfaction," which I recommend ... Kind of week to week, month to month, if you're on the right trajectory.
Adora Cheung:
Oh, man, I wish I had known that ... I could have ... I remember when I was about to implement Stripe myself, I had these bad memories of trying to implement PayPal. And the stacks of documentation, and taking like five days to figure it all out. And so I sat down because you guys are saying, oh, it'll take you ten minutes. I was like, no way. And it probably took me actually five minutes at that point. And I was super happy. Maybe I should have sent you a review.
Patric...llison:
Yeah that would have been great, especially if the review had sort of criticism for us. But no, it's definitely helpful to have competitors with not very good products.
Adora Cheung:
Yes. Okay. So you were, in the early days, you were doing a lot of stuff yourself. At some point, I guess two part question. One is, where are the things that you weren't good at? And then two, at what point did you hire someone to what I assume is to do those things?
Patric...llison:
Well, I mean, I'm not that good at most things. And I say this is in a non sort of fall modesty or, I mean don't mean to be artificially self deprecating. But sort of for almost anything that Stripe has to do, there are sort of people who are are better at that than I am. And so I think to some degree sort of the story of say product market fit and say our current stage is kind of implementing the recognition of that in kind of more and more areas. That said, I think maybe sort of embedded in that question is okay, well, acknowledging that you're probably not the world's experts in any single thing, it's kind of, in what order do you sort of replace yourself? And for Stripe the sort of, the important thing that we're sort of most obviously not that great at was kind of partnerships and working with the various banks that we had to sort of get on board and so on. In fact Jeff Ralston, who is here in the room today, I think sort of was some combination of sort of very supportive and perhaps in the back of his mind slightly pitying where he saw us kind of trying to get these partnerships with these kind of big banks in place. And we really weren't sort of getting anywhere very fast. And so he told us that we had to hire this guy Billy Alvarado. And told us, "Just, don't ask me questions, just hire this guy." And at the time everyone at Stripe was an engineer. And so we just kind of couldn't quite understand what a non engineer would do. Like, you're not writing code, what else is there? And so we're kind of suspicious of this idea. And we sort of, we went back to Jeff and we, we met Billy. He seemed like a wonderful guy. We really liked him. But we couldn't quite get past this, okay, but like, what does it actually, how does this work out in practice? And so Jeff told us that we should hire Billy, and for the first few months or whatever, that if it didn't work out, Jeff would sort of go back and pay his salary. So it's going to zero risk move for us. And so we did not have a whole lot of money at the time. So that was not insignificant. So we hired Billy. And that was sort of an immediately trajectory changing event, where previously when we'd gone and talked to a bank, I mean, I don't if they were literally doing this, but it certainly felt they're kind of pushing the security button under their desk. It's like why these guys in my office? And then suddenly things start to go kind of much more smoothly. And Billy is still with Stripe today. And he has been an enormously kind of pivotal presence. And so that was definitely very helpful advice.
Adora Cheung:
That is interesting. Jeff as an inflection point for Stripe, never knew. Cool. So, it sounds like you had hired actually people before Billy. I guess your very first hire, third person with you and John was an engineer, I'm assuming?
Patric...llison:
Well, he actually wasn't an engineer. But he joined Stripe. And he started to become an engineer. He'd written a little bit of code previously. But he joined, there was a lot of code that had to be written. He was a guy I'd known from college. He's actually also Irish. And we had a lot of code to be written. And so he was the kind of person who would sort of survey the landscape and just do whatever was most important and required. And at the time it was writing code. And so off he went.
Adora Cheung:
So kind of the transition from pre product market fit to post product market fit, a lot of CEOs, when they think back, this is the one point in which they think ah, I could have done that better. So how did you how do you grade your success of that transition? Because a lot of it is just taking stuff, delegating stuff better and doing other functions of the business. So, what exactly was your transition like? And how would you, how could I, if I was going in your shoes tell that I was doing it well?
Patric...llison:
Yeah, so I don't think I did it especially well, and I think it kind of fortunately sort of worked out. But I think if I was doing it all over again, I think we could have sort of accelerated ourselves by a year or two if we'd sort of going about it in a somewhat more disciplined and kind of self aware fashion. I think one of those kind of pernicious sort of mental models you can have here is that kind of you are on some growth curve, and it is sort of your job to sustain, or marginally inflect upwards, or kind of somehow ... Is curling the sport where you're kind of wiping the ice while the whatever it is, the weight, proceeds down along? Sorry, I'm not Canadian, but kind of, somehow, you're kind of making kind of these very small interventions and perturbations on some underlying growth curve. I think that's an easy mental model to have. And I think it's kind of actively kind of fallacious and mistaken. I think that a much better mental model have is you're serving some market, the market is, I mean, it's relatively finite in size. You can always change the project and increase the market size, but you can think of it as being finite. And then there's sort of the percentage of the market that you're serving, and then whatever percentage you are not serving is kind of you just haven't built the sort of go to market functions and organization that's kind of capable, or at least has yet sort of brought the product to those market segments. And that kind of the growth curve or adoption curve is just kind of a function of, of that go to market apparatus. But basically, it's not some kind of cosmic trajectory, it's something kind of very much of your creation and under your control. And so what we did not do but what I wish we did is kind of maybe whatever ... Just after we launched there's a whole bunch of immediate scaling work we had to do. But say, six months after launch, that we should have sort of mapped out the kind of concentric circles of our market, like, maybe there's kind of very early stage startups that were kind of our initial constituency. Then there's kind of all technical startups, but not necessarily very early stage. And it's kind of, I don't know, you keep going in these kind of successive increments until eventually you get to, say, all companies handling online payments or something, right? And [inaudible] figure out, okay, kind of what's the size of this market? What fraction of what we currently serving? What would it take to serve more? And so on. And I think it's quite striking, you see that kind of when repeat founders go and start companies, they almost invariably are willing to kind of build the organization post product market fit. So it's invariably willing to kind of build the organization ahead of where things are today. Which I think is exactly the right thing to do. Because they're thinking, Okay, I have the right product. Now, let's kind of work backwards from, Okay, what would the organism look like that was serving the entire market, and let's just start building that organization. Because, again, the growth curve is under my control. And of course, it's not like 100% under your control. But I think it's much more under your control than, than the things that people tend to think. There's also, of course, the difference here, a major difference when you can use or think about sort of consumer versus kind of B2B use cases. For a consumer it's a bit more, I mean, people don't necessarily know exactly what they want. What's the market size for a news reading app, or a dating app or something. I mean, it's, it kind of depends a lot on the products. Like maybe way more people should be reading news or something. But for sort of a, for some service or product that sort of serves a discrete logical, concrete function, that sort of set of businesses or entities to finish we have or don't have, I think it's kind of much more rational and much more mappable. And I partly had this epiphany when Aaron Levie, who's the CEO of Box ... John I eventually, we started in Palo Alto, we moved up to San Francisco. Aaron Levie had Facebook messaged John, and we'd never heard of him. We we hadn't heard of most people in Silicon Valley. But he Facebook messaged us very early on asking to invest in Stripe. And I think John didn't know, who's this random guy? And so we never replied, but then we heard of Box and we heard of Aaron, and we read his funny tweets, and all the rest. And so we moved to San Francisco and we invited him to our house warming. I think was the first time we ever met him. And sort of like, we're not very good at partying. And so by sort of 11 p.m. Or midnight or something kind of everyone was going home. But Aaron was still there, and Aaron stayed until, like 2 a.m., I still remember kind of sitting in our friend room telling us how much better it was to be building B2B software than consumer software for this reason. Sort of consumer software, it's so hard to predict sort of what people want, they don't even know themselves what they want. It's such an amorphous space. Whereas when you're selling software to businesses, businesses are kind of mostly rational, I don't know what the opposite of inscrutable is. Scrutable, I guess. And so you can sort of work backwards in a way that sort of, it's just much more comprehensible. And so I still have this kind of ... It's like the angel and demon on your shoulder, I still have 2:00 a.m. Aaron Levie sitting on my shoulders of extolling the virtues of building software for entities that know what they want.
Adora Cheung:
You've made the right choice. Yeah, in some sense there's a lot less variables, or in consumer there's a lot more variables to to consider. And they're quite unknown. I want to take a step back, you talked a little bit about thinking ahead about what your team is, or what your company structure is going to look like. How do you ... Maybe this is too big of a question. So maybe we can whittle it down a little bit, but how do you think about that? Like I'm sitting, if I'm starting a start up today, I'm close to maybe product market fit. But before that stage, like am I thinking about this sort of thing, like, what should my team look like? What should my culture be, and stuff like that?
Patric...llison:
I think that ... Well, okay, so pre product market fit. The goal is really just to [guess] your product market fit. And so I actually wouldn't bother thinking too much about all these kind of distribution mechanics questions. Now, you can get product market fit sort of relatively quickly. And so, kind of, that pre product market fit stage might only last six months. You're not necessarily like Stripe where you're kind of in it for various reasons for multiple years. And so it may not last very long. However, until that point, I really think you should just be thinking about, okay, how do I get there? The main thing I think companies screw up at the pre product market fit stage and is sort of speed of iteration. Speed of fruitful iteration. If you're repeatedly rebuilding your products, but not in response to user feedback, I mean, that's kind of far less likely to be kind of bringing you in sort of a, in a productive direction. But if you have some kind of meaningful, albeit perhaps small initial set of users and you're rapidly iterating a response to sort of their feedback and sort of observed behavior and so on, then I think that's like a really good spot to be in. And I think, again, at that juncture, pre product market fit, it is kind of this, you should be sort of doing everything you can to tighten that sort of feedback cycle. There's a fighter pilot who kind of revolutionized airborne combat in the US in the second half of the 20th century, so Korean War onwards, called Boyd. And he had this concept of the ooda loop, which was sort of a similar notion of ... Previously [inaudible] just like the fastest aircraft, or the most sophisticated weaponry and so on. Where he was all about sort of no, you actually want to aircraft and sort of pilots and training that are really oriented around sort of the the fastest responsiveness and iteration to the particulars of the situation. In the way that kind of subsequently went on to really inform modern aircraft design. And so I think you want to be like one of these sort of these modern fighters. Where you're sort of really optimized to respond as quickly as possible to sort of rapidly evolving situations. Again, in this kind of pre product market fit stage. And so then, from a hiring standpoint, I think it should really be about okay, well, what's going to get you there faster? And I mean, I think at an early stage it's most likely people will help you kind of build a product. But of course not too many. Because, I mean, at some point, like, you might be able to do more, but you might actually be less responsive, because you have a bigger team to manage or something, right? And so as an empirical matter, it seems that somewhere between kind of, to intend, depending on exactly what you're building is kind of the optimally responsive size. But I think it really is about that sort of time from observed sort of necessity or deficiency, or just characteristic of your users' behavior to executed fix, or improvement. And whatever it is that kind of minimizes that.
Adora Cheung:
Is there, I mean, you say, two to ten, which is helpful. But is there, are there observations or evidence in which you have hit the peak, like, you should not add an ... This extra person is going to be negative value add to the whole operation?
Patric...llison:
Yeah, I mean, every person ... Well, startups in general, involve all these kind of impossibly difficult sort of judgment calls in this kind of high dimensional possibility space. And so, it'd be great if you could sort of collapse it down to kind of a fairly simple set of trade offs, it's just I don't think you can. However, I think in principle the calculation you're sort of trying to run is okay, each successive person takes time to hire, and so slows us down in that regard, takes time to onboard slows down that regard. Kind of takes time to just kind of meld with the culture and learn the stack, all that stuff, that that also takes cost and time. Then involves subsequent ongoing cost of just like coordination and alignment. The organization is now distributed across more neurons. And so, there's that kind of persistent tax. And that's not just necessarily a linear cost. But it can be sort of quadratic or something, kind of given you have the multi way communication problem. So you have all these costs of an additional person. And so the question is, okay, but this person can help us like get more shit done, right? They can write more code or talk to more users or whatever. And so it's kind of, is that fixed benefit to sort of that additional person worth all these other costs? And again, with I think the ultimate arbiter being, will we be more responsive to what we're learning about our users, given the presence of this additional person? And I think whether or not you will be depends on the complexity of the product and the complexity of the market, and all that stuff. But I think that's [inaudible] the calculation you want to be running.
Adora Cheung:
I've heard you said, speaking of hiring people I've heard you say the key qualities that you look for in a future Stripe employee is intellectually honest, cares a great deal, and just loves getting things done. Which are great attributes, because some people just don't fit in those categories. So, it's good to have the separation there. How do you ... When you meet someone, how do you figure out this is the right person?
Patric...llison:
It's very hard. I wish I had a more sort of definitive rubric, and a particular set of questions. Although if I had a particular set of questions, maybe they stop working, because people would learn how to game them or something. And so, I mean, it's hard to fake just being smart, right? And so that ones kind of not as hard to discern. And it's oddly hard to fake being intellectually honest. And the characteristic of being able to see multiple sides of a debate or an argument. There are so many kind of complicated questions where sort of the only think that I'm really skeptical of is certainty in either direction. Just because the questions are intrinsically, involve very contingent trade offs. It's also, it's not impossible, but it's hard-ish to fake just being nice. Like, something we care a lot about at Stripe is just sort of people who are pleasant, and warm, and sort of make others happier as a result of their presence. And, you know, if you can fake that perfectly forever it's fine, right? But yeah, they're all sort of ... Actually there's no clear rubric for them. And I'm not sure that a clear rubric could even work.
Adora Cheung:
So you talk about get people who help move the organization faster, if at all possible. And I think there are two issues usually that start slowing down the organization as you start scaling, just because each person adds just more complexity to the organization. But also I think one is asymmetric information. Just, people are never on the same page. And I think, you've talked a lot about this, I think. Everyone can Google around for lectures you've given on this, you've done email transparency. Obviously having metrics transparent to the whole organization. But the second problem to that is if you fix that there's also this asymmetric interpretation problem. Which is everyone's ... There's this, like, black box function to how people interpret ... Even if all the inputs are the same, the outputs are all different. And especially at your scale now, it's nearly impossible to figure out everybody's function. So, when you're thinking about quitting your organization and building it out, like, how do you reduce that noise, and try to get everyone on the same page?
Patric...llison:
Well, the first thing is I wish we had actually ... Between say, five and fifty people, I think we were much too consensus oriented. We of course weren't completely consensus oriented. I mean, we couldn't have gotten anything done if we were. But I think we kind of biased too much in that direction. And it's just not that efficient. And then sort of, it's necessarily not the case. And so, kind of, you can sort of perhaps maintain some kind of fiction for, you know, more or less time. But sort of ultimately speaking, there is no way of sustaining that. And I think that's a relatively common mistake. Because you almost invariably come from some kind of [N Muskateers] , small [N] sort of orientation, where there's no particular need for formal decision making mechanisms, or sort of subsequent communication of said decisions or whatever, right? But then you hit 15 people, and now there is. And I think companies don't adjust quickly enough to that new necessity. Again, very much us included. And so, actually I think we did relatively well on the kind of ambient availability of sort of context, information, so on. But actually kind of in some sense poorly at sort deliberate, explicit communication of decisions. Decisions being, I mean, actual kind of tactical decisions, or even bigger decisions like what are our priorities the next six months, or things of that nature. And so the high order piece of advice, and perhaps I'm over extrapolating from our personal experience, but the high order of advice, just kind of reflecting back would be to kind of ... It's kind of like the pre and post product market fit thing, except it's actually about the size of the organization, where kind of, when you hit a certain size, again, I'm just gonna say ten people for the sake of simplicity. Maybe it's a bit before, a bit after. I think you have to kind of adjust more deliberately to this kind of explicit communication model of sort of, of being sort of quite firmly non consensus based, and sort of ... Nobody likes the idea of being hierarchical. That sounds pejorative. But like, in some sense hierarchical.
Adora Cheung:
Sort of the top down, it does move things faster. Maybe some people don't like that.
Patric...llison:
Yes
Adora Cheung:
But it does move faster.
Patric...llison:
That's right. And the reason is it's kind of a delicate balancing act. You want to sort of orchestrate, where kind of on the one hand you want to sort of really prioritize speed and agility, which involves being kind of somewhat hierarchical, because those are sort of efficient, sort of symmetry breaking mechanisms, and ways to have shots get called. But, like I said, you really do want people to have this kind of strong ownership mentality. And real sense that sort of, that they can cause things to change, or identify problems, or sort of inject new ideas even in unrelated areas. And so it's this delicate act where, I mean, you definitely can be excessively hierarchical. But sort of, how do you sort of facilitate enough autonomy and agency, but also not have things devolve into this kind of, I don't know, sort of uniform morass of brownian motion. And I think that's hard, and requires all these kind of ongoing tweaks and nudges. And I mean, depending on the personalities involved and all the rest ... And, again, I really wish there was kind of the sort of rote simple, we'll just to X, Y and Z and you'll be good. But sort of, if such X, Y's and Z's exist, no one's told me yet.
Adora Cheung:
If only there was a formula for everything.
Patric...llison:
If only.
Adora Cheung:
So, riding on the same theme, as Stripe grows, you strike me as a company that does the opposite of most companies, which as they get bigger they just slow down and they get less innovative. But for you guys, and it's hard to even keep up, you're just pumping out new products. Which seem to be successful to me, like Stripe Atlas, Stripe Press, Stripe Terminals, and so forth. So, in the early days, when there's just nine or ten of you, if someone had a new idea, it's probably really easy to get to you, and then you guys would decide. How has that changed over time to make sure that someone who's six degrees away from you, that a good idea actually gets to you, and then how is that decision made to actually execute upon it?
Patric...llison:
Well, it's very nice of you to say that you feel like we're getting faster as we get bigger. We're constantly sort of self flagellating over how frickin' slow we are. And, like, paranoid about sort of degenerating into some kind of immobile stupor. And so, to whatever extent we do get things done, or appear fast, I think it's largely because we, we're very paranoid in this dimension. And I think kind of the default outcome of companies, of course, as they scale is to become sort of more ossified, and rigid, and sort of closed to new ideas, and directions, and things that contradict their prevailing orthodoxies and all of that. As to how we kind of avoid that, I mean, there's lots of kind of obvious things. Like, partly it's sort of having leaders that care about the rate of progress, and just love seeing things happen quickly, and lots of things of that nature. I think it may be sort of deeper rooted is we try to be a kind of yes and culture. In that, I mean, I personally love ideas, and potential things we could do. I mean, most of them are ... I mean, no matter how good the idea is we should not pursue most ideas. Even if independently it can be a super successful company or something, but there is a fairly finite number of things we can do. And so, sort of, you kind of on the one hand need to recognize that intellectually and just not pursue most things, while on the other hand enjoying the exercise of contemplating, "Well, how would it look like if we did it?" And so, one thing we do every year, for example, is we have this kind of crazy ideas process we call it, where we literally send a document to the whole company, a [hackpod] document that's open to everyone. And people can sort of add ideas to it that they think are probably a bad idea, but if they worked, might be a great idea. And it's very important that they have to be probably a bad idea. Because if they're probably a good idea then it's not that risky, and I mean, kind of definition we should probably do it, and so whatever. Maybe we should just do it. And so, people really self censor a lot in most organizations, because they don't want to look stupid, and they don't want to sort of associated with just having all these wacky, bad ideas and so on. And so, we try to be fairly firm that if you add ideas to this, it has to be probably a bad idea. And actually a lot of cool things we've subsequently got on and done first came from that process. Stripe Atlas being one of them. And also we sort of helped Stellar get off the ground, this sort of cryptocurrency back a few years ago. And that also sort of came from this process. And so, that's one of the mechanisms by which we try to have a kind of yes and culture. And I really think there aren't that many, just as an empirical matter there aren't that many large organizations that I think sort of really do this successfully. But I think that sort of the most successful larger organizations somehow do succeed in sort of this iterative, repeated process of kind of augmentation. Amazon and Google being the most prominent examples. Obviously when Google launched there was no Gmail, or YouTube, or Android, or Google Maps, or whatever. And Amazon is kind of an even more conspicuous example, in some sense. This kind of repeated attach of successful ancillary businesses. Yeah, it's a very natural temptation as you grow to, I think, become increasingly close to this. I think it's very important to avoid.
Adora Cheung:
Cool. So, I have couple more questions, and then maybe we'll have time to take questions from the audience. One is, looking back, is there something ... Did you have a strong opinion of how startups should be run as a CEO that have just completely reversed because you're now the CEO?
Patric...llison:
That's a good question.
Adora Cheung:
Another way to potentially put it is what are things that you did where you're like, "I know for sure this should have been done," and then just turn out to be a mistake?
Patric...llison:
Well, I already mentioned the sort of, the consensus orientation. The one that we're going through right now, which is a quite significant divergence is we were sort of fairly centralized up until sort of relatively recently. I mean, we had some remote employees from a pretty early stage. But by and large Stripe was kind of concentrated in San Francisco. And last week we announced our fourth global hub. And basically what we've decided to do is we're gonna have kind of major sort of product and engineering efforts, and teams, and functions, and all the rest, in San Francisco. Also in Seattle. Also in Dublin, and also in Singapore. And so that these non San Francisco locations are not gonna be sort of operations offices, or satellite offices, or places where we do sort of localization, and local market adaptation. We want to have kind of completely [denovo] new products that sort of become super successful started out of these offices. And that's not the sort of standard, obviously, kind of Silicon Valley pattern, where sort of Apple, and Amazon, and Facebook, and Google, and all these companies tend to be sort of highly concentrated in these sort of very sort of monolithic corporate headquarters. And our thesis is kind of several fold. Partly that the availability of talent is becoming far more geographically dispersed, partly that sort of the Bay Area is becoming an increasingly untenably expensive location to locate. And partly that sort of, we really want Stripe to be global infrastructure that works kind of just as well in sort of Asian markets or in Latin American markets or whatever, as it does for businesses in the U.S., and kind of the era of the internet being sort of a predominately North American, or North American, western European or whatever. The days of being kind of such a phenomenon are over. And so, I think that's sort of a fairly substantial break with kind of, you know, descriptive best practice of the past. I mean, we obviously think it'll work, we wouldn't do it if we didn't. But it is also, on some level, risky. We don't have good, you know, prior examples to point to. And there's some great companies in Singapore, like Grab and Carousel, but there aren't really any examples yet of sort of American companies establishing kind of major product and engineering hubs there. We're pretty optimistic it can be done. But, you know, if it works we'll be the first, or one of the first.
Adora Cheung:
Cool. Last question. So, in a hundred years from now, what is Stripe gonna be? What do you imagine it to be?
Patric...llison:
We're only seven years old. So, that's a difficult question to answer. I mean, we're trying to build this kind of economic infrastructure for the internet. And this sort of platform for globalization, and kind of, I don't know, sort of technological progress in the sense that it ought to be just as easy to start a company in sort of Nigeria as it is in New York. And it should be just as easy for somebody in Brazil to buy something from any of these companies as it is for, again, somebody in the western world. And it just seems so crazy to me that that hasn't happened yet, it sort of feels that Stripe should have happened 10 or 20 years before it did. And I don't so much think that we're sort of pursuing this kind of unprecedented kind of inconceivable idea, so much as sort of correcting a deficiency in sort of a rip in the fabric of internet infrastructure. And so, anyway, I think we still have at least five years to go in sort of correcting this inadequacy. So, what happens after that I'm not sure.
Adora Cheung:
Got it. In some sense, in the future all transactions should be digital, and they could very well just be all going through Stripe. I mean, right now in the U.S. Someone was telling me, like, 80% of all Americans have done some transaction through Stripe, right?
Patric...llison:
Yeah, that's right, in the last 12 months more than 80% of American adults have bought something from a Stripe business. At least one thing from a Stripe business. And it's not just the case in the U.S., like in Singapore where I was last week, that figure is about 70%. But I guess we don't think about ... Well, I think about it more in terms of the things that are possible, or get started. As in, we think a lot about the rate of sort of new firm creation, what companies are getting started, how successful are those companies, which markets can they serve and so on. And every now and again we look back, and we look at sort of those kinds of market coverage stats. But I guess that's not really what motivates us. It's more that sort of are these businesses that should exist, and/or should be able to offer their products and services in these places where they currently can't? And that's the kind of thinking that we use to kind of inform the product, and that sort of is kind of the core locomotion day to day. And then maybe the outcome of that is that all these people get to benefit from it.
Adora Cheung:
All right. Thank you so much, Patrick. This was great.
Patric...llison:
Thank you.
用户评论