Produktens expertis syns inte över en natt. Hela produktutvecklingsprocessen är vad som skapar "experter" kring specifika funktioner och egenskaper, och är grunden för all dokumentation som föregår och följer deras lansering.

Team som använder Guru för produktaktivering inser vikten av att ha en enda källa till sanning för kunskap som omfattar hela produktens utgivningslivscykel – från tidig utveckling till pågående support och underhåll. Genom att ge varje avdelning en överenskommen, pålitlig plats för att lägga information som verifierats av experter, kan alla som är involverade i dessa tvärfunktionella processer göra bättre arbete. Låt oss gå igenom en nyligen lanserad funktion hos Guru som ett exempel på produktaktivering i praktiken.

Under januari arbetade vår nybildade intäktsgrupp pod med den första delen av en uppgradering av faktureringsupplevelsen i Guru. Detta projekt involverade det vanliga produktutvecklingsteamet – produktledning, design, teknik och produktmarknadsföring – samt flera andra intressenter inklusive ekonomi, support och försäljningsoperationer. Detta var en teknisk uppdatering som krävde tight kommunikation och samordning mellan alla involverade team, samt omfattande förberedelsearbete för att möjliggöra att våra kundvända motsvarigheter kan tala säkert om dessa förändringar. De följande tre faserna sammanfattar de huvudsakliga sätten vi använder Guru för produktaktivering kring funktionslanseringar som denna.

Fas 1: Funktionsplanering och utveckling

Produktaktivering börjar verkligen när projektet från en Produktteam får grönt ljus. Detta kan vara för en mindre funktionsförbättring, en sidomvandling eller en helt ny funktion. Från det att projektets specifikationer upprättas av en Produktchef (PM) och delas med sina ingenjörer, designers och andra intressenter, behöver alla tillgång till tillförlitlig, uppdaterad dokumentation från en mängd olika författare.

Vår planering började i december, med våra PM:er som identifierade ett par nyckelplatser i våra fakturerings- och checkoutupplevelser som behövde fräschas upp. Därifrån skapade de en projektplan och började utarbeta en tidig funktionsspecifikation för det första projektet i serien. När de var redo att dela med teamet schemalade de ett kickoffmöte för att gå igenom de föreslagna förändringarna och diskutera tidslinjer. Från denna punkt var det avgörande att alla involverade i projektet hade tillgång till alla relaterade dokument, inklusive projektets specifikationer, designer, relaterad fakturadokumentation och mer.

Eftersom dessa dokument ofta ändras och kan läggas till ofta under de tidiga faserna av ett projekt är det viktigt att ha en pålitlig källa till sanning som teamet kan återkomma till. För att säkerställa att alla hade en enda plats att dela och få tillgång till dessa resurser skapade vi ett Aktiva Projektresurskort som skulle delas med teamet. Vi placerade detta inom Monetization Pod Board, där alla berörda intressenter har författartillgång.

Under utvecklingsprocessen behövde våra ingenjörer inte oroa sig för att bokmärka designfiler eller dubbelkolla om kopian som gavs till dem förra veckan fortfarande var aktuell. Istället kunde de hänvisa till Aktiva Projektresurskort medan de arbetade, vilket säkerställde att de byggde på den mest aktuella informationen. Se hur ingenjörsteamen använder Guru.

Fas 2: Förberedelse för lansering

Vi ser funktionslanseringar som en lagaktivitet på Guru. När vi närmar oss slutet av utvecklingen måste vi säkerställa att vi har uppfyllt alla krav, testat potentiella kundproblem och kommunicerat de kommande förändringarna korrekt till våra kundvända team. Eftersom detta är fasen där information mest sannolikt ändras snabbt, är det av största vikt att säkerställa att all kunskap verifieras av respektive experter.

För vårt nyligen faktureringsprojekt avsatte vi en vecka för teamet och våra intressenter att genomföra kvalitetskontroll (QA) och testa den nya kundupplevelsen innan den går live. Eftersom detta var ett särskilt tekniskt projekt involverade det flera steg för att förbereda miljöer för testning, inklusive aktivering av funktionsflags och arbete genom en specifik uppsättning av replika-utcheckningssteg. För att säkerställa att alla hade all information de behövde för att delta i testningen, skapade vår ingenjörschef ett kort med steg-för-steg-instruktioner för att delta i QA. Vi skickade detta kort till vårt Pod och våra intressenter via en tillkännagivande för att säkerställa att de hade läst det innan de började testa.

