Patrick Collison, co-founder and CEO of Stripe, discusses the early days of the company and their gradual expansion before public launch. He talks about the importance of user feedback and the "Collison installation" method they used to get users to switch to Stripe. Patrick also mentions that he and his brother, John, both run the company together and make decisions based on passion and expertise. He emphasizes the importance of efficient decision-making processes and the need for dispassionate disagreement.

- The speaker discusses the age difference between himself and his colleagues when they started Stripe.
- They talk about the role of a CEO before and after product market fit.
- They define product market fit for Stripe as when they launched publicly in September 2011.
- They mention that they focused on iterating the product based on user feedback and were quickly overwhelmed by user demand after launching.
- The speaker describes their approach to understanding user behavior and fixing issues, including monitoring API requests and reaching out to users who didn't go live.
- They emphasize the importance of qualitative feedback and being attentive to user experiences before product market fit.
- The speaker mentions using a text box to collect feedback from users, both positive and negative.
- They discuss the challenges and fulfillment of building Stripe, noting that happiness may not always be present in the moment but fulfillment can be achieved in retrospect.

- The experience of starting Stripe was not particularly happy, as they were aware of the product's deficiencies and faced many challenges.
- However, working with the team and serving smart customers made it fulfilling and meaningful.
- Progress may not be noticeable on a day-to-day basis, but taking a step back and evaluating progress on a monthly basis can show movement.
- It is important to find happiness, satisfaction, and fulfillment in what you're working on.
- Knowing when to quit and call it quits is crucial, as time has high opportunity costs.
- Stripe initially struggled with partnerships and working with banks, but hiring the right person helped change the trajectory.
- The transition from pre-product market fit to post-product market fit could have been done better, but it worked out in the end.
- The mental model of sustaining growth through small interventions is fallacious, and it is better to focus on serving a finite market and building the go-to-market apparatus.

- The growth of a startup is under the founder's control
- Mapping out the concentric circles of the market is important to understand the potential size and fraction being served
- Repeat founders are willing to build the organization ahead of where things are currently
- Building software for businesses is more rational and comprehensible than consumer software
- Pre-product market fit stage should focus on speed of iteration and getting to product market fit
- Hiring should be focused on individuals who will help build the product and minimize the time from observation to execution
- Each additional person hired has costs in terms of time, onboarding, coordination, and alignment
- The decision to hire should be based on whether the benefits outweigh the costs and if it will make the organization more responsive to user needs
- Key qualities in a Stripe employee include intellectual honesty, caring a great deal, and a love for getting things done
- It is difficult to determine if someone is the right fit for a position, but being smart cannot be faked.

- The speaker discusses the difficulty of faking intelligence, intellectual honesty, and kindness.
- They mention the challenge of reducing noise and getting everyone on the same page in a growing organization.
- The speaker suggests adjusting to a more explicit communication model and being less consensus-oriented.
- They emphasize the need for a balance between hierarchy and autonomy in order to maintain speed and innovation.
- The company encourages a "yes and" culture and has a process for generating and considering new ideas.

- The speaker discusses the importance of fostering a "yes and" culture in organizations.
- They mention that few large organizations successfully implement this culture, with Amazon and Google being notable exceptions.
- The speaker also talks about their experience as CEO of Stripe and how their opinions on running startups have changed.
- They mention that Stripe has recently decentralized its operations, opening global hubs in Seattle, Dublin, and Singapore.
- This decision is based on the belief that talent is becoming more geographically dispersed and that the Bay Area is becoming too expensive.
- Stripe aims to be a global infrastructure that works well in all markets, not just North America.
- The speaker acknowledges the risk involved in this decision but is optimistic about its potential success.
- The ultimate goal of Stripe is to build economic infrastructure for the internet and make starting a company and conducting transactions globally as easy as possible.
- They mention that currently, a large percentage of Americans have made transactions through Stripe, and they hope to expand this reach globally.
- The speaker emphasizes that the motivation behind Stripe's work is the belief that there are businesses that should exist and offer their products and services globally.

