Sustaining Fast Using Asymmetry

By Aaron Yodaiken. Initially published Mar 29, 2025.

Everyone loves building software fast. And for good reason: all else equal, building faster means giving your users valuable features faster, making money faster, and learning what works and what doesn’t work faster. This cycle creates long-lasting, highly valuable products.

With the last couple of decades of agile practices, programming language improvements, cloud hosting, SaaS, and — yes — vibe coding, the best builders are moving faster than ever. Revenue isn’t a perfect metric, but the median AI company on Stripe is now generating $10M in annualized revenue in just over a year. That’s pretty damn fast!

But speed in young software companies—without many or any users, and worst-case outcomes consisting of grumpy beta testers—has always been relatively easy.

The real challenge? Maintaining that velocity as the stakes rise. With success, customers begin to depend on your product, and the potential worst-case escalates:

• Losing your entire customer base to a more reliable competitor
• An angry social media post going viral and damaging your reputation
• A major security breach that you can’t come back from

In industries like finance or healthcare, the stakes are high from the beginning. When I worked at Butterfly, a medical device startup, FDA regulation and concern for patients meant that we began worrying about bad outcomes long before shipping our first production code. At Ramp, the risk of losing millions of dollars due to a programming error has been possible from day one. (These days, the exposure is orders of magnitude higher.)

Real stakes make the speed-quality paradox clear:

• On one hand: Products built quickly through many iterations often achieve higher long-term quality. Rapid iteration fuels faster learning, incorporates more user feedback, leads to better product-market fit, and builds resilience against real-world errors. The team shipping ten versions while a competitor ships one usually wins. I certainly want the product that has benefited from accelerated learning about quality.
• On the other hand: Every change introduces variance and risk. More deployments mean more chances for bugs, security flaws, and system failures. When the stakes are high, even if long-term quality trends upward, the short-term variance might be unacceptable.

At some level, even if you can fix things faster than you break them, sometimes breaking some things at all is not acceptable.

So, what’s the solution? Traditionally, teams hit the brakes when quality issues mount and move from “fast mode” to “slow mode”:

Think NASA’s 10 Rules for Safe C Code, or Salesforce release cycles. The unacceptable dips below the quality bar are eliminated by a dramatic change to the engineering process: instead of shipping things fast, learning from them, and correcting them (error robustness), the focus becomes on error prevention — carefully writing highly tested code, running lots of manual QA, and praying that you don’t miss anything. Teams do this because it’s the easy answer to reducing quality variance and sometimes it’s what you have to do — but of course, it comes at an immense cost.

Defying the odds and maintaining speed offers a significant competitive advantage. Many strategies exist (I’m curious about yours – email me), but one framework I’ve found particularly helpful is thinking in asymmetries.

Introducing: Asymmetric Upsides and Downsides

Imagine a spectrum of potential outcomes for any action, ranging from a reasonable “worst case” to a reasonable “best case”:

For an early-stage team hacking together a software-only, the “worst case” and “best cases” might look something like this:

For an early-stage team that’s, say, building a medical device, the outcomes might look more like this:

A more mature company adding a new “nice to have” feature to an existing product with lots of happy customers but legacy, hard-to-modify code might have an outcome set like this:

Here’s a visual representation of all of these together, with roughly to-scale “badness of outcome” and “goodness of outcome”:

This visualization clarifies things.

Building that new AI product quickly? That’s a clear case of asymmetric upside: the potential gains dwarf the relatively minor worst-case scenario. Don’t overthink the downside; fix issues as they arise, and go build something! (You should, actually, probably go build a new AI product right now!)

But the medical device and the mature SaaS feature present negative asymmetries or asymmetric downsides. The potential costs of failure are far greater than the potential benefits of success.

But what about the medical device? There’s a great best case, but a really terrible worst case. Similarly, for the mature SaaS product, the best-case scenario seems pretty marginal and the worst-case seems pretty damn bad. These are both examples of negative asymmetries: the worst-case costs dwarf the best-case profits.

Does this mean abandoning high-stakes projects or improvements to mature products? Not necessarily. As mentioned, you can operate in “slow mode”—building safely and meticulously. While this carries a huge competitive cost, sometimes it’s the only path forward. Traditionally, this cautious approach is applied wholesale to high-risk teams or projects. Salesforce releases major updates, but it requires immense effort and armies of testers to ensure stability.

However, to stay competitive, the modern approach is often more nuanced: isolate high-downside components to cap downside, and continue moving fast everywhere else.

