Produktchefen lanserar en funktion. Funktionen ska lösa ett kundproblem och driva kundbehållning.
Två veckor efter lanseringen: minskar funktionen kundbortfallet? Är det fler kunder som använder funktionen? Lägger kunder mer tid i funktionen?
Utan en produktdashboard väntar produktchefen sex veckor på månadsrapporten för att se funktionens effekt. Då har kundernas reaktioner svalnat. Går inte att iterera.
Med en produktdashboard ser produktchefen efter två veckor: användningen av funktionen är 5 % (målet var 20 % efter vecka två). Problemet syns direkt. Produktchefen utreder. Upptäcker att funktionen är svår att hitta. Lägger till ett meddelande i introduktionen. Användningen går upp till 15 % efter vecka fyra.
Produktdashboards: funktionsanvändning och engagemang
Andel som använder funktionen
Funktionen lanserades för två veckor sedan. Berättigade användare: 10 000. Användare som har använt funktionen: 500. Användningsgrad: 5 %. Målet var 20 % efter vecka fyra. Ligger efter just nu. Utredning behövs.
Engagemang i funktionen
Av de 500 användare som provade funktionen, hur många använder den dagligen? 200. Hur många använder den varje vecka? 300. Hur många har slutat använda funktionen? 200. Engagemang: 40 % dagligen, 60 % varje vecka, 40 % har slutat. Avhoppen är för höga. Funktionen fastnar inte.
Tid som läggs i funktionen
Den genomsnittliga sessionen i funktionen är två minuter. Före funktionen var den genomsnittliga sessionstiden på webbplatsen tio minuter. Funktionen drar användare bort från andra funktioner. Är det avsiktligt? Ersatte funktionen en äldre funktion eller är den ett tillägg?
Effekt på kundbehållning
Kunder som började använda funktionen: 8 % bortfall per månad. Kunder som inte började använda funktionen: 12 % bortfall per månad. Funktionen fungerar. Förbättring av bortfallet med fyra procentenheter. För en kundbas på tusen kunder är det 40 färre kunder per månad. 40 gånger 50 (genomsnittligt kundvärde) är 2 000 i sparade intäkter per månad.
Driftdashboards: systemhälsa och prestanda
Drifttid
Webbplatsen var uppe 99,95 procent av tiden förra veckan. Målet är 99,99 procent. Vi ligger under målet. Två avbrott: ett på tio minuter, ett på femton minuter. Tillsammans 25 minuters driftstopp. Vad orsakade avbrotten? Går de att förhindra?
Svarstid
Den genomsnittliga svarstiden för API är 200 millisekunder. P95-svarstiden är 500 millisekunder (95 procent av anropen är snabbare, fem procent är långsammare). P99 är en sekund. Långsamma svarstider förekommer ibland. Är de acceptabla?
Felfrekvens
En procent av API-anropen gav fel. Upp från 0,5 procent förra veckan. Felfrekvensen fördubblades. Vad ändrades? En databasfråga är långsammare. Svarstiderna ökade. Kunder får tidsgränsfel och försöker igen. Utredning behövs.
Databasens anslutningspool
Poolen har 100 anslutningar. Just nu är 100 öppna (fullt utnyttjad). Inga fler anslutningar finns. Om ännu ett anrop kommer hamnar det i kö. Användaren upplever väntetid. Poolen är full. Behöver utökas eller användningen minskas.
Träffgrad i cachen
Cachen träffas 50 procent av gångerna. 50 procent av trafiken behöver ingen databasfråga. En missfrekvens i cachen på 50 procent är acceptabel för de flesta webbplatser. Under 40 procent är databasen överbelastad. Över 70 procent cachar du för mycket.
Verkligt exempel: produkt- och driftdashboard för ett SaaS-företag
Produktmått
Ny dashboardfunktion: lanserades månad ett. Berättigade användare: 5 000 (kunder med fler än tio datapunkter). Användare som skapade en dashboard: 1 000. Användningsgrad: 20 %. På målet.
Av de 1 000 som skapade en dashboard: Dagligen aktiva: 600. Bra engagemang. Veckovis aktiva: 900. De flesta använder den minst varje vecka. Slutat: 100. Tio procents bortfall.
Effekt på kundbehållning: kunder med aktiva dashboards har 2 % bortfall per månad. Kunder utan dashboards har 4 % bortfall per månad. Dashboarden minskar bortfallet med två punkter. För en kundbas på tusen kunder är det tjugo kunder. Med ett månatligt värde på 100 dollar per kund är det 2 000 i sparade intäkter per månad. 24 000 per år.
Driftmått
Drifttid förra månaden: 99,92 procent. Mål: 99,95 procent. Vi missade målet.
Avbrott: En incident: tio minuter, betalningar nere. Orsak: databasens växling till reservsystemet tog för lång tid. En incident: femton minuter, topp av tidsgränsfel i API. Orsak: trafikökning plus långsam databasfråga.
Svarstid: Genomsnitt: 150 millisekunder. Bra. P95: 300 millisekunder. Acceptabelt. P99: en sekund. Det är för högt. En procent av kunderna upplever en sekunds väntetid. Behöver optimeras.
Felfrekvens: 0,8 procent. Upp från 0,4 procent för två veckor sedan. Utredningen visar: fel vid betalningar har ökat eftersom betalningsleverantören hade ett avbrott förra veckan (inte vårt fel), API-fel har ökat eftersom vi släppte en kodändring som förstörde en ändpunkt (vårt fel).
Databas: Genomsnittlig frågetid: 30 millisekunder. Utnyttjande av anslutningspoolen: 80 procent. Friskt. Andel långsamma frågor: 0,2 procent. Acceptabelt.
Träffgrad i cachen: 65 procent. Friskt.
Koppla ihop produkt- och driftdashboards
Användningen av funktioner beror på systemets prestanda. Om systemet är långsamt blir användningen av funktioner lidande. Den nya dashboardfunktionen har låg användning. Kontrollera driftdashboarden. P99-svarstiden är en sekund. Användare upplever fördröjning när de öppnar dashboarden. Lägg till i utredningen: orsakar den långsamma prestandan den låga användningen? Om ja, optimera systemets prestanda först. Mät sedan användningen igen.
Systemets prestanda mäts för drifttid, inte för effekten av funktioner. Men effekten av funktioner beror på drifttiden. Koppla ihop de två dashboardarna. När driftmåtten försämras försämras också produktmåtten.
Vanliga frågor
Hur ofta ska produktchefen kontrollera användningen av en funktion?
Första veckan: dagligen. Funktionen har just lanserats och användningskurvan är som brantast. Du behöver fånga problem tidigt. Vecka två till fyra: tre gånger i veckan. Användningskurvan planar ut. Veckovisa uppdateringar räcker. Efter första månaden: varje vecka. Användningen har stabiliserats eller växer stadigt. En kontroll per vecka räcker. Undantag: om funktionen är kritisk eller om den tidiga användningen ligger under målet fortsätter den dagliga övervakningen tills problemet är löst. Med WEMASY webbplatsbyggare kan du ställa in det direkt på din webbplats.
Vilken användningsgrad av en funktion är acceptabel per vecka?
Vecka ett: 5 till 15 % (folk provar). Vecka två: 10 till 30 % (mun till mun sprider sig). Första månaden: 20 till 50 % (stabil nivå). Skiljer sig mellan funktioner. Spelfunktioner kan nå 90 % användning. Funktioner för efterlevnad kanske bara når 10 %. Målet ska bygga på användarsegment och funktionens betydelse, inte på ett allmänt riktmärke. Bestäm före lanseringen: är funktionen för alla eller bara för ett segment? Det avgör målet.
Hur skiljer vi mellan användning och engagemang?
Användning är att prova funktionen (har de använt den minst en gång). Engagemang är att använda den upprepade gånger (dagligen, varje vecka, varje månad). En funktion kan ha hög användning och lågt engagemang (alla provade, få stannade). En funktion kan ha låg användning och högt engagemang (få provade, men de som provade älskade den). Båda måtten spelar roll. Hög användning plus högt engagemang är framgång. Lågt engagemang betyder att funktionen inte löser ett verkligt problem. Låg användning betyder ett problem med att funktionen går att hitta.
Ska produktdashboarden innehålla kundfeedback eller bara mått?
Ta med båda. Mått visar vad kunder gör. Feedback visar varför. 500 användare slutade använda funktionen (mått). Feedbacken säger ”funktionen är svår att hitta” eller ”funktionen löser inte mitt problem” (varför). Mått utan feedback är ofullständiga. Lägg till ett avsnitt för feedback som visar de tre vanligaste orsakerna till bortfall eller att användare slutar, utifrån supportärenden och enkäter. Genomförande: lägg till ett kommentarsfält i funktionen. Varje vecka: läs de tjugo viktigaste kommentarerna och sortera dem i teman. Redovisa teman på dashboarden.
Hur sätter vi mål för drifttid och svarstid?
Bygg målen på påverkan på kunder och branschstandarder. För e-handelns kassa: drifttid 99,9 procent, svarstid under två sekunder. För marknadsföringssajt: drifttid 99 procent, svarstid under tre sekunder. För interna verktyg: drifttid 95 procent, svarstid under fem sekunder. Ju mer kritisk tjänsten är, desto strängare mål. När du sätter ett mål, vet vilken investering som krävs. 99,99 procents drifttid (fyra nior) kostar tre till fyra gånger mer än 99 procents drifttid (två nior). Se till att målet är värt kostnaden.
Ska driftdashboarden utlösa larm eller bara visa status?
Båda. Dashboarden visar aktuell status. Larm utlöses när tröskelvärden passeras. Om felfrekvensen går över 1 procent i fem minuter går ett larm. Larmet går till utvecklaren i jour som utreder. Dashboarden är för övervakning under ordinarie tider. Larmet är för tider utanför arbetstid eller kritiska lägen. Ingen av dem räcker ensam. En dashboard utan larm betyder att problem upptäcks under arbetstid. Larm utan dashboard betyder att teamet är blint för långsam försämring tills larmet går. Använd båda tillsammans.