- Patrick Collison, co-founder and CEO of Stripe, discusses the early days of the company and their gradual expansion before public launch.
- They emphasize the importance of user feedback and the "Collison installation" method they used to get users to switch to Stripe.
- Patrick mentions that he and his brother, John, both run the company together and make decisions based on passion and expertise.
- The importance of efficient decision-making processes and the need for dispassionate disagreement is highlighted.
- They focused on iterating the product based on user feedback and were quickly overwhelmed by user demand after launching.
- The challenges and fulfillment of building Stripe are discussed, noting that happiness may not always be present in the moment but fulfillment can be achieved in retrospect.
- Stripe initially struggled with partnerships and working with banks, but hiring the right person helped change the trajectory.
- The transition from pre-product market fit to post-product market fit could have been done better, but it worked out in the end.
- Mapping out the concentric circles of the market is important to understand the potential size and fraction being served.
- Pre-product market fit stage should focus on speed of iteration and getting to product market fit.
- Hiring should be focused on individuals who will help build the product and minimize the time from observation to execution.
- The decision to hire should be based on whether the benefits outweigh the costs and if it will make the organization more responsive to user needs.
- The company encourages a "yes and" culture and has a process for generating and considering new ideas.
- Stripe has recently decentralized its operations, opening global hubs in Seattle, Dublin, and Singapore.
- The ultimate goal of Stripe is to build economic infrastructure for the internet and make starting a company and conducting transactions globally as easy as possible.

YC Partner Adora Cheung, along with Patrick Collison, the founder of well known YC alumnus Stripe, discuss how to most effectively run a startup company towards success.

Learn more at https://www.startupschool.org/

So Patrick is the co-founder and CEO of Stripe.

He launched the startup, or now pretty big company, in 2010, correct?

Well, actually, we started working on it full time in 2010.

But actually, to your comment just there about companies launching, it took us quite a while to launch because we had all these kind of banking partnerships in place and so on.

And so we didn't launch until September 2011.

We'd been working on it for almost 2 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 had not launched yet.

It was, I think, 1 year and 11 months from first line of code to public launch.

It's just we had to, because we had to get all these other things in place.

And because it took us so long to be able to publicly launch, we tried to be very disciplined about gradually expanding the number of users every month.

And so even though we weren't publicly available, we got our first production user just 3 months in.

And then every month, we tried to add at least a handful of users.

And so by the time we publicly launched, we did have about 100 users, which I mean, back then to us, that seemed like a big deal.

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 installing their API 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 happens so much that actually, I don't know if you know, Paul Graham, PG, now calls it the Collison installation.

And this is actually something we tell founders to go do this, do the Collison installation, because obviously, in hindsight, it seems so obvious to do.

I mean, it served as a really good way to do user research and to get UX feedback and so on.

And if you've done this, I'm sure you've had the experience where you design what you're absolutely certain is the most streamlined, user-friendly, straightforward, frictionless way to do whatever it is the product does.

And then you present it and put it in front of a user and you just 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 so it's invariably sort of incredibly painful, the sort of nothing so sobering as watching somebody use 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 or whatever.

And invariably, the response is, oh, yeah, sure.

But they'll postpone it, and they'll postpone it again.

And it's just like there's never a moment where it's like, OK, 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.

It's always like a why you and a why this and a 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.

Although, perhaps we should have, but no.

We tried to be kind of at least semi-invited.

So Stripe now today, I mean you've come a long way since back then, I mean it's not even been, it's really been a decade, not even.

But I mean today you're, well you have 1,300 employees across 9 offices across the world.

You manage 200 million API requests a day, you process billions a year for millions of companies across 130 companies, your latest round of funding, Stripe is now worth $20 million.

Anyway, the list keeps going 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, I guess, the time today talking about running your startup from the perspective of the startup CEO, you yourself.

Like 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 discussion, 1 thing is, you know, when you start off, you know, when 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, ah, 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 a great leader.

How did you and John decide you would be the CEO?

Well, I think Stripe is unusual for, John and I are 3 brothers.

And, you know, because of the relationship, we're able to 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, I'm the person who, in the case of disagreement, it's not always the case that I prevail.

Our dispute resolution framework is much more around which of us cares more than kind of which of us holds this title or that.

And I mean, John's title is president, and so there's kind of some, I don't know, both are significant roles.

And so, yeah, 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, we're able to kind of get to this unusual situation where we really do run it together.

Which, sorry, may not be a helpful answer because perhaps you're trying to encourage all these companies, it's like, you know, shit, 1 of you guys has got to be the CEO, but.

Do you think there's like a rubric for this of, you know, here are 5 questions you should answer and maybe then you decide.

I will say 1 thing, which is I think it is important to have an efficient mechanism for reaching a decision and it can't be sort of simply oriented around consensus, right?

