On speed vs quality

We were discussing product delivery in a meeting earlier today where Shola, my cofounder, touched on something interesting about speed versus quality - that classic argument about tradeoffs in project execution. His take was fundamentally different, and it got me thinking. This is it, paraphrased.

Quality is inherent. Speed is a reflection of priorities.

The core insight is this: quality isn’t actually a variable - it’s a constant. You’re either committed to building quality products or you’re not. That’s an absolute fact, not something that flexes based on other factors. Speed, however, is ultimately just a reflection of how you prioritize. This distinction becomes clear when we look at how it plays out in practice.

In an ideal scenario where you’ve got all your ducks in a row - you’re focused on the right work, you’re not getting derailed by random distractions - your speed of execution, or at least how that speed is perceived externally, still comes down to how you prioritize and structure your work.

This manifests in two distinct approaches.

In the first approach, you take on a big epic with end-to-end planning upfront. You dive into execution, continuously discovering things you didn’t account for in planning, going back and forth until you finally reach the end. Then you ship this big final thing you set out to build. It’s comprehensive, but value delivery is backloaded.

The alternative approach is more iterative. You take that same big vision but break it down into smaller chunks you can iterate over. Then you look at everything holistically - what’s the most important small chunk you can ship today? Next week? You get that core bit out there, allowing you to layer improvements and the rest of your vision on top of it. The key difference? You’re already delivering value. You’re not waiting until the end of a large epic to start making impact.

There’s another benefit to this iterative approach: real-time feedback. As your product lives in the wild, delivering value, you get actual usage data and user insights that inform how you approach the remaining tasks. This typically results in a much better, more market-ready product that genuinely delivers value to your customers. Compare this to the first approach, where you not only deal with scope creep during the build, but you also don’t get real user feedback until everything is done.

Looking at these approaches, you can see how they reflect different prioritization strategies. But one is inherently faster than the other - not because it cuts corners or sacrifices quality, but because it structures delivery in a way that creates value sooner and learns faster. In product development, speed isn’t about how fast you can build everything - it’s about how quickly you can start delivering real value.