People sometimes ask why I spend my evenings and weekends building tools like Trova (a SaaS boilerplate) and VulnClaw (an AI pen-testing CLI). Isn't operations about processes, not products?
My answer: building products makes me better at building operations. Here's why.
1. Scope teaches you everything. When you build a product from scratch, you learn scope management the hard way. Every feature request seems reasonable. Every edge case needs handling. The discipline of saying "no" to good ideas — to ship the essential ones — is exactly the same skill you need in operations. A project with 50 priorities has zero priorities.
2. You feel the pain of bad processes. When you're the one waiting for a CI pipeline, debugging a webhook failure, or chasing down a deployment approval, you experience operational friction firsthand. That changes how you design systems. You stop creating processes that look good on paper and start creating processes that actually work.
3. Metrics are not abstract. I track build times, deploy cycles, error rates, and customer issues for every tool I build. These are real numbers that bite back when they're bad. Operations leaders who build products don't just talk about KPIs — they live under them.
4. Documentation is not optional. Every tool I release comes with comprehensive docs — setup guides, API references, troubleshooting. Not because users demand it, but because I've learned that undocumented systems don't scale. Same truth applies to operations. A process that isn't documented is a single point of failure wearing tribal knowledge as armor.
The best operations leaders I know share this trait: they build things. Not because they need to — because understanding the act of creation makes you better at designing the systems that support it.