Isolating and Capping Downsides

We might decompose our medical device into two components:

• Infrastructure: Core diagnostic algorithms, patient data handling, and hardware interfaces. These require rigorous testing, validation, regulatory consideration, and careful release processes. We need to build them or else we won’t have a product, and if we build them poorly, we will be in a very bad situation.
• New Features: Doctor-facing UI, analytics dashboards, appointment scheduling features, internal tools. Can be iterated on quickly based on user feedback. This is likely where are unique value lies, and the risk of screwing it up might be cappable.

Visually, we might look at something like this:

By pulling out the risky bits, isolating them, and then treating the rest of the product development process with a “move fast” mentality, you get the best of both worlds. The medical device’s core functionality that interfaces with patients might need careful, regulated development, but the UI for doctors, the analytics dashboard, and other peripheral features can move quickly.

This isolation strategy applies equally well to mature SaaS products. Instead of slowing down all developement due to a legacy codebase with its complex interdependencies, we might instead invest in factoring out components by their risk levels. The core database schema? The payment processing system? The user authentication service? Those might need cautious handling. But the new reporting dashboard, the profile customization feature, or the team collaboration tool? Those can likely move at much higher velocity with manageable risk and may be able to be completely broken out from the main product area.

This approach mirrors Zuckerberg’s strategic shift at Facebook post-IPO, moving from “move fast and break things” to “move fast with stable infrastructure.” Isolated stability enables speed and controlled variation elsewhere.

So what does this mean for me?

I’ve used these ideas of asymmetry both to help teams I work with and myself personally.

In the context of an organization, you might use this framing to:

• Challenge Slowdowns: Don’t accept “slowing down” as the only way to ensure quality. While caution is vital for high-risk areas, aim to isolate these, not let them dictate the pace of the entire system.
• Analyze Your Asymmetries: Consciously evaluate the potential upsides and downsides of your projects and features. Moving fast without considering severe downsides isn’t sustainable. Moving too slowly when downsides are minimal means getting outcompeted. Optimize for your specific context.
• Consider Person/Problem Fit: Recognize that different types of work suit different temperaments. Some engineers thrive in high-stakes, meticulous environments; others excel in rapid, iterative cycles. Aligning people with the asymmetry profile of their work can improve both satisfaction and outcomes. Avoid forcing an “asymmetric upside” innovator into a purely “asymmetric downside” risk-mitigation role, and vice versa.
• Measure What Matters: For high-downside components, focus on metrics like time between failures, test coverage, and security audit results. For high-upside areas, track innovation speed, feature adoption, and customer feedback loops. Different risk profiles should have different success metrics.

On a personal level, it’s worth thinking about your own level of proclivity to different kinds of work. If you’ve only ever worked in “fast mode”, trying to go slow will minimally give you respect for the work it takes to succeed in a different class of environment. If you’ve only ever worked in “slow mode”—try hacking around something purely with some vibe coding and get a sense for how cool it is to be able to move quickly while not caring too much about the worst case. And if you’ve done both and found a lane you like, then maybe this gives you some good language to use to articulate what you want.

And as always, if you have thoughts or ideas spurred by this post, please reach out. I always love meeting new folks and learning new things.

Appendix

Read more

Like everything, the ideas here have been expressed in many contexts and by other writers many times. If you’ve found this interesting, here are a few things I’ve read on similar themes. (If there are others that I’m missing here or that you’d think I’d like, email me recommendations at [email protected].)

• Fooled by Randomness by Nassim Taleb
• The Innovator’s Dilemma by Clayton Christensen
• Thinking, Fast and Slow by Daniel Kahneman

Lovers of Speed

Our generation’s business titans extol the virtue of speed:

• Patrick Collision¹, Stripe co-founder (2020s): “Fast”
• Mark Zuckerberg², Facebook founder (2010s): “Move fast and break things.”
• Jeff Bezos³, Amazon founder (2010s): “Speed matters”
• Steve Jobs⁴, Apple founder (1980s): “Real artists ship.”

The previous generation’s business titans did, too: Thomas Watson, IBM’s founder in the 1940s said, “The fastest way to succeed is to double your failure rate” ⁵.

And they weren’t the first: around 500 BCE, Sun Tzu wrote in The Art of War, “speed is the essence of war”.

Footnotes

1. Fast · Patrick Collison ↩

2. Business Insider via Wikipedia ↩

3. 2016 Letter to Shareholders ↩

4. WikiQuote ↩

5. The Failure-Tolerant Leader ↩