Quick inventory: think of the most ambitious project you have been part of - the big replatforming, the grand redesign, the everything-app. Where is it now? Shipped, thriving, loved? Or did it die in a slide deck, get “descoped”, or launch two years late as a shadow of the original vision?
Now think of the smallest thing you ever shipped - the annoying bug you fixed, the one-click export someone begged for, the build script that saved everyone four minutes a day. I would bet people still thank you for that one.
That asymmetry is not bad luck. It is a pattern, and it is worth taking seriously.
Why grand plans rarely see daylight
Big plans fail for a boring reason: they starve. Not of budget or talent - of feedback.
A plan that takes a year to deliver spends a year being wrong in private. Requirements drift, assumptions expire, the market moves, sponsors change - and nobody notices, because nothing real has touched a real user yet. By the time the grand thing finally ships, it answers last year’s question.
The numbers behind this are brutal. The Standish Group famously found that 45% of features in typical systems are never used, and another 19% are rarely used - roughly two thirds of built functionality is waste. That waste is not free: every unused feature still has to be maintained, tested, secured, and understood by every future developer, forever.
Where does all that dead weight come from? Mostly from one innocent-sounding sentence: “But the customer might also want…” Speculation feels like diligence. It is actually how a two-week solution becomes a two-quarter project that never ships.
What shipping small actually gives you
Flip the approach. Take a concrete problem someone has today - and solve just that. The mechanics change immediately:
- Faster wins. Small problems fit in days, not quarters. You ship, someone’s day gets better, and you feel it. That motivational loop is real fuel - for you and for the team.
- Direct feedback. A small change hits reality fast. You learn whether it worked this week, not in a retrospective next year. Wrong turns cost days instead of quarters.
- Tighter iterations. Because each step is cheap, you can afford many of them. Ten small iterations with real feedback beat one big guess every time - the small-batch effect that continuous delivery teams have measured for years: smaller changes mean lower risk, faster review, easier rollback, shorter cycle times.
- Less drowning in details. A small scope has fewer places to get lost. You do not spend three weeks on an abstraction layer for requirements that do not exist yet.
The hidden superpower: forced focus
Here is the part I find most underrated. Working small does not just make you faster - it makes you honest.
When the unit of work is “solve this one daily problem”, there is simply no room for speculation. The “customer might also want” features do not fit, so they do not get built. You are forced onto the essentials: what does the user in front of you need right now? Everything else waits until it proves itself real.
That is YAGNI - you aren’t gonna need it - applied not as a code-review slogan but as a way of working. And it pays: analyses of speculative feature waste suggest that ruthlessly cutting “just in case” functionality can reduce project cost by 30-40% while delivering the same business value. Not by working harder. By not building the two thirds that nobody asked for.
The application benefits too. Software assembled from solved real problems stays lean. Software assembled from anticipated hypothetical problems becomes the bloated system everyone dreads touching - where the unused features are not neutral, but active drag on every future change.
How to work this way
As a developer:
- Slice until it hurts. If a task cannot ship something observable within days, slice it again.
- Start where the friction is. The problems worth solving announce themselves daily - the manual step everyone hates, the flaky script, the report someone assembles by hand every Monday.
- Ship, observe, then decide. Let the reaction to the small solution tell you whether more is needed. Usually “more” looks different from what you would have guessed - and often it is not needed at all.
- Say the magic words. When someone adds “the customer might also want…”, answer: “Great - the moment they do, it’s a small problem we’ll solve then.”
As a manager or lead:
- Reward outcomes, not roadmap theater. If your team gets praised for grand plans, you will get grand plans. If it gets praised for shipped improvements, you will get shipped improvements.
- Protect small work. Daily-problem solving dies when every ticket must justify itself against a quarterly initiative. Keep room for “this annoyed someone yesterday, it is fixed today.”
- Make results visible. A two-line “shipped this week” note does more for momentum than any milestone review.
None of this argues against vision. It argues against building speculatively. Keep the direction big; keep the steps small.
Paving the desire paths
Every campus and park has them: the official paved walkways, drawn by planners years ago - and next to them, the dirt trails worn into the grass where people actually walk. Landscape architects call them desire paths. The wise ones have learned a trick: do not design the paths first. Watch where the grass wears thin, then pave exactly there.
Grand software plans are the planner’s walkways - elegant on the blueprint, drawn far from the ground, and routinely ignored by reality. Daily problems are the desire paths: proof, worn into the grass by real people, of where a path is actually needed.
Solve the problem people walk through every day, and you are never guessing. You are paving a path you can already see - and the ones who walk it will thank you every single morning.