Stripe, A Modern Product Rocket 🚀
Stripe, A Modern Product Rocket 🚀
The private $100B company is rewriting the product growth playbook
We are all at least 25% more interested in Stripe because we cannot get a peak under the hood. This has made for the stuff of several amazing profiles.
But, what exactly is its legendary product strategy? What lessons can product leaders take from Stripe? Enter this piece.
It all starts with day one.
Lesson 1: Make Something Your Customer Needs to do Easy
2010
Like many great products before it, Stripe grew out of personal frustration. After selling his business for eBay power sellers, Patrick Collison was debating with his brother John why it was so difficult to accept payments on the web. The two “were really appalled” how hard it was with existing products on the market.
So they set out to build a better product. To kick-start the company, they raised a $20K round from Y Combinator. The brothers spent six months on a prototype to make accepting payments on the web dead simple for developers. They pioneered PayFac technology, which allowed developers to accept payments with a few lines of code, instead of going through a lengthy list of arduous tasks: payment gateway setup, credit card storage, PCI compliance, and bank management.
Two weeks after launch, they acquired their first customer. Patrick had offered to write the code to switch off PayPal checkout for another Y Combinator participant. From there, it was off to the races.
Product market fit was almost “instant.” Word spread like fire. It is amazing to hear Patrick describe how the virality surprised the young co-founders:
Initially it very much spread through a word of mouth process. That was surprising to us because it’s a payment system, not a social network, so it’s not something you’d think would have any virality whatsoever. But, it became clear that everything else was so bad, and so painful to work with, that people actually were selling this to their friends.
Few products spread this way. How exactly did Stripe? It made something customers needed to do easy. Developers have high standards, and they talk to one another. Stripe meeting those standards led to continued growth for Stripe. They replaced the lengthy enterprise sales cycle with a direct to user model. They turned exceptional customer experience into a marketing strategy.
This early on in its life, Stripe, for its core payments product had already locked on its key customer, persona, problem, and solution. “Stripe is a company built by developers, for developers,” as the saying goes.
This was not a straightforward choice. Historically, the CFO was the ultimate payments decision maker. Surely, some of Stripe’s early advisors would have advised against it, but Stripe stuck to its focused user persona. There is great power in focus. It allowed the product and engineering teams to build for that single persona, instead of everybody.
Lesson 2: Don’t Jump Into Big Marketing & Sales Spend
2011
Come time to raise money, Stripe put together a buzzy seed round. It was a “who’s who” of Silicon Valley investors, including Peter Thiel, Elon Musk, Sequoia Capital, Andreesen Horowitz, and SV Angel. Stripe raised at a $20M valuation.
The crazy thing? The company had done almost no marketing. When Michael Arrington at TechCrunch wrote about the raise, he did not know much about the product. He had to ask for the basis we all now know:
“How is it different than PayPal or Google Checkout?” I asked someone who’s seen the product. Their answer – “It doesn’t suck.”
Stripe focused on product development, so the product did not suck.
It is worth reflecting on the competitive pressure Stripe would have faced to scale sales and marketing. Braintree was founded in 2007, and in 2011 it already ranked 47th on Inc. Magazine's list of the 500 fastest-growing companies. Braintree was building a similar product, for a similar market, with 2 years head start. After Stripe’s March raise of $20M, Braintree followed up in June with a raise of $34M.
This is one of the moments where companies define themselves. Instead of going the marketing/sales route, or the hybrid route, Stripe chose product growth as its strategy. According to Chief Financial Offier (CFO) and Chief Product Officer (CPO) William Gaybrick, the sales team was “diminutive,” and they only had 1 marketing person. Most SaaS companies establish a large outbound sales motion after raising at a $20M valuation. Not Stripe.
Lesson 3: Build for Platforms and Marketplaces
Much of the economic activity of the internet goes through platforms. Stripe’s original product was a better fit for single websites and merchants. So, Stripe built a new product for platforms.
In late 2011, Stripe launched its second product after Stripe Payments, Stripe Connect. Where Stripe’s Payments APIs are the easiest way for typical merchants to accept payments and move money globally, Stripe Connect is those APIs for platforms and marketplaces specifically.
Like Stripe’s first product, Payments, the Connect product was quick to establish product market fit. That is because Stripe did not just go to market haphazardly. It spent six months in production testing the product. It iterated from learnings, for example allowing customers to add optional fees, as well as adding donations in SubReddits.
Fast forward to today, and Connect is estimated to be one of Stripe’s biggest revenue drivers. Take Shopify, which has done about $80B in payment volume over the last twelve months. At a 2.5% take rate, and 38% gross margin for that segment, we can estimate Stripe received $1.2B in revenue from Shopify.
By building out payments for an e-commerce platform like Shopify, Stripe is able to access Shopify’s incredible growth. Part of the reason building for platforms and marketplaces works so well is a principle of Paul Graham’s:
A startup that helps people make money will make money itself.
Platforms help people make money. Stripe helps platforms. Shopify is not Stripe’s only big platform or marketplace customer. Stripe also has names like Lyft and Wordpress on the list. Stripe grows as these customers grow. This is how Stripe accomplishes its mission of building out the infrastructural rails for the internet. If Lyft and Wordpress are building out the roads, Stripe is supplying the cement.
2014
Lesson 4: Go Deep to Solve Problems Well
In 2014, Stripe became a unicorn. Many companies celebrate the opportunity by expanding their product offerings. Not Stripe.
Between Payments and Connect, Stripe could service most types of internet businesses’ core payment needs (it would add subscriptions later). So, for years, Stripe focused on these two products, instead of solving additional problems. It went deep, instead of getting distracted by new products.
How do you help your teams go deep? Stripe had four main techniques.
First and foremost, Stripe did this by going deep on its customers. To this effect, there is a great anecdote in The Generalist’s profile about Patrick in the early days:
[A]t any given time, especially when we were smaller, [Patrick] could ask about a particular deal you were working on, and he knew about that company and how they should be using Stripe…[H]e took the time to actually be plugged into the technology and the products and the business.
It takes a willingness to get your hands dirty to start examining each and every customer’s implementation of your product. Stripe does this all the way to the CEO level. Members of their product team have described user research as part of the job of “every team across Stripe,” because it is “a part of literally every part of product development.”
Stripe also went deep by taking on complexity. Stripe continued to add on complexity in the back end of these products, like ML, countries, currencies. But at the same time, it continued to keep it dead simple for the developer once it reached them. All APIs, for instance, are backwards compatible. No new push will make old code stop working. This manifests itself in a design principle. As former Stripe employee Brie Wolfson put it:
Good API’s make things easier by providing a layer of abstraction between complex systems
Another technique Stripe used to go deep is adding scale. At the Stripe keynote in June, it shared that in the last 12 months it had 99.999% uptime over Black Friday and Cyber Monday. For a company that handled 173 billion API requests in a year, that is phenomenal uptime.
Finally, Stripe went deep by moving fast. Being deep does not mean moving slowly. Actually, Stripe is explicitly focused on speed. As John Collison explains, “speed is of the essence, and a defensible trait in companies.” Stripe publishes updates to its core API 16 times per day. That is far faster than most companies.
How do product leaders help their organizations go deep? Stripe uses vision, strategy, and principles.
Instead of playing zero-sum games, Stripe formalized its mission to, “increase the GDP of the internet.” This is the product vision. The strategy is to build economic infrastructure for the internet. Stripe’s product leadership further adds context to this with its operating principles. As CTO David Singleton describes them:
1. Put users first
2. Spend time to make it good
3. Design your organization
This set of context provides a path for the product teams to go deep for years. We can put it all together:
There are six more lessons. Don’t miss them:
I hope you enjoyed the deep dive! As an email subscriber, you got first access. I also published 4 IPO analyses this week:
Will you be investing in any of these companies? I am most interested in Nykaa (story 1):
Everyone knows Facebook renamed to Meta this week. I want to talk about something else.
As a product leader who has to build compelling vision for large organizations, I love Zuck’s use of a film crew to show the metaverse vision.
Very powerful technique for product leaders 👌
Finally, I wanted to leave you with a mini essay:
On the Value of Less
Everyone wants to add to the product.
Features have cost.
Most have performance impact: bigger download, slower site, whatever.
Many also have UX impact: more ways for the user to go.
As well as more code to maintain.
Next time, maybe subtract instead of add.