Where Does Stripe Go From Here?

Where Does Stripe Go From Here?

You can break the life of a startup into few stages: it starts with early experimentation, leads to an initial product-market fit, and is followed by a period of peak variance in total value created—a time when a company's model works well enough for there to be a viable business, the rate of fire drills has reached a semi-manageable pace, and there's finally room to ask "What do we want this company to be when it grows up?" There is a big gap between initial success and defining a company's long-term role in the relevant ecosystem, and not everyone survives; Fitbit, for example, defined a category early on but eventually turned into a feature of more fully functional devices, while Apple has managed to continuously broaden its mission and redefine itself.

Stripe is at the stage where the core payment product works—10% of the world population transacted through Stripe in 2022—and businesses like Issuing and financial management are valuable enterprises on their own. And they have a reasonable path forward towards an even more valuable version of Stripe, just from a linear extrapolation of the current business. But markets are dynamic, and extrapolators eventually extrapolate themselves into a corner.

I recently chatted with Will Gaybrick, Stripe's President of Product & Business, to talk about what the company is doing now and how they're adding more degrees of freedom to their model. (Gaybrick's career is good evidence for the model of aiming for an unconventional Venn Diagram of skills; he worked at Blackstone before the crisis, spent a few years as a software engineer at startups, moved to Thrive as a partner, then joined Stripe as CFO. Taking an unconventional path to the CFO role enabled double-dipping on unconventionality by switching from CFO to product roles, and then to his current position. Of course, that's rendered slightly more linear by the fact that money is, depending on how you think of it, either the key raw material in Stripe's product or the product itself.)

One element of Stripe's initial model was that they specifically targeted startups. That is, and should be, a polarizing decision:

• Consider the downsides: these customers have, structurally, the highest imaginable churn rate, since they're designed to fail fast if they can't grow. Founders often have no idea what they're doing—or, put more nicely, there are a few dozen things a small company needs to be competent at, and small, high-variance teams will probably be exceptional at a few of them and inadequate at many more. Since startups start from zero, they have no vendor lock-in, and they tend to assume that most of the tools they use will be up to the standards of tools they care about (i.e. their typical expectation for software they use is determined by Zoom rather than Citrix, or by Expensify instead of Concur).
• And for theupside: those high standards mean that the quality of customer feedback will be extremely high. The high failure rate is offset by high growth, which is especially valuable for a company whose revenue is a function of customer revenue. And being a one-decision product for achieving competency in something critical—collecting money from customers who wish to spend it on your business's goods and/or services is, typically, a mission-critical task for a company—is a nice source of pricing power.

Let’s start with the churn issue. In a payments business, churn can be broken down in a useful way: there's churn from customers who go out of business, and churn from customers who suddenly require a different payments solution. (This is just a vertical-specific way to think about involuntary and voluntary churn.) That means a payments company that targets high-growth customers has selected a daunting task, but one that they can define with reasonable precision; consider the customers who are adding the most payments volume to Stripe's total each year. Estimate what that payment volume will look like over the next year, make a list of everything they will need at next year's payment volume. And ship it in the next twelve months.

The beauty of this arrangement is that it can simultaneously focus on a) the needs of existing customers and b) continuously expanding the addressable market. For example, imagine working with DoorDash, a company that handled $57bn in gross order value in the last four quarters, and that pays out a few billion of that to a few million individual drivers. Handling their payments is not a task to which a tiny payments company is well-suited. But if a tiny payments company starts working with an equally-tiny business like PaloAltoDelivery.com, then the tiny payments company’s task is to keep up with them—which is certainly not easy, but it’s a lot more achievable through incremental progress. And, as a result, it means that the maximum customer size, and therefore the immediately addressable market, grows as existing customers grow.

But one thing that happens as organizations grow is that they become, well, more of an organization. At a small enough scale, a business can work even if the org chart, employee handbook, and business plan all exist solely in one person's head. But eventually, companies develop some kind of shape that’s independent of the personalities of the founding employees. And that changes which enterprise products the company buys and how they buy them. This Steven Sinofsky essay on enterprise sales talks about part of the process:

Every enterprise sales person I have worked with begins to build out the physical and logical org chart from the first engagements. You want to learn the management reporting structure as well as the power. You want to understand the budget and decision making processes.

