Protect a small amount of unassigned time and you keep the only condition under which unplanned products get built.
Where do software products come from?
Some come from research. Somebody studies a market, finds a gap, writes a plan, and gets it funded.
Others come from an engineer who was annoyed.
The second kind never appears on a roadmap, because a roadmap is a list of things somebody decided to do. Nobody puts down that in March an engineer will get irritated enough about a slow machine to fix it on a weekend.
Both kinds produce real products. Only one of them can be planned, so companies build processes around that one and quietly eliminate the conditions the other needs.
Why does performance work never get funded?
Because a successful performance project has nothing to show at the end.
New features demo. Integrations demo. A dashboard demos. Performance work produces the absence of a problem, and absence is the hardest thing in technology to get paid for.
Ask for two weeks to make something faster and the question comes back: faster by how much, and what does that buy us. Both are fair questions and neither has an answer before the work is done.
So the work does not get approved. And then somebody does it anyway, on their own time, because they have to use the thing every day and it is driving them out of their mind.
What happened when two engineers fixed a slow machine on their own time?
At the consulting firm where I spent my early career, Steve Davis and another engineer built a disk defragmenter for the operating system we all worked on.
There was no company mandate. Nobody assigned it, nobody scheduled it, and it did not appear in any plan. They did it themselves, on the side, because disks got fragmented and everything slowed down and they were tired of it.
It worked. Performance before and after was not marginally different, it was different by orders of magnitude.
Then somebody looked at what they had and realized it was a product.
How do you turn an internal tool into a product?
You decide the market is bigger than the one you built it for.
The original tool served the operating system our clients ran. The firm judged the larger opportunity to be on the other major platform of the era, so the work turned into a port and a plan.
I led that side of it. We also decided to bundle rather than ship a single utility, so it became a set of disk tools rather than one defragmenter. One person handled the defragmenter, another handled a directory program.
None of that was possible before the side project existed. The strategy came second. The thing came first and the strategy was assembled around it afterward, which is the opposite of how the story usually gets told.
What does slack mean in an engineering organization?
Unassigned capacity. Hours not allocated to anything in particular.
Slack is the first casualty when budgets tighten, and cutting it is easy to justify. Every hour is now attached to a deliverable and the numbers improve immediately.
What disappears is invisible, because it was never on a list. Nobody writes down the products that were not built because nobody had a spare afternoon.
I am not arguing for a formal program. Twenty percent time is a large-company answer to a large-company problem and it usually decays into another meeting.
The small-company version is simpler and cheaper. Do not schedule every hour. Leave a margin, do not ask what it produced, and accept that most of it produces nothing.
How do you spot a side project worth backing?
Somebody built it without being asked, and then other people started using it.
That second half is the test and it is a good one, because adoption without promotion is hard to fake. When a tool spreads through a team because it is useful, the market research has already happened.
Ask two questions when you find one. Who else has started using this, and what were they doing before. If the answer to the second is something slow and painful, you may be looking at a product.
The mistake is the other reaction. A manager who discovers unapproved work and asks who authorized it will not get told about the next one, and there is always a next one.
What did the defragmenter project prove about planning?
The plan followed the product rather than producing it.
Two engineers were annoyed by something. They fixed it on their own time and the result was orders of magnitude better than what existed. Only then did anyone think about markets, ports, or bundles.
Every company would prefer this to run the other way, and for most work it does. The plan comes first, the work follows, and the result is predictable. That is how the majority of anything gets built and there is nothing wrong with it.
Protect the exception anyway. It costs a margin of unassigned time and the discipline to not ask what that margin produced. Cutting it looks free on a spreadsheet, and the thing you cannot see on the spreadsheet is the product nobody got around to building.
The Guides That Get Your Book Written, Published, and Sold
Four short, practical guides on writing, publishing, and selling your book, plus the occasional note when there's something worth your time. No fluff, no daily inbox clutter. Drop your email and they're yours.
We use MailerLite to manage our list and send these emails. Your address is used only to send you what you signed up for. We will not sell it, share it, or use it for anything else, and you can unsubscribe anytime.