Julien Reszka
The fastest way to make a product cheaper is to not build most of it. The Standish Group has tracked software project outcomes for decades and consistently finds that around 64% of features are rarely or never used, which means the average product spends the majority of its build budget on things that do not matter to anyone. The discipline that prevents this is not better estimation or faster sprints; it is a willingness to cut before you start. The method is straightforward: list every planned feature, then label each with two questions:
- Does any other feature depend on this one? If not, it is non-critical.
- Is there another way to get the same result without building this? If yes, there is a workaround.
A feature that is non-critical and has a workaround is a candidate for removal, not because it is useless, but because its absence costs nothing and its presence costs engineering time, maintenance, edge cases, documentation, and bugs. Run the analysis, rank by severity, remove from the bottom up, and stop when removing anything would actually break something. What remains is the minimum viable product in the literal sense: the smallest set of features where every one is load-bearing.
Discussion
Yes. Our roadmap has 34 items and I genuinely cannot defend 20 of them. The dependency/workaround matrix is going into next week's planning to cut from the bottom.
Our backlog is graveyard of features we built because one big customer asked. None of them get used now and we still maintain them. The post is describing my job.
Same trap. 'A customer asked' was never sufficient justification but we treated it as if it was.
The dependency/workaround matrix is a snapshot, not a forecast. We killed an audit trail feature two years ago (non-critical, had workarounds) and spent six months rebuilding it when a customer triggered a compliance review. Features that seem optional at scale one become foundational at scale ten. The framework needs a growth assumption baked in.