När QA pågick var det också viktigt att informera våra kundvända team om de kommande förändringarna för att förbereda dem för eventuella frågor från potentiella kunder eller kunder. Även om dessa förändringar i stor utsträckning var fokuserade på användbarhet och tillförlitlighet (jämfört med en större gränssnittsändring) skulle vissa delar av den äldre faktureringsupplevelsen att ändras med detta projekt. För att kommunicera dessa förändringar med tillräckligt med tid för att granska och ställa frågor, uppdaterade vi vårt kort för faktureringsfunktionens nedbrytning.

Du kommer att märka att detta är första gången i processen som vi använder ordet uppdatera istället för skapa, och det är avsiktligt. Vi använder kort för funktionsnedbrytning som den levande källan till sanning om funktioner för våra kundvända team, vilket innebär att det finns ett för alla våra aktiva funktioner hela tiden. 

När vi uppdaterar och förbättrar en befintlig funktion, uppdaterar och förbättrar vi funktionsnedbrytningkortet i enlighet med detta. Detta förhindrar det gamla problemet där en säljrepresentant är osäker på om de tittar på föråldrad dokumentation om en funktion och skickar meddelanden till ingenjörer i panik medan de är på ett samtal. De kan vara säkra på att kortet om faktureringssidan som de litade på förra året är lika korrekt i år, som verifierat av teamet som arbetar med förbättringarna.

Fas 3: Lansering och vidare

Den mest uppenbara tillämpningen av produktaktivering kan mycket väl handla om lanseringen av den nya eller förbättrade funktionen. Från översikter som funktionsnedbrytningkortet ovan till högteknologiska, specifika felsökningar och frågor & svar, går mycket åt för att säkerställa att kundvända team är utrustade med allt de behöver för att sälja och stödja varje release. Och eftersom funktionerna itereras och förbättras över tid, förblir det avgörande att all dokumentation hålls uppdaterad och återspeglar produktens nuvarande tillstånd.

Det är ingen överraskning att faktureringssidor är otroligt komplexa och nyanserade, vilket innebär att det inte saknas potentiella frågor som kunderna kan ha när de genomför en utcheckningsprocess. Även om vår faktureringsupplevelse troligen inte är något som vårt försäljningsteam kommer att behöva tala om i detalj, är det ett område som vårt supportteam ofta hjälper kunder att navigera. För att förbereda för denna lansering och ytterligare kommande förbättringar av vår utcheckningsupplevelse, arbetade vår ingenjörschef med vår kundsupportchampion för att sammanställa en lista över tekniska vanliga frågor (FAQ), som uppdateras i takt med att nya frågor dyker upp. Detta ger inte bara supportteamet, utan också vem som helst som svarar på kundfrågor om fakturering, en konsekvent plats att kontrollera först innan de kontaktar vårt team (och sedan lägga till den tekniska FAQ-kortet!).

Förutom att hålla FAQ-kortet uppdaterat när iterationer fortskrider, hålls också funktionsnedbrytningkortet alltid aktuellt. Förutom att notera det officiella lanseringsdatumet och viktiga samtalspunkter om den nya faktureringsupplevelsen, kommer vi att länka till andra relaterade kort och resurser, precis som detta blogginlägg. Genom att skapa en engångsgalleria för att få tillgång till all tillgänglig information om en funktion ger vi våra kundvända team förtroende att tala med kunder och prospekter med ett helt informerat perspektiv.

För att stänga denna loop kan vi inte glömma hur kund- och marknadsfeedback spelar en viktig roll i produktutvecklingscykeln. När våra team tar nya och förbättrade funktioner till våra befintliga kunder och vår marknad, samlar vi värdefull insikt om vad som hjälper dem att göra bättre arbete, och vad de hoppas att se oss fokusera på nästa. Dokumentation och delning av denna information med vårt produktteam är en viktig del av vår iterativa utvecklingsprocess och hjälper oss att leverera mest värde möjligt till våra kunder. Och dokumentation för hur man delar olika feedbackmetoder (samtalsinspelningar, e-post, etc.) hålls i – du gissade rätt – Guru.