Productexpertise verschijnt niet van de één op de andere dag. Het gehele productontwikkelingsproces leidt tot de creatie van "experts" rond bepaalde functies en functionaliteiten, en vormt de basis voor alle documentatie die de release voorafgaat en volgt.

Teams die Guru voor productenablement gebruiken, erkennen het belang van een enkele bron van waarheid voor kennis die de volledige productreleasecyclus omvat - van vroege ontwikkeling tot doorlopende ondersteuning en onderhoud. Door elke afdeling één betrouwbare plek te geven om door experts geverifieerde informatie te plaatsen, kan iedereen die betrokken is bij deze cross-functionele processen beter werk leveren. Laten we een recente functie-release bij Guru doorlopen als een voorbeeld van productenablement in actie.

In januari heeft ons nieuw gevormde Monetization pod gewerkt aan het eerste deel van een upgrade van de factureringservaring in Guru. Dit project omvatte het gebruikelijke productontwikkelingsteam – productmanagement, ontwerp, engineering en productmarketing – evenals verschillende andere belanghebbenden, waaronder financiën, ondersteuning en verkoopoperaties. Dit was een technische update die een goede communicatie en coördinatie vereiste tussen alle betrokken teams, evenals substantiële voorbereidingen zodat onze klantgerichte tegenhangers vol vertrouwen konden praten over deze wijzigingen. De volgende drie fases omvatten de belangrijkste manieren waarop we Guru gebruiken voor productenablement rondom functie-releases zoals deze.

Fase 1: Functieplanning en -ontwikkeling

Productenablement begint echt op het moment dat een project van het Productteam groen licht krijgt. Dit kan zijn voor een kleine functionaliteitsvernieuwing, een paginawijziging of een geheel nieuwe functie. Vanaf het moment dat de projectvereisten zijn opgesteld door een Product Manager (PM) en gedeeld zijn met hun engineers, ontwerpers en andere belanghebbenden, moet iedereen toegang hebben tot betrouwbare, actuele documentatie van verschillende auteurs.

Onze planning begon in december, met onze PM's die een paar belangrijke punten identificeerden in onze facturerings- en afrekenervaringen die vernieuwing nodig hadden. Van daaruit maakten ze een projectplan en begonnen ze met het opstellen van de vroege functiebeschrijving voor het eerste project in de reeks. Toen ze klaar waren om dit met het team te delen, plande ze een kickoff-vergadering om het team door de voorgestelde wijzigingen te leiden en de tijdslijnen te bespreken. Vanaf dit punt was het cruciaal dat iedereen die betrokken was bij het project toegang had tot al de gerelateerde documenten, inclusief de projectvereisten, ontwerpen, gerelateerde factureringsdocumentatie en meer.

Omdat deze documenten vaak veranderen en gedurende de vroege fasen van een project vaak worden toegevoegd, is het belangrijk om een betrouwbare waarheid te hebben waar het team op kan terugvallen. Om ervoor te zorgen dat iedereen één plek had om deze middelen te delen en te benaderen, hebben we een Actieve Projectbronnenkaart gemaakt om met het team te delen. We hebben dit binnen het Monetization Pod-bord geplaatst, waar alle relevante belanghebbenden toegang hebben als auteur.

Gedurende het ontwikkelingsproces hoefden onze engineers zich geen zorgen te maken over het bookmarken van ontwerpbestanden of het dubbel controleren of de tekst die vorige week aan hen was gegeven nog actueel was. In plaats daarvan konden ze tijdens het werken terugverwijzen naar de Actieve Projectbronnenkaart, waarmee ze zich verzekerden dat ze gebruik maakten van de meest actuele informatie. Zie hoe engineeringteams Guru gebruiken.

Fase 2: Voorbereiding release

Wij beschouwen functie-releases als een teamsport bij Guru. Naarmate we de fase van ontwikkeling naderen, moeten we ervoor zorgen dat we aan alle vereisten hebben voldaan, getest op potentiële pijnpunten voor klanten en de aanstaande wijzigingen goed hebben gecommuniceerd aan onze klantgerichte teams. Aangezien dit de fase is waarin informatie het meest waarschijnlijk snel verandert, is het van het grootste belang om ervoor te zorgen dat alle kennis door de betreffende experts is geverifieerd.

Voor ons recente factureringsproject hebben we één week gereserveerd voor het team en onze belanghebbenden om kwaliteit (QA) te waarborgen en de nieuwe klantbeleving te testen voordat deze live gaat. Aangezien dit een bijzonder technisch project was, waren er verschillende stappen betrokken bij het klaarzetten van omgevingen voor het testen, waaronder het inschakelen van functie-vlaggen en het doorgaan van een specifieke set replicatie-afrekenstappen. Om ervoor te zorgen dat iedereen alle informatie had die ze nodig hadden om deel te nemen aan het testen, heeft onze teamleider engineering een Kaart opgezet met stapsgewijze instructies voor deelname aan QA. We hebben deze Kaart naar onze Pod en belanghebbenden gestuurd via een aankondiging om ervoor te zorgen dat ze het hadden gelezen voordat ze met testen begonnen.

