Product delivery is simple and complex, all at the same time. The issue is that we always want 3 dimensions of delivery. We want it:
- Quickly (Time dimension)
- Bug-free (Quality dimension)
- All the “important” features (Scope dimension)
The problem is that you can only deliver on 2 of the 3 at the same time.
If you want a lot of features quickly, you have to sacrifice quality.
Because if you are trying to do a lot of things quickly, the only thing you can adjust is the build quality.
Do you write automated tests? Work through all the edge cases and scenarios? Odds are, when you are rushing (which you are if you’re trying to do a lot of features fast), you will miss things, and the end result will feel less refined or have strange bugs.
The problem with this approach is that many of the issues are hidden from the view of anyone who isn’t looking from the technical aspect. Because of that, this is the angle that Product Managers tend to lean into.
If you want a lot of high-quality features, it will take a long-time.
Software Engineers love nerding out on tech.
Let’s make things reusable! What kind of crazy scenarios might happen? Does someone have 10 words in their name? Thinking through technical excellence and building a fully working piece of software is one of the best spots for an engineer to be in.
But the problem is, without modifications, the natural inclinations of most software engineers is how we got waterfall software development that goes over budget and over deadlines.
The best approach is a small number of high-quality features that can be done quickly.
This is what agile was meant to be before it became a buzzword—it’s how you deliver and iterate on magical experiences.
It’s the most challenging part of software design and development, but it’s essential to make the software the best it can be.
Limit the number of features, think through edge cases, and write automated tests. But because you limit the number of features, you keep the scope small, and you can ship software quickly and reliably.
So the next time you’re pulled into a discussion on what will be built and when it’ll be ready, bring the product-delivery paradox triangle with you.
Top comments (0)