I principi del prodotto Intercom: costruire in piccoli passi per offrire il massimo valore al cliente

Le modifiche di grandi dimensioni sono difficili da comprendere e più difficili da eseguire il debug.

In Intercom, forniamo modifiche complesse in una serie di passaggi piccoli, controllati e di facile comprensione. Le piccole modifiche sono più facili da creare e più veloci da rivedere, consentendoci di fornire valore ai clienti più rapidamente.

Questo è il settimo post di una serie che esplora i principi dei nostri prodotti . Qui, Aidan discute il nostro principio di ingegneria "Costruisci a piccoli passi".

Nessuno lo fa sempre bene

Gli errori accadono in ogni squadra, in ogni azienda nel mondo. Una volta che accetti che non lo farai sempre bene, puoi regolare in uno dei due modi seguenti:

• Cerca di correggere gli errori prima di spedirli, adottando misure per convalidare o controllare il tuo lavoro.
• Consenti a te stesso di sbagliare, impara dall'errore e adattati rapidamente per correggerlo.

Se hai già sprofondato settimane in un cambiamento, spesso c'è meno spazio per sbagliare. Questo può portarti a fare affidamento sulla convalida per evitare sorprese quando spedisci la modifica. La convalida ha il suo posto, ma è un povero sostituto per implementare qualcosa di reale. Maggiore è la convalida che devi eseguire prima della spedizione, più tempo ci vorrà prima di poter iterare o passare alla funzionalità successiva: alla fine ti rallenterà.

Quando spediamo un cambiamento, miriamo a controllare:

• Il numero di variabili interessate: più variabili sono interessate durante una modifica, più difficile è capire quale parte della modifica ha causato il problema. Riducendo le dimensioni di ogni passaggio, stringiamo il ciclo di feedback e ci prepariamo per imparare e adattarci molto più velocemente, se necessario.
• La dimensione della modifica: riducendo la dimensione delle nostre modifiche, riduciamo anche il raggio di esplosione di ogni modifica. È importante testare le modifiche, ma c'è solo così tanto che la convalida anticipata catturerà. Cambiamenti più piccoli ci consentono di concentrare la nostra attenzione sul raggiungimento incrementale del tuo obiettivo e di non essere troppo coinvolti nel garantire che ogni cambiamento sia perfetto.
• Quali clienti sperimentano il cambiamento: ci affidiamo ai flag delle funzionalità per convalidare le modifiche nella produzione e rilasciarle in modo incrementale ai clienti.

Non sappiamo con certezza se la funzione risolverà il problema di un cliente finché non lo avrà nelle loro mani. Questo impegno per la spedizione di piccole iterazioni si collega rapidamente a un altro principio Intercom: spedire per imparare.

Gestire la complessità

Costruire all'interno di sistemi complessi è impegnativo. Quando i bug emergono in grandi modifiche o le funzionalità gonfie mancano nel segno, è difficile individuare il problema specifico. Piccoli passi rendono più facile convalidare, modificare e andare avanti, sicuri di costruire su un terreno solido.

I grandi cambiamenti includono molte ipotesi:

• Presupposti esterni su come la tua modifica influirà sui flussi di lavoro dei tuoi clienti.
• Presupposti interni su come le diverse parti del tuo cambiamento interagiscono e dipendono l'una dall'altra.

Sebbene tu possa fare del tuo meglio per verificare i presupposti esterni, spesso è più rapido e affidabile inviare la modifica e convalidarla o modificarla. I presupposti interni sono i punti in cui la complessità può insinuarsi. Quando il tuo cambiamento diventa abbastanza grande da comprendere diversi elementi costitutivi che dipendono tutti l'uno dall'altro, testarli insieme può essere rischioso. È molto più sicuro rilasciarli in modo incrementale, costruendo uno sopra l'altro e monitorando l'impatto man mano che procedi.

La velocità durevole crea slancio

La velocità è ottima ma durevole, la velocità affidabile sta cambiando il gioco. Spedire un cambiamento di grandi dimensioni significa che c'è molto di più da sfruttare per avere successo e un rischio maggiore di sorprese rispetto a una serie di iterazioni piccole e veloci.

" Un ciclo serrato di spedizione di piccole modifiche, apprendimento e iterazione crea un forte slancio"

Un ciclo serrato di spedizione di piccole modifiche, apprendimento e iterazione crea un forte slancio. Elimina la necessità di avere ragione la prima volta, incoraggia un processo decisionale più rapido e riduce il raggio d'azione degli errori. Inoltre, suddividere il lavoro in unità più piccole significa che gli ingegneri possono far progredire il lavoro in parallelo, consentendo al team di muoversi più velocemente nel suo insieme.

Costruire a piccoli passi richiede la giusta cultura di squadra

Costruire a piccoli passi non avviene per caso, ci vuole un intento deliberato e l'ambiente giusto. La cultura del nostro team e lo stack dell'infrastruttura svolgono un ruolo cruciale nella nostra capacità di spedire rapidamente piccole modifiche.

