En produktchef lancerer en funktion. Funktionen skal løse et problem for kunderne og skabe fastholdelse.
To uger efter lanceringen: mindsker funktionen frafaldet? Er der flere kunder, der bruger funktionen? Bruger kunderne mere tid i funktionen?
Uden et dashboard til produktet venter produktchefen seks uger på den månedlige rapport for at se, hvad funktionen har ført til. Da er kundernes feedback kold. Det er for sent at forbedre.
Med et dashboard til produktet ser produktchefen efter to uger: brugen af funktionen er fem procent (målet var tyve procent i uge to). Problemet er synligt med det samme. Produktchefen undersøger det. Finder ud af, at funktionen er svær at finde. Tilføjer en besked i onboarding. Brugen stiger til femten procent i uge fire.
Dashboards til produktet: brug af funktioner og engagement
Andel, der bruger funktionen
Funktionen blev lanceret for to uger siden. Brugere, der kan bruge den: ti tusind. Brugere, der har brugt funktionen: fem hundrede. Andel: fem procent. Målet var tyve procent i uge fire. Lige nu bagud. Det skal undersøges.
Engagement i funktionen
Af de fem hundrede brugere, der prøvede funktionen, hvor mange bruger den hver dag? To hundrede. Hvor mange bruger den hver uge? Tre hundrede. Hvor mange har droppet funktionen? To hundrede. Engagement: fyrre procent hver dag, tres procent hver uge, fyrre procent har droppet den. Frafaldet er for højt. Funktionen er ikke til at blive ved.
Tid brugt i funktionen
En gennemsnitlig session i funktionen er to minutter. Før funktionen var den gennemsnitlige tid på siden ti minutter. Funktionen trækker brugerne væk fra andre funktioner. Er det med vilje? Erstattede funktionen en ældre funktion, eller kommer den oven i?
Betydning for fastholdelse
Kunder, der tog funktionen i brug: otte procent frafald om måneden. Kunder, der ikke tog funktionen i brug: tolv procent frafald om måneden. Funktionen virker. Forbedring af frafaldet på fire procentpoint. For en kundebase på tusind er det fyrre færre kunder om måneden. Fyrre gange halvtreds (gennemsnitlig værdi pr. kunde) er to tusind i omsætning sparet om måneden.
Dashboards til driften: systemernes tilstand og ydelse
Oppetid
Hjemmesiden var oppe 99,95 procent af tiden i sidste uge. Målet er 99,99 procent. Vi er under målet. To nedbrud: ét på ti minutter og ét på femten minutter. Tilsammen femogtyve minutters nedetid. Hvad forårsagede nedbruddene? Kan de forebygges?
Svartid
Den gennemsnitlige svartid for API'et er to hundrede millisekunder. Svartiden for P95 er fem hundrede millisekunder (95 procent af forespørgslerne er hurtigere, fem procent er langsommere). P99 er et sekund. Langsomme svartider sker en gang imellem. Er de acceptable?
Andel af fejl
En procent af forespørgslerne til API'et gav fejl. Op fra nul komma fem procent i sidste uge. Andelen af fejl blev fordoblet. Hvad ændrede sig? En forespørgsel til databasen er langsommere. Svartiderne steg. Kunderne får tidsudløb og prøver igen. Det skal undersøges.
Forbindelser til databasen
Puljen har hundrede forbindelser. Lige nu er hundrede åbne (fuldt brugt). Der er ikke flere forbindelser. Kommer der en forespørgsel mere, kommer den i kø. Brugeren oplever ventetid. Puljen er fyldt. Du skal øge puljen eller bruge mindre.
Andel af hits i cachen
Cachen bruges halvdelen af tiden. Halvdelen af trafikken behøver ikke en forespørgsel til databasen. En andel af misser i cachen på halvtreds procent er acceptabel for de fleste sider. Under fyrre procent er databasen overbelastet. Over halvfjerds procent cacher du for meget.
Et rigtigt eksempel: dashboard til produkt og drift i SaaS
Tal for produktet
Ny funktion til dashboards: lanceret i måned et. Brugere, der kan bruge den: fem tusind (kunder med mere end ti datapunkter). Brugere, der lavede et dashboard: tusind. Andel: tyve procent. På målet.
Af de tusind, der lavede et dashboard: Aktive hver dag: seks hundrede. Godt engagement. Aktive hver uge: ni hundrede. De fleste bruger det mindst hver uge. Droppet: hundrede. Ti procent frafald.
Betydning for fastholdelse: kunder med aktive dashboards har to procent frafald om måneden. Kunder uden dashboards har fire procent frafald om måneden. Dashboardet sparer to point i frafald. For en kundebase på tusind er det tyve kunder. Med hundrede dollar i værdi pr. kunde om måneden er det to tusind i omsætning sparet om måneden. Fireogtyve tusind om året.
Tal for driften
Oppetid sidste måned: 99,92 procent. Mål: 99,95 procent. Vi missede målet.
Nedbrud: Én hændelse: ti minutter, betalinger nede. Årsag: skiftet til reserven i databasen tog for lang tid. Én hændelse: femten minutter, spring i tidsudløb for API'et. Årsag: stigning i trafikken plus en langsom forespørgsel til databasen.
Svartid: Gennemsnit: et hundrede og halvtreds millisekunder. Godt. P95: tre hundrede millisekunder. Acceptabelt. P99: et sekund. Det er for højt. En procent af kunderne oplever en ventetid på et sekund. Skal optimeres.
Andel af fejl: nul komma otte procent. Op fra nul komma fire procent for to uger siden. Undersøgelsen viser: fejl i betalinger er steget, fordi betalingsudbyderen havde et nedbrud i sidste uge (ikke vores skyld), og fejl i API'et er steget, fordi vi udgav en ændring i koden, der ødelagde ét endpoint (vores skyld).
Database: Gennemsnitlig tid for en forespørgsel: tredive millisekunder. Brug af puljen af forbindelser: firs procent. Sund. Andel af langsomme forespørgsler: nul komma to procent. Acceptabelt.
Andel af hits i cachen: femogtres procent. Sund.
Kobl dashboards til produkt og drift sammen
Brugen af funktioner afhænger af systemets ydelse. Hvis systemet er langsomt, lider brugen af funktionerne. Den nye funktion til dashboards bliver lidt brugt. Se på dashboardet til driften. Svartiden for P99 er et sekund. Brugerne oplever forsinkelse, når de åbner dashboardet. Tag det med i undersøgelsen: er den langsomme ydelse årsagen til den lave brug? Hvis ja, så optimer først systemets ydelse. Mål derefter brugen igen.
Systemets ydelse måles på oppetid og ikke på betydningen for funktioner. Men betydningen af en funktion afhænger af oppetiden. Kobl de to dashboards sammen. Når tallene for driften bliver dårligere, bliver tallene for produktet det også.
Ofte stillede spørgsmål
Hvor ofte skal produktchefen se på brugen af en funktion?
Første uge: hver dag. Funktionen er lige lanceret, og kurven for brug er stejlest. Du skal fange problemer tidligt. Uge to til fire: tre gange om ugen. Kurven for brug flader ud. Opdateringer hver uge er nok. Efter første måned: hver uge. Brugen har fundet et leje eller vokser jævnt. Et tjek hver uge er nok. Undtagelse: hvis funktionen er kritisk, eller hvis den tidlige brug er under målet, så fortsæt med at overvåge hver dag, til problemet er løst. Med WEMASY's hjemmesidebygger kan du sætte det op direkte på din hjemmeside.
Hvad er en acceptabel andel, der bruger funktionen, uge for uge?
Uge et: fem til femten procent (folk prøver). Uge to: ti til tredive procent (det spreder sig fra mund til mund). Måned et: tyve til halvtreds procent (det, der falder til ro). Det er forskelligt fra funktion til funktion. Funktioner i spil kan nå halvfems procent. Funktioner til overholdelse af regler når måske kun ti procent. Målet bør bygge på brugersegmentet og funktionens betydning og ikke på et generelt tal. Beslut før lanceringen: er funktionen til alle eller kun til et segment? Det afgør målet.
Hvordan skelner vi mellem at tage i brug og engagement?
At tage i brug er at prøve funktionen (brugte de den mindst én gang). Engagement er at bruge den igen og igen (hver dag, hver uge, hver måned). En funktion kan have mange, der tager den i brug, og lavt engagement (alle prøvede, få blev ved). En funktion kan have få, der tager den i brug, og højt engagement (få prøvede, men dem, der prøvede, elskede den). Begge tal betyder noget. Mange, der tager den i brug, og højt engagement er en succes. Lavt engagement betyder, at funktionen ikke løser et rigtigt problem. Få, der tager den i brug, betyder, at den er svær at finde.
Skal dashboardet til produktet have kundernes feedback med eller kun tal?
Tag begge dele med. Tal fortæller, hvad kunderne gør. Feedback fortæller hvorfor. Fem hundrede brugere droppede funktionen (tal). Feedback siger "funktionen er svær at finde" eller "funktionen løser ikke mit problem" (hvorfor). Tal uden feedback er ufuldstændige. Tilføj et afsnit med feedback, der viser de tre vigtigste grunde til frafald eller til, at man dropper funktionen, ud fra supporthenvendelser og spørgeskemaer. Sådan gør du: tilføj et felt til kommentarer i funktionen. Hver uge: læs de tyve vigtigste kommentarer fra brugerne og sortér dem i temaer. Vis temaerne på dashboardet.
Hvordan sætter vi mål for oppetid og svartid?
Byg målene på betydningen for kunderne og på standarder i branchen. For kassen i en webshop: oppetid 99,9 procent, svartid under to sekunder. For en hjemmeside til markedsføring: oppetid 99 procent, svartid under tre sekunder. For interne værktøjer: oppetid 95 procent, svartid under fem sekunder. Jo mere kritisk tjenesten er, jo strengere er målet. Når du sætter et mål, så vid, hvilken investering der skal til. 99,99 procent oppetid (fire nioere) koster tre til fire gange så meget som 99 procent oppetid (to nioere). Sørg for, at målet er pengene værd.
Skal dashboardet til driften udløse advarsler eller bare vise status?
Begge dele. Dashboardet viser den aktuelle status. Advarsler udløses, når grænser overskrides. Hvis andelen af fejl kommer over en procent i fem minutter, udløses en advarsel. Advarslen går til udvikleren på vagt, som undersøger det. Dashboardet er til overvågning i almindelig arbejdstid. Advarslen er til tiden uden for arbejdstid eller til kritiske situationer. Ingen af dem alene er nok. Et dashboard uden advarsler betyder, at problemer opdages i arbejdstiden. En advarsel uden dashboard betyder, at teamet er blindt over for en langsom forværring, til advarslen udløses. Brug dem sammen.