Delivering a feature is not the same as delivering a quality feature. It may do what it is meant to, but most likely it is full of small details that make it hard to use, scale or understand.
The constraint between delivering features constantly because it adds business value “now” is one that teams constantly face. The challenge with delivering earlier by sacrificing quality is that it compounds. This is especially true if multiple teams are adding to the product simultaneously. If everyone sacrifices quality with the mantra “we will fix it later”, it probably won’t be fixed because the team didn’t see value in it in the first place. The business wants the next feature they can sell. Eventually, it adds up and probably will require redesigning the whole feature or product.
The same problem is true for engineering. The challenge with making short term solutions to deliver now is that many short term decisions hurt the long term. It may work for a start-up working on a minimum viable product (MVP), but MVPs don’t sacrifice quality, they sacrifice capability. Don’t hide your willingness to sacrifice quality behind the idea of an MVP. It’s not the same.
If you want to scale your product, you have to consider the long term over the short term benefits. What if you could have the feature 2 weeks later, but increase quality by 10%. What if you did that for every feature? Will 10% accumulate the same way over time?
I always tell co-workers that we are either making our product incrementally better or incrementally worst. It’s never a leap. One compromise is not so bad when you know you are sacrificing the quality for the capability in the short run knowing that the next step is to improve quality. When everyone is compromising quality to deliver early, it adds up.
Are you an engineer? Is your current implementation setting your team up to deliver quality later? Or does it just meet the requirements?