L’esperto di prodotto condivide il flusso di lavoro basato sul vibe coding che sta sostituendo i passaggi di consegne con il team di ingegneria

Anton Ingachev è il fondatore di Mini Apps Builder, una piattaforma senza codice per creare app Telegram, dove si occupa del prodotto. In precedenza, ha ricoperto diversi ruoli di CPO e Product Director.

Abbiamo parlato con Anton per scoprire come sta eliminando i passaggi di consegne con il team di ingegneria, programmando personalmente piccole funzionalità attraverso il vibe coding. Ecco cosa ci ha raccontato.

Avvicinarsi all'IA per necessità

Lavoro nel settore del prodotto da oltre dieci anni: fintech, piattaforme di scacchi, blockchain e tecnologie per la salute. Ho ricoperto per due volte il ruolo di CPO e una volta quello di Product Director.

Il mio percorso nell'IA è iniziato per una necessità pratica, non per una strategia. Circa un anno e mezzo fa, ho cofondato Mini Apps Builder, una piattaforma B2B2C senza codice per creare app Telegram. In qualità di CPO non tecnico, avevo bisogno di distribuire rapidamente le funzionalità senza aspettare un ciclo di sviluppo completo. È allora che ho iniziato a usare quotidianamente Claude Code e Cursor, non solo per la documentazione o la prototipazione, ma anche per il lavoro in produzione.

Per dimostrarne appieno il potenziale, ho creato da solo un prodotto pronto per la produzione: architettura, backend, frontend, tutto quanto, utilizzando strumenti di IA e senza un team di ingegneria. È stato allora che ho smesso di pensare "uso l'IA per lavorare più velocemente" e ho iniziato a pensare "posso creare e distribuire personalmente prodotti reali".

Ora applico lo stesso approccio all'interno di Mini Apps Builder: sviluppo direttamente alcune funzionalità, invece di limitarmi a definirne le specifiche per gli ingegneri.

Il mio percorso, quindi, non è stato: "Ho letto della trasformazione guidata dall'IA e ho deciso di guidarla". Avevo invece bisogno di muovermi rapidamente senza un team numeroso; l'IA lo ha reso possibile e ora, grazie a questo, penso alla strategia di prodotto in modo diverso: ogni decisione sulla roadmap include la domanda "L'IA può occuparsi di questo passaggio o può solo supportarlo?"

Come l'IA sostituisce il vecchio modello di passaggio di consegne nei flussi di lavoro del prodotto

Per anni ho creduto che il lavoro di un PM terminasse con le specifiche. Scrivi i requisiti, ma non tocchi il codice: quello è il lavoro dell'ingegnere. Superare quel limite sembrava un'invasione di campo.

È questa la cosa più importante che l'IA ha cambiato nel mondo del prodotto. Ora gestisco personalmente le funzionalità semplici. Le creo utilizzando Claude Code e le distribuisco direttamente, senza aspettare la disponibilità del team di ingegneria.

Questo significa che possiamo eliminare un intero passaggio di consegne. Invece di passare da specifiche → revisione tecnica → sviluppo → QA, spesso sviluppo e testo direttamente.

Ora il nostro ciclo di rilascio prevede due o tre funzionalità distribuite alla settimana con un team di due persone, tra il sito web, il pannello di controllo per gli esercenti, la stessa Telegram Mini App e il nostro pannello di amministrazione interno. Questo ritmo non sarebbe possibile con il vecchio modello di passaggio di consegne.

E questo ha cambiato anche il mio modo di pensare alla struttura del team. Il vincolo non è più "Quanti ingegneri abbiamo?". È invece "Quanto bene riesco a specificare ciò che voglio?"

Un flusso di sviluppo delle funzionalità supportato dall'IA

Ecco come si svolge lo sviluppo di una funzionalità:

1. Descrivo l'attività a un modello di alto livello come Claude Code. Condivido ciò che mi piace, ciò che non mi piace, il problema che stiamo risolvendo e ciò che non dovrebbe essere dimenticato o danneggiato. Fornisco dei riferimenti, a volte di concorrenti diretti, ma non sempre.
2. Il modello produce un piano dettagliato. Lo leggo. Se necessario, apporto modifiche o metto in discussione il piano.
3. Chiedo a Claude di implementare il piano nel codice.
4. Creo una PR, che passa attraverso controlli automatizzati prima di essere assegnata al CTO.
5. Se è tutto a posto, il CTO la unisce all'ambiente di sviluppo e io la testo nel prodotto.
6. Se qualcosa non va, il CTO lascia dei commenti, io chiedo al modello di correggerli e il processo si ripete.
7. Se qualcosa è completamente sbagliato, discuto con il CTO su come migliorare le istruzioni fornite all'LLM e ripeto il processo.
8. Dopo aver testato nell'ambiente di sviluppo, pubblichiamo in produzione.

I pensieri di Anton

Condivido ciò che mi piace, ciò che non mi piace, il problema che stiamo risolvendo e ciò che non dovrebbe essere dimenticato o danneggiato.

Dove si può applicare l'IA nei flussi di lavoro del prodotto

I principali strumenti di IA che utilizzo sono Claude Code, Codex, Cursor, Gamma, Midjourney e Figma Agent. Ecco altri modi in cui utilizzo l'IA nei flussi di lavoro dei prodotti, insieme ad alcuni dei vantaggi:

1. Il nostro intero prodotto — interfacce, blog, Centro assistenza, articoli sugli aggiornamenti del prodotto — viene tradotto in 20 lingue quasi in tempo reale con un solo clic.
2. Gli articoli del blog scritti da un LLM hanno quasi raddoppiato il nostro traffico proveniente dalla ricerca — e la loro realizzazione richiede una frazione del tempo.
3. In qualità di product manager, l'IA mi facilita il mettere in discussione le mie idee — posso chiederle di trovare dati che le supportino o le smentiscano.
4. Scrivere le note di rilascio non è più un problema, poiché l'IA lo fa quasi automaticamente.

Onestamente, non riesco a indicare un ambito in cui l'IA non sia d'aiuto. Quasi ovunque, utilizzarla porta un vantaggio evidente. Sì, gli esseri umani devono verificarla, perfezionarla e addestrarla, ma ovunque ci sia un obiettivo chiaro e si sappia come raggiungerlo con l'IA, il processo migliora.

Perché l'IA ha bisogno del contesto giusto prima di essere integrata nei flussi di lavoro

Quando si parla di IA, il contesto è tutto.

Un tempo scrivevo articoli per il blog basandomi sul brief di uno specialista SEO. Ci volevano dalle due alle tre ore. Poi ho caricato il contesto del progetto in un LLM e gli ho fornito direttamente il brief: ora gli articoli richiedono 5-7 minuti. E, come ho detto sopra, sono di qualità superiore e portano a raddoppiare il traffico.

Ma quando ho chiesto allo specialista SEO di scriverli con l'IA, sono rimasto sorpreso dalla scarsa qualità dei risultati. Il motivo? Il suo LLM aveva molto meno contesto sul progetto rispetto al mio.

Qualunque sia il flusso di lavoro, investi nel fornire il contesto ai tuoi strumenti di IA!

Perché i responsabili di prodotto devono rivedere radicalmente alcuni flussi di lavoro del prodotto, ma non necessariamente tutti

Il mio consiglio? Integra subito l'IA nella maggior parte dei tuoi processi. Non siamo più nel 2022; oggi il valore è evidente. L'IA è indispensabile.

I responsabili di prodotto dovrebbero riesaminare ogni processo e strumento precedentemente considerato ottimale. Ma questo non significa necessariamente rivederli tutti radicalmente con l'IA. Devi comprendere i limiti dell'IA, i tuoi punti di forza e di debolezza, il prodotto su cui stai lavorando, i budget e così via.

La configurazione sarà diversa per ogni progetto specifico. Tutto è flessibile. E non esistono buone pratiche consolidate. Questo complica le cose.

L'unico modo per capirlo per il tuo prodotto è sperimentare direttamente.

Le riflessioni di Anton

Il mio consiglio? Integra subito l’IA nella maggior parte dei tuoi processi. Non siamo più nel 2022; oggi il valore è evidente. L’IA è indispensabile.

Segui gli aggiornamenti

Puoi seguire il lavoro di Anton Ingachev su LinkedIn e GitHub. E dai un'occhiata a Mini Apps Builder.

Presto arriveranno altre interviste a esperti su The CPO Club!