I recently had a very interesting conversation with a very successful founder. He asked me multiple questions, but one was asked multiple times in a different form: "How can we ship faster?"
And I was like... look, I rarely see companies where engineers are the bottleneck. When they actually are, that's quite a solvable problem—hard, but solvable. Most of the time companies either don't know what to build, or they're shipping very wrong things. That's where you're spending most of your time. If you optimise that, you've done 95% of the job.
But he was still very keen to understand how to ship faster. He asked a more direct question: "How do we fire people faster? Hiring is random at best—the only successful companies are the ones who managed to fire incorrect hires quickly."
I slightly disagreed with that sentiment, but yes—hiring is broken everywhere. The reality is, until you actually work with a person, assumptions are all you have.
The RRevelation
The conversation took an interesting turn when he brought up one fintech. "Look what they achieved," he said. "They built a feature-shipping machine."
He wasn't wrong. they are a marvel of execution. They've mastered the art of rapid feature delivery, clear product ownership, and—yes—quick talent decisions. Their "shepherd with a big stick and medium carrot" model works brilliantly for what they do.
But here's something interesting: do you know that way before they was born, there was a bank in the Russian market called Tinkoff? They had more features compared to what that fintech have even now, and they built a much better and bigger product. Geographical arbitrage in a nutshell. Nu did the same, but on smaller scale.
That's not that hard to copy and paste. I heard some countries built whole industries around copying and pasting... throw in a 996 work culture and you can execute it really, really well. To a point, of course.
But here's what keeps me thinking: what happens when everyone else figures out the same playbook?
The Two Extremes
I've observed companies clustering around two poles, both failing to crack the innovation code:
The Pressure Model: High-pressure, metrics-driven, performance-obsessed cultures that excel at execution but struggle with genuine breakthrough thinking. When everyone's worried about their next performance review, who's thinking about the impossible?
The Comfort Zone Model: Well-compensated, work-life balanced environments that attract talent seeking stability. Mostly retirement places. Great for retention, terrible for the kind of obsessive curiosity that drives real innovation.
Both models optimize for something valuable—execution in the first case, talent happiness in the second. But neither optimises for the conditions that create breakthrough innovation.
Figure Out Which Game You're Playing
I think, I've seen enough product teams to know that half the confusion comes from not knowing what you're actually trying to do.
Are you playing catch-up? Cool. Find out which features your customers actually care about—spoiler alert: it's not all of them. Then do yourself a favour and stop having those weekly alignment meetings where everyone pretends to agree but nothing gets decided. Just... build the damn thing. The R approach works wonders here—clear owners, clear metrics, and yes, clear consequences for people who can't deliver.
Trying to innovate instead? Well, that's a different sport entirely. You'll need space to mess around, permission to learn, and a culture where "that didn't work" is a proud outcome and you need your carrots and some kind of sticks as well…good luck figuring that out.
Let’s make it even harder: can you run both simultaneously?
You need teams that can execute ruthlessly on known problems while other teams explore entirely new problem spaces.
Different teams, different rules, different success metrics.
The tricky part isn't picking one approach—it's building an organisation complicated enough to run multiple operating systems with them interfering with each other in a positive way.
So, this isn't about shipping speed at all. Your customers aren't asking you to build faster—they're asking you to build things that's matter. To solve problems they can't solve themselves, in ways they never imagined possible.
The question isn't whether you can optimise your existing playbook. The question is whether that's enough.