If there are sort of 3 co-founders and sort of none of you sort of quite want to, or, you know, nobody's a clear CEO and you don't have some kind of efficient mechanism for having decisions get made, I think that is a recipe for failure.

And even doing some kind of quasi-democratic voting is probably not a great idea either.

And so for myself and John, we both have areas we respectively specialize in.

And so that doesn't mean we have absolute autonomy and authority there, but 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 internally on a lot of 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 secondly, we have this kind of additional aspect where, in the case of it being a major decision, and we sort of respectively disagree, then we really do sort of try to make it based on which of us is just more passionate about it.

Because that will correlate with the outcome.

1 of us really wants to do something or thinks that X or Y is the right thing to do, simply sort of wanting us to be so passionately is more, I mean, that can be a sort of self-fulfilling prophecy and so I think it's kind of not irrational to have that be a consideration.

And 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 get to that conclusion.

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, I think that 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 I don't know that this kind of the notion of disagreeing strongly is not sort of a scary phenomenon and the kind of both parties or multiple parties if there are more than 2 are kind of suppressing their feelings for fear of there being this divergence.

You have how many more siblings do you have?

Would you guys, would he join the Or is it just you and John, or is it a special match there?

Well, Tommy, my youngest sibling, he's sort of quite a bit younger than myself and John.

And so John is almost approximately 2 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 it just wasn't quite practical at the time.

And now I think if you asked him, he'd probably say he'd never throw his lad in with miscreants like us.

Cool, so in terms of the role of CEO, often people say There's a threshold in time in which, and it's related to product market fit, where you have a role as a pre-product market fit CEO, and then which is completely different from your role as a post-product market fit CEO.

So I wanna 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?

What number of employees you were at when you reached it, so on and so forth?

And I think you're exactly right to divide things into sort of, the story of a startup is 2 stories.

It's a story of getting to product market fit and then the story of what happens subsequently.

And obviously there isn't a totally definitive binary line between them, but I think it's helpful to frame the narrative in that regard.

And I would say for Stripe, 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'd rebuilt significant components of Stripe 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 evident challenges that users had or the deficiencies the product seemed to possess.

And when we launched, we were basically immediately bottlenecked on being able to serve user demand rather than generating user demand.

And I think directionally, that's kind of the inversion that happens, where in the early days, you're really trying to figure out, well, OK, conditioned on or given 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 at some point it flops for, 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 100 users, the curve asymptotes downwards.

And then you take 100 users and again, a meaningful fraction end up engaged.

And they actually tell more people about it or they sort of invite people.

I don't mean kind of strictly just in a viral sense, but just kind of generally speaking, does that kind of lead to and generate more demand such that things seem to be sort of in some super linear fashion kind of growing.

And I think when you sort of, like being kind of less than 1 is just very different to being more than 1.

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.

When you launched, how many people were you at at that point, please?

So I guess before you launched then, your day-to-day sounds like it was just like we were talking about earlier, just running around, talking with users, and fixing issues.

Was that literally every single day was like that?

OK, So not literally every single day, but I would say we really tried very hard to understand in very granular detail 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 providing support when people were integrating Stripe.

And it was actually a public chat room, which had some downsides, because if we'd broken something or if 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, sort of for the first, I don't know, call, 10 users of Stripe, every time somebody sent an API request to Stripe, like it sent an email to us.

So we were looking at every single API request.

And if we saw users do something weird, we're like, well, why did they do that?

Or where were our docs confusing or whatever?

And so I'd get out of dinner in the evening or something.

Well, again, it seemed like a lot of the time out of maybe 10 emails, because Stripe was not handling a lot of API requests back then.

But you're literally looking at 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 29.

And so I was looking at our sort of, we had an hourly stats email that we used 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 3 or 5 or something API requests, but it's sort of not gone live.

We literally just had the emails of all these businesses.

The idea was that we would then kind of, we would literally individually reach out to them.

It's like, hey, you kind of seem to use Stripe a little bit, but you know, 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 a high priority email to us.

And so we would try to immediately go solve it.

And that also kind of generated, I think, this pleasant kind of user experience, where it's frustrating when you hit an error in some service.

But we could then often, 15 minutes later, reach out to them and say, hey, we saw that you've encountered this problem.

And sometimes we did it even in the case where the user just made a silly mistake, and they mistyped an API parameter or something.

And we just reach out to them and be like, hey, I noticed you had a typo in your code, which perhaps some of them was a little bit unsettling, but at least helped us increase the throughput of product feedback.

