Rockets versus planes

When starting a product at any large-ish company you will need to present a global overview of how much your product will cost and how much revenue it will generate in a given amount of time (typically the first year of operation).

In my personal opinion, that is a reductive way of looking at your product's ROI - and one that doesn't capture the complexity of who will need to maintain it afterwards. I've seen plenty of high performing teams being crushed by the duty of maintaining their flagship product - and becoming unable to innovate.

A useful mental model to see whether your brand new idea is going to drag down a team like that - and mitigate that risk - is to look at your product and determine whether it's a plane, or a rocket.

• ✈️ A Plane product takes effort to get up in the air - and the team celebrates once it takes off. But the reality is that if you want to keep flying your plane past its maiden flight, you'll need ground operations, a flight crew, and refuel stops. Without that, the team will keep scrambling forever to keep the plane flying.
• 🚀 A Rocket product also takes effort to get up in the air - generally more so than a plane product. But once it gets out of the atmosphere and into orbit, it will stay there with minimal energy expenditure for a very long time - without generating significant maintenance costs for you, and leaving the rocket team able to innovate and work on the next launch.

To make this more tangible, we can look at Stripe - a company which has innovated plenty in the last few years, but has also had to scale up their workforce significantly and is known in the sector for occasional ruthless crunches. Which of their products are planes - and which are rockets?

✈️ A classic plane product: Stripe's payment methods

Imagine we're trying to start a payment processor. If we're based in the West, we'll most likely go with VISA, Mastercard and American Express first. Once those are done, the strategic next step is branching out to local payment methods - stuff like bank redirects, local wallets, and alternative schemes.

Now here's the kicker: any new payment method is not a rocket product - but a plane product. Every single payment method requires bespoke integration, expanding or upskilling the operations team, new settlement flows, new monitoring and infra tooling - those are fixed and variable costs that will remain with the product for the remaining of its lifecycle.

Once the product has launched, the maximum utility for the end customer is achieved: the only thing that can happen now is scaling: more customers, more transactions. Many PMs will let marketing take care of that, and move on to the next payment method. But tossing more and more payment methods onto the team's platter without a credible scaling strategy will lead to an inflection point where the team spends more time maintaining existing methods and putting out fires, than building something new for the customer. The plane becomes too heavy to fly again.

That's not to say plane products can't be successful or profitable. But you need to capture this complexity when deciding what to build - and not stop at a single 'additional volume estimate' that doesn't take into account the team growth and expenditure needed to keep the plane flying forever.

🚀 A rocket product: Sigma

So what's a good example of a rocket product? To me, that would be another of Stripe's offering - Sigma. Sigma is, at its core, an SQL dashboard layer that allows customers to query their own transactions - and get insights based on their payments without having to build reporting or data storage on their end.

This product must have been a difficult one to launch: aggregating many different payment methods and products built at a different point in time into a single data lake, ensuring PCI compliance, security and access segregation by allowing customers to only query their data, and of course the fact the payment data can now be scrutinized by the customer directly (prompting plenty of customer support contacts) are just some of the many challenges the team no doubt had to solve.

But now the product is out there, its maintenance cost does not scale linearly with the amount of customers. This is a fully in-house product, does not depend on external integrations, and is by and large feature-complete: there is no need to add graphs, machine learning, or analytics notification since the customer knows exactly what to expect from Sigma: a no-frills SQL dashboard for querying data they don't have the ability or capacity to store.

This rocket product is in orbit, and will stay useful and profitable with limited effort from the team.

🛸 A spaceplane: Stripe Tax

Does that mean that any product that requires integration or maintenance is by itself a plane product?

Let's take a look at the recently launched Stripe Tax, which allows customers to easily embed and report VAT rates on their checkout page. A seemingly simple endeavor that is complicated by constantly changing - and regionally granular - VAT and tax amount.

Stripe built this no doubt with the help of a significant contingent of for-hire lawyers, plenty of research, and their strategic acquisition of TaxJar. They will need to maintain the product forever: as VAT rates changes, so will the underlying product - and keeping track of variations over time and region will be a constant chore the team needs to fulfill.

Stripe managed to turn this plane into a rocket in two steps:

1. First, they changed their pricing model. TaxJar - which they acquired - is priced, like most robo-tax advisors on a monthly or yearly fee. Kind of like your tax accountant.
   
   But Stripe Tax charges you per sale: every time a tax is calculated, you'll pay Stripe an outrageous 0.5% of the total transaction amount, an amount they're keeping for themselves and not paying to any middleman like you would for an additional payment method. As maintenance cost scale with usage, so does revenue.
   
2. Second, if any region is underperforming, Stripe can simply pull the plug on coverage for that region with 30 days' notice - something that is impossible to do with payment methods.
   
3. Third, a large part of the issue with plane products is the liability they generate for the team running them -  things like fraud, timely payouts, or SLAs are what keep plane product teams awake at night.
   
   Stripe completely writes off any and all liability for this product, neutralizing one of the largest risks for this product. If the team is unable to update the service to include the latest VAT changes, that's no biggie: the customer is liable for this in the end.
   

Stripe does not represent or warrant that the Stripe Tax Services will enable you to fulfill your obligations under applicable Law, including with respect to taxes. Stripe is not liable for any tax calculations generated by the Stripe Tax Services. You are solely responsible for your compliance with applicable Law

While this makes this product arguably a better deal for Stripe than it is for their customers, there's no denying here that they have managed to defuse two of the largest risk of plane products - and turned them into rockets.

In short:

• 💰 They worked on pricing to ensure that revenues would automatically grow at a faster rate than maintenance costs: plane tickets are prized to cover the cost of fuel.
• 🌎 They segmented their product to allow them to turn on or off features and regions at any time (either with a termination clause or the Beta moniker): only the most profitable routes are flown
• 🥔 They removed liability ensuring neither the customer or other departments can force the team to maintain the product they created. Airlines are liable for customer injury, but rockets are not - that's how you can tell them apart. And while passing the hot potato to the customer is not a good strategy, if the liabilities being shifted are reasonable, it's a good way to protect your team.

Building rockets - or turning plane into spaceplanes - is a good thing to do if you plan to keep shipping year after year.