Il cliente
Una startup seed agritech offriva una piattaforma SaaS B2B per la gestione degli allevamenti a partire dai dati raccolti nelle stalle. La piattaforma si collega ai sensori aziendali e alle apparecchiature già installate per monitorare temperatura, umidità, qualità dell’aria, consumo di mangime e acqua e attività dei singoli animali. Dashboard in tempo reale, analisi delle tendenze e avvisi automatici aiutano allevatori e responsabili di mandria a rilevare per tempo problemi come lo stress da calore o i guasti alle attrezzature, tutelare il benessere animale e ridurre le perdite.
Il prodotto era già sul mercato e aveva aziende agricole paganti. Era venduto con un abbonamento modulare, a stalla o a capo, per allevamenti bovini da latte e da carne, suini e avicoli. Il team contava 9 persone, di cui 2 sviluppatori backend, 3 frontend, 2 persone nelle vendite e 2 nel marketing. Clienti, vendite e investitori avanzavano richieste diverse e nessuno aveva il compito di valutarle rispetto a un obiettivo di prodotto. Ogni richiesta sembrava ragionevole.
La sfida
- Il team sviluppava molto, ma senza una priorità chiara.
- Il backlog cresceva più rapidamente dell’impatto del prodotto.
- Ogni richiesta di clienti, team e investitori sembrava urgente e nessuna veniva davvero scartata.
- Al team serviva un metodo condiviso per scegliere quali richieste portare avanti e quali lasciare fuori.
Diagnosi
Mancavano criteri espliciti per prendere decisioni. Il backlog finiva per raccogliere tutte le idee, senza aiutare il team a scegliere.
Le richieste di clienti, vendite e investitori arrivavano da canali diversi e venivano valutate una per una. A ottenere la priorità era spesso chi aveva chiesto per ultimo o con più insistenza. Gli sviluppatori potevano ricevere indicazioni in conflitto da più persone nello stesso momento e il piano cambiava a ogni conversazione.
L’esempio più chiaro arrivò dalla direzione. Il CEO decise di ripensare il meccanismo di crescita e ridisegnare le landing page, spostando frontend e marketing su quel lavoro e mettendo da parte la roadmap e il processo di definizione delle priorità. La proposta era plausibile. Senza criteri comuni, però, mancava un modo per confrontarla con il lavoro già previsto e capire cosa avrebbe preso il suo posto.
Anche le iniziative erano difficili da confrontare. Integrare un nuovo sensore, aggiungere un tipo di avviso, migliorare una dashboard e ridisegnare il sito competevano per la stessa capacità, senza un riferimento comune per stabilire quale intervento contasse di più. Il backlog conteneva circa 200 voci aperte e il team seguiva 11 iniziative in parallelo. Molte richieste erano prive di un obiettivo di prodotto esplicito o di evidenze sufficienti per valutarne la priorità. Il costo si vedeva nei continui cambi di contesto, nelle iniziative lasciate a metà e in un backlog che cresceva più rapidamente dell’impatto del prodotto.
Approccio strategico
Ho lavorato per sottrazione, partendo dalle decisioni su quali iniziative tenere.
- Ridefinire i criteri decisionali. Ho concordato con il team 4 criteri condivisi: impatto per l’utente, contributo agli obiettivi aziendali, evidenze e impegno richiesto. Li abbiamo applicati a tutte le richieste, comprese quelle della direzione.
- Chiarire cosa misurare. Abbiamo scelto poche metriche legate agli obiettivi di prodotto e messo da parte gli indicatori che non aiutavano a decidere.
- Togliere dal backlog le iniziative a basso impatto. Abbiamo rivisto ogni voce e deciso esplicitamente quali richieste eliminare o rinviare quando non soddisfacevano i criteri.
- Rivedere le priorità con regolarità. Abbiamo introdotto una revisione periodica delle richieste e delle priorità, documentando le ragioni delle decisioni.
Come abbiamo lavorato
In 6 settimane abbiamo rivisto il backlog ogni settimana e inserito i criteri di valutazione direttamente in Jira. Ogni richiesta veniva così valutata dove il team lavorava già, con la motivazione registrata nel ticket. Il punteggio orientava il confronto e la decisione spettava al team. Abbiamo misurato quante aziende collegavano i sensori e trasmettevano dati nelle prime settimane, quali avvisi venivano presi in carico e seguiti da un’azione, e l’uso ricorrente delle dashboard principali.
Risultati
- Da circa 200 voci a un backlog di 50. Il limite era intenzionale. Per aggiungere una richiesta oltre quel numero occorreva valutare se meritasse un posto e quale voce rimuovere. Il backlog è tornato a essere uno strumento per scegliere.
- 5 priorità in discussione alla volta. Le proposte erano in una lista breve e visibile a tutti. Prima di entrare in uno sprint venivano valutate con i criteri condivisi.
- Da 1 a 3 priorità in lavorazione per sprint. Dalle 11 iniziative in parallelo siamo passati a un numero adatto alla capacità dello sprint settimanale. Il team poteva rilasciare ogni settimana e far evolvere il prodotto per piccoli passi.
- Stesso numero di riunioni, decisioni più chiare. Gli incontri sulle priorità sono rimasti gli stessi. Scegliere su cosa lavorare è diventato più semplice e il team usciva da ogni incontro con una motivazione condivisa.
Cosa ha detto il cliente
“Le riunioni sono le stesse, ma ora decidiamo più in fretta e tutti sanno perché. Finalmente abbiamo un modo per dire di no spiegandone il motivo.”
CTO, startup agritech in fase seed