But so, I mean, these are all kind of examples, I'd say, of the general pattern of really trying to be kind of hyper attentive to all the micro details of what people were doing with the product and iterating rapidly in response to it.

And generally speaking, I think that pre-product market fit, metrics are actually relatively unhelpful.

I think you really want to buy as very strongly towards as much inspection and 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 in some sense afford to just look at everything they're doing and try to understand what's working, what isn't.

Yeah, in some sense, you can tell subjectively how much they love your product, or how much are they gonna probably be really upset if it just disappears.

Totally, and actually on this point, we had a thing at the bottom of every webpage, we had a little text box, kind of anchored to the bottom of the browser frame.

But we had placeholder text in it to try to prime people to tell us things.

And so it had my favorite part of Stripe is ellipsis.

And people would just fill it out and hit Enter.

But we also, of course, had most of the prompts were negative.

It was like, the worst thing about Stripe is, or the worst thing about this page is, or I really hate the way Stripe does, or whatever.

And again, we would 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 a helpful to-do list for the day ahead.

Like in the early days, before I reached out, I was like, I'm always complaining.

So, I would say it was, well, happy is such a squishy concept, right?

And because there are lots of things that we, I guess, when I look back, and look, Maybe this is the rationalization I tell myself.

But when I look back through life at the things that I'm most glad I did, I wasn't exactly happy while doing them.

Often I was very stressed out, or I had to work really hard, or whatever.

But they're the things that post-hoc brought the most fulfillment.

And I think that, well, whatever, there's a rich literature here and so I won't dive too deeply into it, but I do think happiness is a tricky concept to pin down because is it happiness in the moment?

Is it sort of the sense that you have a year later looking back and so on?

And so I think, you know, language is squishy and it's not, you know, completely specifically defined.

But I think kind of 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, you know, constantly sort of 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 2 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 did feel kind of fulfilling.

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 were just businesses doing all these wonderful things, and they were really smart people.

And it felt that if it worked, it could be consequential in the world.

And so I would say It sort of felt like, I mean, I don't know what it feels like to be a scientist or something, but I'm guessing when you're pursuing, you have this big question and you're pursuing all these avenues to try to better understand it, and I'm guessing day to day it's not especially happy because most of your experiments don't work or whatever, but sort of in perhaps there's some analog there in terms of it still feels in some sense meaningful.

Yeah, there in some sense, I mean day to day, like you said, you're just 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 what progress have I actually made?

Because week to week, it's like 1% here, 1% here.

But from a monthly basis or maybe longer than that, it seems like there's movement.

And I think it's almost certainly a bad idea to sort of work on a company or to work on anything if you're like truly unhappy working on it, right?

And so there's kind of cheerleaders and balancing act there.

And I think, I mean, a lot of, well, there's sort of so many different sort of difficult judgment calls to try to make in a startup, but of course, part of it is, like, if something is making you unhappy, or if it just doesn'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 startup then we really extol and sort of uphold the virtues of sort of determination at all costs, you know, never quit, and so on.

And that's clearly not the right answer, in that like sometimes you should quit.

And so I think what you're getting at is true and right.

I think there does need to be 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.

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 stacks of documentation and taking like 5 days to figure it all out.

And so I sat down, I was like, because you guys are saying, oh, it'd take you 10 minutes.

And it probably took me actually 5 minutes at that point.

I mean, that's like, but maybe I should have sent you a review.

Yeah, I mean, that would have been great, especially if the review had a sort of criticism for us.

But no, it's definitely helpful to have competitors with not very good products.

OK, so you were, in the early days, you were doing a lot of stuff yourself.

1 is, what are the things that you weren't good at?

And then 2, at what point did you hire someone to, what I assume is to do those things?

Well, I mean, I'm not thinking of most things, right?

And I say this in a non-false modesty, or I don't mean to be kind of artificially self-deprecating, but sort of for almost anything that Stripe has to do, there are sort of people who are better at that than I am.

And so I think to some degree sort of the story of say, you know, product market fit and to, you know, say our current stage is kind of implementing the recognition of that in more and more areas.

That said, I think maybe sort of embedded in that question is, OK, well, acknowledging that you're probably not the world's expert in any single thing.

It's kind of in what order do you sort of replace yourself.

And for Stripe, the important thing that we were most obviously not that great at was partnerships and working with the various banks that we had to get on board and so on.

See all Y Combinator transcripts on Youtube

Running Your Company by Patrick Collison