Do The Right Thing Slow vs The Wrong Thing Fast?
Why failing fast and iterating is the key to delivering real value in software development
In software development, there’s always pressure to build things quickly and get them out the door. Deadlines loom, stakeholders demand results, and the temptation to sprint toward a solution can feel overwhelming. But here’s the reality: doing the wrong thing fast won’t help anyone in the long run. However, taking forever to do the right thing also has its pitfalls.
We live in a world where failing fast and iterating is not just encouraged—it’s necessary.
Perfect is the enemy of good.
And sometimes, if you’re building for too long, the “right” thing changes before you’ve even delivered it. So how do you balance speed with quality? Let’s dive into the tension between speed and strategy and how to ensure we’re learning fast without getting stuck in perfectionism.
Why "Fail Fast" Is More Than a Buzzword
We hear it all the time: "fail fast." But what does that really mean? At its core, it’s about learning quickly. Building something small, putting it out into the world, seeing how it performs, and then iterating based on what you’ve learned. You’re not aiming for failure; you’re aiming for early feedback to prevent large-scale failure down the road.
In one of our recent projects, we had a product feature that was technically sound but remained in the backlog for months as we worked through endless refinement, re-planning, and adjustments. By the time we finally released it, the market and user needs had shifted. The "perfect" solution we spent so long building was now outdated. Had we embraced an MVP approach and launched a simpler version earlier, we could have learned what was working (and what wasn’t) months before, saving us time and energy while delivering real value faster.
The lesson? Don’t build a perfect feature that’s obsolete by the time it’s live. Sometimes, the right answer evolves as the world around your product changes. You need to be flexible enough to learn from that evolution, not buried under your pursuit of an ideal solution.
The Danger of Perfectionism in Development
Perfectionism in software development is a dangerous thing. It often masks itself as quality, but in reality, it’s an excuse to delay delivery, prolong debates, and keep teams trapped in a cycle of over-polishing. While striving for excellence is important, being perfect means you’re aiming for something static in a world that’s constantly moving.
A great example of this comes from a retrospective I ran after our Go-To-Market team delayed a feature launch due to a "it must be flawless" mindset. We spent extra sprints polishing minor UI details, reworking micro-interactions, and debating the smallest technical decisions. Meanwhile, our competitors released similar functionality. Less polished but more impactful. And gained market traction. While we were perfecting, they were iterating, and by the time we went live, we had lost the edge.
In retrospect, we realized that if we had launched sooner, even with a few imperfections, we would have had the opportunity to gather real user feedback and iterate. Instead, we worked in isolation, building what we thought users needed, rather than releasing what they actually wanted. More often, it's better to put out something "good enough" and improve from there, than chase an unattainable vision of perfect.
Right Things Can Change if You Build Too Long
In the fast-moving world of software, what’s “right” today might not be “right” tomorrow. Market conditions change. Customer needs evolve. New technology emerges. If your focus is solely on crafting the “right” thing but you’re building in isolation for too long, the world outside your product will move on.
I’ve seen this firsthand in long-term projects where the requirements were set in stone at the start but dragged on for months. By the time we delivered, the customers' pain points had shifted. The very features that were once considered essential no longer had the same relevance. It’s like setting sail toward a fixed point on the horizon but not adjusting your course as the seas and winds change.
Building iteratively and checking in with your users regularly ensures that what you’re delivering remains valuable. The "right thing" is a moving target. So instead of planning for months and assuming your initial ideas will still be valid by the time you release, get something in front of users early. Gather feedback. Adapt. Evolve your definition of "right" as you go.
Learning Faster to Deliver Better
This brings us to a core principle in agile teams:
Speed isn't about rushing, it's about learning.
The faster you can get feedback from real users, the faster you can course-correct. This doesn’t mean sacrificing quality; it means recognizing that no amount of internal debate will ever be as valuable as actual user feedback.
Here’s what I’ve found works best:
Start Small: Build a minimum viable product (MVP) that solves the core problem. It doesn’t need to have all the bells and whistles—just enough to test your hypothesis.
Iterate Often: Use every release as an opportunity to learn. Release, gather feedback, iterate. Each cycle helps you refine the product in ways that align with real-world needs, not just internal assumptions.
Embrace Imperfection: Your product doesn’t need to be flawless in its first iteration. What matters is that it’s solving the right problems. Get comfortable with the idea that perfection is a process, not a prerequisite for release.
Use Sprints as Learning Cycles: Each sprint should be seen as a learning cycle, not just a delivery cycle. What did we learn from the last iteration? How can we improve? The retrospective is sacred for reflecting on not just what was delivered, but what was learned and how we’ll adapt moving forward.
Final Thoughts
Doing the right thing slowly may sound noble, but in a world where customer needs and technology are always evolving, slow perfection can be just as harmful as rushing toward the wrong goal. The trick is to strike a balance—deliver quickly enough to learn and adapt, but thoughtfully enough to ensure what you’re delivering brings real value.
In the end, it’s not about speed or perfection. It’s about agility. It’s about failing fast, learning faster, and improving continuously. By doing that, you’re not just delivering faster—you’re delivering better.
📅 Coming Next Week
I think the late great Cory Rudl said something like, we fail all the time. The key is to fail small. Same idea, but from the marketing side of things.