A volte le persone mi chiedono perché passo serate e weekend a costruire strumenti come Trova (un boilerplate SaaS) e VulnClaw (un CLI di penetration testing AI). Le operations non riguardano processi, non prodotti?
La mia risposta: costruire prodotti mi rende migliore nel costruire operations. Ecco perché.
1. Lo scope ti insegna tutto. Quando costruisci un prodotto da zero, impari la gestione dello scope nel modo più duro. Ogni richiesta di funzionalità sembra ragionevole. Ogni caso limite va gestito. La disciplina di dire "no" alle buone idee — per ship quelle essenziali — è esattamente la stessa competenza che ti serve nelle operations. Un progetto con 50 priorità ha zero priorità.
2. Senti il dolore dei processi inefficienti. Quando sei tu ad aspettare una CI pipeline, a debuggerare un fallimento di webhook, o a inseguire un'approvazione di deploy, provi l'attrito operativo in prima persona. Questo cambia il modo in cui progetti i sistemi. Smetti di creare processi che sembrano belli sulla carta e inizi a creare processi che funzionano davvero.
3. Le metriche non sono astratte. Traccio tempi di build, cicli di deploy, tassi di errore e segnalazioni utenti per ogni strumento che costruisco. Sono numeri reali che mordono quando sono sbagliati. I leader di operations che costruiscono prodotti non parlano solo di KPI — ci vivono sotto.
4. La documentazione non è opzionale. Ogni strumento che rilascio include documentazione completa — guide di setup, API reference, troubleshooting. Non perché gli utenti la richiedano, ma perché ho imparato che i sistemi non documentati non scalano. La stessa verità vale per le operations. Un processo non documentato è un singolo punto di fallimento vestito di conoscenza tribale.
I migliori operations leader che conosco condividono questo tratto: costruiscono cose. Non perché ne abbiano bisogno — perché capire l'atto della creazione ti rende migliore nel progettare i sistemi che la supportano.