Tijdens de QA was het ook belangrijk om onze klantgerichte teams te informeren over de aanstaande wijzigingen om hen voor te bereiden op eventuele vragen van prospects of klanten. Hoewel deze wijzigingen voornamelijk gericht waren op gebruiksvriendelijkheid en betrouwbaarheid (ten opzichte van een grotere interface-wijziging), zouden sommige delen van de legacy factureringservaring met dit project gewijzigd worden. Om deze veranderingen tijdig te communiceren en voldoende tijd te geven voor beoordeling en vragen, hebben we onze Kaart met functiebreakdown van de facturering bijgewerkt.

Je zult merken dat dit de eerste keer is dat we in het proces het woord vernieuwen gebruiken in plaats van creëren, en dat is opzettelijk. We gebruiken functiebreakdown Kaarten als de levende waarheid over functies voor onze klantgerichte teams, wat betekent dat er altijd één bestaat voor al onze live functies. 

Wanneer we een bestaande functie bijwerken en verbeteren, werken we de functiebreakdown Kaart dienovereenkomstig bij. Dit voorkomt het eeuwenoude probleem dat een verkoper onzeker is of ze verouderde documentatie over een functie bekijken en paniek-berichten naar engineers sturen terwijl ze aan de telefoon zijn. Ze kunnen er zeker van zijn dat de Kaart over de factureringspagina waarop ze vorig jaar vertrouwden dit jaar even accuraat is, zoals geverifieerd door het team dat verantwoordelijk was voor de verbeteringen.

Fase 3: Release en verder

De meest voor de hand liggende toepassing van productenablement kan heel goed rond de lancering van de nieuwe of verbeterde functie zijn. Van overzichten zoals de functiebreakdown Kaart hierboven tot zeer technische, specifieke troubleshooting Q&A's, gaat er veel in de zorg ervoor dat klantgerichte teams zijn toegerust met alles wat ze nodig hebben om elke release te verkopen en te ondersteunen. En naarmate functies in de loop van de tijd worden herhaald en verbeterd, blijft het cruciaal dat alle documentatie actueel en reflecterend is voor de huidige staat van het product.

Het is geen verrassing dat factureringspagina's ongelooflijk complex en genuanceerd zijn, wat betekent dat er geen tekort is aan potentiële vragen die klanten kunnen hebben tijdens het afronden van een afrekenproces. Hoewel onze factureringservaring iets is waar ons verkoopteam waarschijnlijk niet in detail over hoeft te spreken, is het een gebied waar ons ondersteuningsteam vaak klanten helpt navigeren. Ter voorbereiding op deze lancering en aanstaande verbeteringen aan onze afrekenervaring, werkte onze teamleider engineering samen met onze klantondersteuningskampioen om een lijst van technische veelgestelde vragen op te stellen, die wordt aangevuld naarmate er nieuwe vragen ontstaan. Dit biedt niet alleen het ondersteuningsteam, maar ook iedereen die klantvragen over facturering beantwoordt een consistente plek om eerst te controleren voordat ze contact opnemen met ons team (en vervolgens, toe te voegen aan de technische FAQ Kaart!).

Naast het up-to-date houden van de FAQ Kaart naarmate de iteraties vorderen, blijft ook de functiebreakdown Kaart actueel. Naast het opmerken van de officiële lanceringsdatum en belangrijke gesprekspunten over de nieuwe factureringservaring, linken we naar andere gerelateerde Kaarten en middelen, net als deze blogpost. Door een one-stop-shop te creëren om toegang te krijgen tot alle beschikbare informatie over een functie, geven we onze klantgerichte teams het vertrouwen om met een volledig geïnformeerd perspectief tegen klanten en prospects te spreken.

Om deze cirkel te sluiten, kunnen we niet vergeten hoe klant- en markfeedback een belangrijke rol speelt in de productontwikkelingscyclus. Naarmate onze teams nieuwe en verbeterde functies naar onze bestaande klanten en onze markt brengen, verzamelen we waardevolle inzichten in wat hen helpt beter werk te leveren, en waar ze hopen dat we ons de volgende keer op richten. Documentatie en het delen van deze informatie met ons productteam is een belangrijk onderdeel van ons iteratieve ontwikkelingsproces, en helpt ons om de meeste waarde te bieden aan onze klanten. En documentatie over hoe verschillende soorten feedback te delen (opnames van telefoongesprekken, e-mails, enz.) wordt bewaard in—je raadt het al—Guru.