At first, companies use products that solve a discrete problem. As they grow, the approach evolves: instead of a binary solution, there are typically multple metrics a sophisticated customer optimizes for. Big companies do not pay the sticker price, and when they compare different payment solutions they're thinking in terms of the tradeoff between transaction volume, the fees they pay, the implementation cost on their end, implementation speed on the part of the partner, the risk of lock-in, and a host of other considerations. A pre-revenue company adopting Stripe is about as convenient as buying a can of Coke, but a large company choosing a payment provider is engaging in a transaction whose complexity is closer to the complexity of doing a leveraged buyout of the Coca-Cola Company.

And that has shaped Stripe's strategy. As the size of target customers grows, pure payments becomes more commoditized, but payments-adjacent software turns out to be more valuable.^[1] The business started as a layer on someone else's abstractions, by making it easier for sellers to get merchant accounts. But over time, it's been a successful effort to make the abstractions around moving money more tractable. The asymptote is that the global financial system will someday have a comprehensive, well-updated user manual, and it will live at stripe.com/docs.

How does Stripe get there? At one level, this is a fundamentally incrementalist project: there are many economic actors that want to spend money, many that want to receive it, and many whose processes are more tractable if those flows can be abstracted and automated. Stripe has retained a surprisingly rapid launch cadence; there's an unfortunate pattern with companies as they grow that features shipped in a given time period divided by headcount drops over time, and sometimes incremental headcount has negative productivity. There's natural entropy at work there (legal reviews make sense when you're operating in many jurisdictions and are big enough to be worth suing; channel conflict doesn't matter when you have hardly any customers; more interoperating systems mean more exposure to edge cases). But it can be resisted. Stripe tracks metrics around implementation, from coarse ones like pull requests per engineer to deeper ones.

At small scale, there's a strict tradeoff between responsiveness and planning: answer customer emails instantaneously whenever they arrive, and prioritizing the features customers ask for, means deprioritizing the features they don't ask for (or the features that would excite new categories of customers), and at an individual level hyper-responsiveness means never having long blocks of time for deep work. But at a larger scale, it's possible to provide that kind of coverage and still make investments in longer-term projects. The responsiveness makes sense; one of Gaybrick's observations about the business is that there are individual customer relationships that are responsible for a unicorn's worth of valuation. But it's not the only thing.

One case of that is security; the ratio of gross payment value to market value of the payments company is, effectively, a measure of how much that company needs to spend on security compared to peers who don't handle money—Stripe is a high-value target, and as its products increasingly enable marketplace-style businesses, its customers are high-value, too. That's a case where customers may like the investment in theory but be annoyed in practice if visible features get a lower priority than engineering investments that lower the risk of a serious hack. Either way, that tradeoff is worth taking in two long-term senses: it's obviously an existential risk to a payments company if the money entrusted to it is at risk, but it also helps the enterprise evolution if the company over-indexed to security relative to its peers. The customers who ask detailed questions about this can be of high value, indeed, and if one company has materially better answers than the others, then that company ends up with more pricing power.

One of the long-run questions about Stripe then becomes: how much room for improvement is left? Start with the assumption that Stripe's customers want to sell something and that their customers want to buy, and a lot of the value add in payments is just reducing friction to get things closer to an idealized state. But as it turns out there is a surprising amount of friction, even today: when Stripe looked at customers who had adopted payment elements and compared them to customers who hadn't, they saw a 10% lift in growth rates—that's a lot of value creation from tweaking a form! Link, which pre-fills customer payment information, takes 1/6th the time as other payment forms, and increases conversions. It would be unusual for the greatest gains in efficiency to occur at the end of a friction-reducing process, rather than close to the beginning, which implies that even for the core product, there's still room for growth.

In the long run, one of the challenges Stripe faces is defining the process it's built to improve. Abstractions are convenient when they hide unnecessary complexity, but dangerous when they hide something important. In his essay In the Beginning... Was the Command Line, Neal Stephenson uses the term "metaphor shear" to describe cases when a user interface hides something important. (At the time that he was writing, it was entirely possible to select all of the text of a multi-page document, delete it, press the "Save" button, and find that you had successfully saved your deletion and lost hours of work. That particular instance of metaphor shear is, fortunately, mostly gone, but others remain.) At some point, the task is less about making it easy for modern companies to interact with a variety of mutually-incompatible legacy systems, and more about using an understanding of how those systems work to build the infrastructure that succeeds them.

---

1. In general, companies seem more comfortable with adding to opex than adding to COGS, since they usually believe that operating leverage is in their favor. If you run a discounted cash flow model, the comparison between fairly fixed costs for software versus variable costs for payment processing favors the former more when expected growth is higher. So the same selection process that allowed Stripe to grow pure payments revenue fast when customers were smaller has pushed them to grow not-strictly-payments revenue as those customers get bigger. Investors love companies with "tollbooth economics," but the bigger a business gets, the less willing it is to let somebody set up a tollbooth at its expense. ↩︎

