Faktum: Kommunikation om produktlanseringar är problematisk

Syftet med produktens lanseringsnoter är att informera interna team (från ingenjör till kundsupport) och externa intressenter (kunder och partners) om att det har skett förändringar i produkten. Inom teknik, där allt går i ljus hastighet, är det en gammal utmaning att leverera produktuppdateringar via lanseringsnoter.

Varje företag där jag har arbetat har kämpat med att få lanseringsnoterna "rätt". Men det är en svår sak att få rätt; betydelsen av varje förändring eller produktlansering varierar beroende på publiken, hur den förändringen påverkar en viss grupps interaktion med funktionen, och hur den gruppen använder hela produkten varje dag.

Dessa kommunikationer om produktlanseringar (vanligtvis kända som lanseringsnoter) måste levereras till publiker som bryr sig om olika saker. Som ledare för Revenue Empowerment på Guru, är mina intressenter alla vars förmåga att utföra sitt jobb påverkas av produktens färdplan, inklusive:

• Produkt-/design-/ingenjörsteam
• Försäljningsteamet (Försäljningsoperationer, Intern försäljning, Kontohanterare över segment)
• Kundupplevelse (framgångschefer och supportrepresentanter)
• Marknadsföringsteamet (Produktmarknadsföring, Tillväxtmarknadsföring, Varumärke, Innehåll som kommer att leda GTM-strategin och pressutmärkelser för produkten)
• Affärsutveckling och partners

Alla dessa partners måste ta till sig produktuppdateringar och omedelbart avgöra i vilken omfattning de behöver tillämpa dessa uppdateringar på sina jobb. De måste också överväga hur de kan hjälpa slutanvändare att förstå den påverkan eventuella förändringar kommer att ha på dem.

Den person (eller grupp) som skapar lanseringskommunikationen måste överväga alla de publiker som kommer att konsumera produktkunskapen. Vad är konsekvenserna av lanseringen för en backend-ingenjör jämfört med en potentiell kund inom detaljhandeln?

Hur inte närma dig lanseringsnoter

Även om det är svårt att ta hänsyn till behoven hos olika publiker, är det också helt enkelt inte skalbart för en produktchef eller en produktmarknadsföringsansvarig (PMM) att skriva fem olika versioner av interna lanseringsnoter. I min erfarenhet är lanseringsnoter antingen för långa och ur sammanhang eller har inte tillräckligt med teknisk kapacitet. Statisk lanseringsnoter ger inte denna insikt och är ofta skrivna för författaren, inte för personen som behöver förstå vad som har förändrats. Ärligt talat, de är vanligtvis förlorade möjligheter.  

Jag har deltagit i timslånga, veckovisa samtal om lanseringsnoter där en monoton röst från produktledning går igenom punkter på bilder. Efter samtalet får den samme produktchefen e-post, telefonsamtal (kom ihåg dem?), Slacks osv. från alla, från kundsupport till försäljning som vill veta vad dessa förändringar betyder för dem, deras kunder och potentiella kunder. Om du missade samtalet, missade du nyanser och kontext, och fick istället bara den råa ändringsloggen.

Men det är inte produktchefsens ansvar att göra denna heliga översättning; deras jobb är att bygga en produkt som löser ett problem för marknaden. Det är PMM:s jobb att översätta den avsikten så att marknaden förstår dess värde.

Hemligheten bakom att skriva fantastiska lanseringsnoter

Jag är ett stort fan av Sound of Music (chockerande, jag vet) och som en enablementprofessionell ringer filmens tidlösa lektioner sanna. "Låt oss börja på helt början; det är en mycket bra plats att börja", går genom mitt huvud på en veckobasis. Så, i att forma eller omforma en produktleveransprocess måste du lära dig språket innan du kan undervisa ämnet.

1. Utveckla ett internt lexikon