Una volta che i team hanno compreso l'importanza di spedire rapidamente piccole modifiche, le revisioni tra pari hanno la priorità e vengono completate più rapidamente. Poiché le piccole modifiche sono più facili da comprendere e rivedere, ci sono più possibilità che vengano rilevati bug in ogni fase. Questa comprensione e urgenza del team accelera l'intero processo.

" Abbiamo investito in modo significativo per garantire che una volta che una modifica è stata rivista e unita a master, occorrano meno di 15 minuti per arrivare alla produzione, compresi i test automatizzati e la convalida della staging"

Quando i tempi di implementazione rallentano, gli ingegneri sono più inclini alle modifiche in batch, determinando un ciclo di modifiche più grandi. Abbiamo investito in modo significativo per garantire che una volta che una modifica è stata esaminata e unita a master, occorrano meno di 15 minuti per arrivare alla produzione, compresi i test automatizzati e la convalida della staging. È completamente automatico e gli ingegneri ricevono una notifica Slack automatica una volta che la modifica è attiva.

Applicazione del principio "costruire in piccoli passi" all'integrazione Salesforce di Intercom

L'anno scorso abbiamo cercato di integrare più profondamente Intercom con Salesforce, consentendo ai clienti di creare automaticamente casi Salesforce dalle conversazioni Intercom. Abbiamo subito capito la complessità; le conversazioni e i casi non sempre vengono mappati in modo diretto e sincronizzare i dati in una relazione molti-a-molti sarebbe impegnativo sia dal punto di vista ingegneristico che di progettazione. In aggiunta a ciò, c'era un'ampia variazione nel modo in cui i clienti desideravano utilizzare questa funzionalità e doveva adattarsi all'integrazione esistente da cui i clienti dipendono fortemente.

Dopo aver analizzato le molte implicazioni e compromessi di progettazione, abbiamo parcheggiato il progetto a favore di qualcosa che ritenevamo avrebbe prodotto un impatto più affidabile. Quasi non l'abbiamo costruito perché l'abbiamo affrontato come un grande cambiamento invece che come una serie di piccoli passi.

Abbiamo rivisitato il progetto con un approccio diverso

Non ci è voluto molto prima che il nostro team di vendita tornasse a sottolineare quanto fosse importante questa funzionalità per i nostri clienti e abbiamo deciso di darle un'altra occhiata. Questa volta abbiamo adottato un approccio diverso, iniziando con la versione più piccola possibile e aggirando parte della complessità fino a quando non abbiamo potuto imparare ciò di cui i clienti avevano veramente bisogno.

" I clienti con cui abbiamo lavorato hanno apprezzato molto il ritmo con cui il team ha ripetuto l'iterazione e il modo in cui la funzionalità si è evoluta giorno per giorno, guidati dal loro feedback"

In due settimane, io e un altro ingegnere abbiamo creato la versione più semplice di questa funzionalità che potremmo condividere con i clienti. Lo abbiamo fatto in molti piccoli passaggi assicurandoci di non interrompere nessuno dei flussi di lavoro esistenti che i clienti stavano già utilizzando. Ciò ha reso la funzionalità molto più tangibile e i clienti sono stati in grado di fornire un feedback specifico sulle lacune e sui miglioramenti del prodotto.

Una volta che i clienti lo utilizzavano, il team ha eseguito l'iterazione in piccoli passaggi, rendendo rapidamente la funzionalità più flessibile. Con l'aumento della flessibilità, è cresciuto anche il numero di clienti che lo utilizzavano e abbiamo ampliato rapidamente la versione beta.

Si è scoperto che la relazione molti-a-molti non ha impedito ai clienti di utilizzare la funzione e l'abbiamo lanciata con successo in modo sicuro e senza questa complessità aggiuntiva, cosa che abbiamo scoperto solo iniziando in piccolo e iterando rapidamente. I clienti con cui abbiamo lavorato hanno apprezzato molto il ritmo con cui il team ha ripetuto l'iterazione e come la funzionalità si è evoluta giorno per giorno, guidati dal loro feedback.

Costruire a piccoli passi funziona per tutti

Costruiamo in piccoli passi principalmente perché ci aiuta a fornire valore al cliente più velocemente in un modo più sicuro e più duraturo. Ma oltre a questo, come ingegnere, è un modo più carino di lavorare. È molto meno stressante rispetto alla spedizione di grandi cambiamenti in cui è molto importante che tu abbia ragione la prima volta e ricevi un normale colpo di dopamina ogni volta che spedisci ciò su cui stai lavorando alla produzione.

Quindi, se nulla in questo post del blog ti convince a ottimizzare per la riduzione del rischio e fornire valore incrementale, dovresti farlo perché è solo più divertente.

Interessato a saperne di più sul modo in cui lavoriamo in Intercom? Scopri di più.