Skip to content
// hd
Writing

The wrong kind of fast

Back when I was working on products at a fintech, I sat in a meeting where the question on the table was: “If we change this payment flow, what breaks?” The answer: “Not sure, but let’s just do it.” The meeting was quick. The fallout wasn’t.

There’s a common line in tech: startups are fast and nimble, big companies are slow and bloated. Not wrong, but it misses something. The two aren’t playing the same game.

At a startup, the central question is: Does anyone actually need this? At an established product: if we change this, how much of what’s already working do we break?

A startup can ship a feature, see users react badly, and pull it back in days. The damage is a few hundred annoyed people. For a product with millions of daily users, especially one tied to money or data, pulling things back isn’t always an option. Some changes, once shipped, can’t be undone.

I once watched a small team that was proud of how fast they moved, right up until they had to apologize to an enterprise client for changing the response format of a payments API. Seemed minor. The client’s system depended on that exact format. Nearly lost the contract. Speed didn’t go away after that day. But it was no longer innocent.

At a startup, speed is an advantage. At a large product, speed is usually a risk.

A question that often comes from the outside: why can’t big companies just move like startups? Usually, from people who’ve never owned the consequences when a bad call hits millions of users going about their day. A startup makes a mistake and learns a lesson. A large product makes a mistake and has to answer to customers, partners, regulators, and legacy decisions no one remembers the reason for.

On the flip side, once a startup has real users and real revenue, every wrong call stops being a cheap lesson. Fail fast still sounds good. The cost of “fail” is just different now.

A PM who moves from a startup to a large product is usually shocked by how slow everything is. One who goes the other way is shocked that no one’s there to shield them. Not because one side is better. The two environments demand different kinds of caution.

Startups optimize for finding the right answer. Established products optimize for not giving the wrong one.

Bring startup thinking into a large product and you get chaos. Bring large-product thinking into a startup and you kill speed before you even know if you’re building the right thing.

What game am I playing, and am I using the right strategy for it?

Reach me if you have other perspectives, or just want to say hello.

Say something.