Elsewhere

Deal Flow

Nat Friedman (former CEO of GitHub) and Daniel Gross (AI at Apple, Pioneer, etc.) have bought roughly $100m worth of GPUs and are offering startups access to them on preferential terms. For context, cloud GPU providers CoreWeave and Lambda Labs would both charge roughly $50m/year for access to that much compute. Even when capital is scarce, investors try to offer something other than cash to convince startups to choose them, and one way to frame these offers is that it's partly an in-kind investment and partly a way to accelerate businesses at a time when speed is at a premium.

It's basically Charlie and the Chocolate Factory for AI startups: compete for a small chance to get access to something that everyone wants and that no one has a practical way to get—and, if you win, there's a chance you'll end up owning a thriving business.

Proprietary Data

One vision of large language model economics is that basic techniques will be open-sourced and commoditized, and the only enduring advantages will be 1) whoever can get the best economies of scale, and 2) whoever has proprietary training data. On the latter point, one of the questions that comes up is whether or not companies can really keep their data proprietary: The Information reported in March that Google's Bard was partly trained with ChatGPT data, and is now reporting that OpenAI used YouTube to train some of its models ($). AI has increased the value of anything that turns out to map between text and other kinds of data, which is one reason TikTok added a longer description field to videos last year. A few months ago, the smart bet was that the companies that would enforce their IP rights against AI models would be IP owners worried that their business would be entirely disrupted by AI. But it might actually turn out to be diversified big tech companies who want to use their own data to disrupt themselves first.

Beyoncéflation

Sweden's May inflation rate was 0.3% higher than expected, and their central bank attributes 0.2% of this to Beyoncé's world tour, which caused a spike in hotel prices. The typical line about small, open economies is that they're vulnerable to global changes in the flow of capital, but they can also be disproportionately affected by global changes in the flow of services. American pop culture hegemony is extremely strong, and American stars tend to be well aware of their own pricing power; when that collides with a comparatively small economy in a concentrated way, it can be a big enough deal to add some noise to economic data.

Pricing and Local Maxima

One of the most important things a company can test is how users react to sharing prices in different ways. When a large e-commerce site offers free shipping, and still displays a shipping cost on the checkout page offset by a free-shipping credit, it's because that leads to slightly more completed transactions than if shipping is omitted entirely.

But this kind of test-driven presentation can sometimes lead companies into a trap, where they get in the habit of hiding some costs until the last minute, and users start to discover that the price they think they're paying and the price they ultimately pay bear little meaningful relationship. Ticketmaster and SeatGeek are joining Airbnb in switching to 'all-in' pricing ($, WSJ): ticket sites have increasingly defaulted to having customers shop based on ticket prices that ignore fees, and then hitting them with fees when they try to make a purchase. Every incremental fee that's added in this way presumably hurts conversions but helps revenue more, on the margin. But every unpleasant surprise at checkout also means that some customers decide that the whole product category is a ripoff. Quarter to quarter, obscuring the high fees works; in the long run, the only question is whether companies that do this lose their customers directly, or whether irate customers eventually push legislators to ban the practice entirely.

Funds and Spoils

The FT looks at the divergent fates of two London hedge funds, Lansdowne Partners and Marshall Wace ($). They were founded around the same time, and in the mid-2010s their assets under management were in the same ballpark. But since then, Marshall Wace has successfully executed the pod structure while Lansdowne has been reluctant to give up enough equity in the management company to attract outside teams. This is a good illustration of the institutionalization of asset management. One side of this is that it switches from being a craft practiced by a small number of opinionated financial artisans into an alpha factory that's willing to pursue any strategy that promises another stream of uncorrelated returns. But it illustrates another aspect of that institutionalization: a company looking for talent needs to pay people with both the amount and the structure they're open to. Some funds have been profitable enough, and good enough at underwriting bets on individual managers' skills, that they can offer performance-based compensation and use fixed bonuses to get managers to make the jump. In other cases, though, a fund that can't be sufficiently confident in a manager's returns and that's reluctant to share equity in the overall fund-management enterprise will find itself perennially outbid. The artisanal, single-strategy approach still works; Lansdowne has $100m in assets per employee, and Marshall Wace is only 15% better on that metric. But Lansdowne ends up making a narrower and more volatile bet; a portfolio manager at either company would readily admit that the diversified business deserves a premium.