Det första steget i att gräva i denna process betyder att få hela teamet att prata samma språk. Att socialisera delad terminologi verkar uppenbart, men det kanske inte händer i hela din organisation. Att inte känna till akronymer och att missförstå språket kan vara isolerande och skapa förvirring och silos mellan team.

Exempel: Vårt marknadsföringsteam använder termen "lansering" för att beskriva när och hur vi går till marknaden med en funktion. Ingenjörsteamet använder dock ordet "lansering" för att beskriva när en funktion har släppts till vår stagingmiljö. Den funktionsspecifika lanseringen är "klar" för ingenjörerna innan våra kunder känner till det. Detta var förvirrande och internt motstridigt.

Ingen vill vara den som offentligt erkänner att de inte förstår vad något betyder genom att ställa frågor om definitioner. Vår lösning: I en tvärfunktionell arbetsgrupp (med representation från ingenjör, produkt, produktmarknadsföring) utvecklade vi nyanserna och dokumenterade våra produktlanseringsdefinitioner:

Obs: Om några av korten misslyckas med att ladda, uppdatera sidan!

2. Vad som ska ingå i dina lanseringsnoter

När ett delat språk har etablerats och ditt team kan formulera lanseringsterminologin kan du skriva dina noteringar. Det enklaste är att skapa en återanvändbar mall för att skriva lanseringsnoter. På så sätt blir intressenterna bekanta med formatet efter några iterationer och sparar dig besväret att behöva uppfinna hjulet på nytt varje gång.

Minst goda lanseringsnoter inkluderar:

• Lanseringsdatum
• Intern och extern
• En beskrivning av funktionen eller buggen
• De produkt(er) som påverkas (om du har mer än en)
• Om du har flera mjukvaruprodukter kanske du också vill inkludera versionnummer
• Var frågor kan ställas internt

Bra lanseringsnoter inkluderar dock också:

• Förväntade vanliga frågor (FAQs)
• Länk till ny offentlig dokumentation, om tillgänglig
• För funktioner:
• Namnet på funktionen
• Skärmbilder på hur funktionen ser ut
• Video om hur man demonstrerar funktionen
• Varför funktionen existerar
• Hur det påverkar relevanta köpare/kundpersonas

Här är mallen vi använder internt (känn dig fri att kopiera!):

💡Obs: Det är bra att tilldela direkt ansvariga individer för denna uppgift (snarare än att lämna det till en gruppinsats där ingen äger det). Ingenjörer eller produktchefer bör äga den tekniska sidan av noterna (namn/version/produkt/datum/skärmbilder), medan produktmarknadschefer eller försäljningsingenjörer bör äga den kontextuella informationen (köparpersonas/vad det betyder).

Implementera en strategi för produktleveransprocessen

Skapa ett konsekvent kommunikationsformat

Nu när du har enat terminologin och skrivit din mall, är nästa steg att eniga om ett konsekvent leveransmedium (dvs. Slack, e-post, Loom, Guru, Google Docs) och metodologi. Ett konsekvent leveransmedium säkerställer att dina intressenter för lanseringsnoter vet var de ska gå eller titta eller prenumerera (för att hämta) för att vara medvetna om en lansering.

Detta är också väsentligt för ändringshantering eftersom du i allmänhet måste berätta för någon något flera gånger för att säkerställa att de fullt ut absorberar det. Beroende på typen av lansering, förändringarna i UI/UX (användargränssnitt och användarupplevelse), samt påverkan på kunden, kommer din publik för lanseringsnoter att behöva bli tryckta med produktkunskap (för att trycka). På Guru använder vi både tryck- och dra-metodologier.

Dra: Där man hittar kunskap

För oss kan intressenter följa i vår Slack #release-notes kanal, där det finns ett konsekvent och lättillgängligt format för allt från buggfixar till helt nya funktioner. Tänk på att era respektive publiker inte bara måste vara medvetna om att lanseringarna sker (via dra i Slack eller e-post) utan viktigare, att de behöver veta varför den lanseringen är viktigt i kontext.

Kunskapen om att en lansering helt enkelt kommer hända eller har hänt är inte värdefull såvida inte ditt team faktiskt kan göra något med den. För att utveckla ett konsekvent format som skulle ge lämplig kontext, frågade jag försäljningsrepresentanter, kontoutsättningsrepresentanter, affärsutvecklingsfolket (det hela), för att etablera vår mall för produktleverans som vi kallar “Feature Breakdown Card”, som du kan hitta ovan.

När en ingenjörschef börjar utvecklingen av en ny funktion, varnas direkt ansvariga individer via Asana för att skapa den funktionsspecifika Feature Breakdown Carden med hjälp av mall för lanseringsnoter. Det nya Feature Breakdown-kortet blir den robusta, enda sanningskällan eller "hjärnan av funktion" som vi släpper. Ämnesexperter (SME) — såsom PMM och försäljningsingenjörer — inkluderar detaljer om varför lanseringen är värdefull, för vem den betyder mest, och där det är tillämpligt, vägledning om hur man demonstrerar funktionen som en del av en större berättelse.

Intressenterna för lanseringsnoterna, särskilt kontohanterare, återvänder till samma kort gång på gång eftersom de har lärt sig att den dynamiska kunskapen på Feature Breakdown Carden är pålitlig, relevant och tillämpbar. Publiken talar nu både samma språk och läser från samma (dynamiska) manus. En återgång till Feature Breakdown-kortet är fortfarande en del av en "dra" metod eftersom det är självdrivet, och görs för att förbereda sig för ett sälj- eller supportanrop, eller om en möjlighet har en fråga om färdplanen.

Tryck: Proaktivt tillhandahållande av kunskap

Tryckmetoden kommer i spel när kunskap om en lansering är tidskänslig, och kritisk för specifika team. Här åstadkoms detta genom Gurus annonseringsfunktion. Beroende på påverkan på mina interna publiker trycker jag en annons via Guru till en relevant grupp. Jag kan sedan se en rapport om de som har bekräftat eller läst varningen och offentligt skämma bort påminna dem som inte har.  

Varför en kunskapsdriven kultur är nyckeln 🗝

Trots allt ovanstående är det inte så enkelt som att komma överens om terminologi, skriva fantastiska lanseringsnoter och skapa en mekanism för dynamisk produktleverans. Team behöver kunna samarbeta om kunskap och ge feedback över tid. För oss betyder det att när kunskapskonsumenter (i detta fall, intressenter för lanseringsnoter) har en fråga eller lär sig något nytt kommenterar de på Feature Breakdown-kortet.

För oss betyder det att när kunskapskonsumenter (i det här fallet, intressenter för releaseanteckningar) har en fråga eller lär sig något nytt, kommenterar de på Feature Breakdown Card. Vi inkorporerar också frågor som ställts och besvarats i Slack genom att kommentera som ett sätt att kontinuerligt förbättra kunskap. Ämnesexperten (vanligtvis PMM) kommer att granska och inkorporera den nya kunskapen eller relevanta frågan, och sätta den i kontext i den specifika Feature Breakdown-kortet.

Vi gör också alla våra lanseringsnoter lätt tillgängliga genom att sätta dem i antingen de kommande eller lanserade sektionerna av vår Feature Breakdown-tavla, där de kan ordnas vidare internt. På så sätt är de lätta att följa vid en första anblick. Om du inte använder Guru, rekommenderar vi att du försöker skapa en lanseringsnotessida, eller länkad ändringslogg.

Som med alla andra processer, så utvecklas denna ständigt. Produktleverans och lanseringsnoter är aldrig så enkelt som en engångsakt. När behovet för ditt företag ändras, bör din process, ansvar och mallar förändras med dem. Men genom att sträva efter enkel förståelse, kontext och användbarhet, kan du inte förlora.