Sådan kan produktchefer udnytte data-superkræfter til at besejre konkurrenterne

Læs transskriptionen:

Vi prøver at transskribere vores podcasts ved hjælp af et softwareprogram. Bær over med eventuelle stavefejl, da botten ikke er korrekt 100 % af tiden.

Hannah Clark: I en perfekt verden ville enhver beslutning, vi træffer, være datadrevet. Så hvad sker der, når hjertet er villigt, men de data, vi ønsker, bare… ikke findes? Eller når processen med at indsamle dataene er så besværlig, at udbyttet simpelthen ikke står mål med indsatsen? For mange produktteams ender for mange beslutninger med kun at være baseret på ét tal – lønnen hos den person, der træffer beslutningen.

I dag talte jeg med Vijay Umapathy, produktledelsesdirektør hos Heap. Vijay fortæller, hvordan hans produktteam gradvist er blevet mere datadrevet, samt om de gennembrud, de har haft for at skabe flere indsigter på kortere tid. Han kom også ind på en virkelig genial taktik, som hans team har brugt til at forhindre splittelser mellem produkt- og ingeniørteams. Lad os komme i gang.

Vijay, mange tak, fordi du vil være med i dag.

Vijay Umapathy: Fantastisk. Tak, fordi jeg måtte være med. Det er dejligt at være her.

Hannah Clark: Ja. Lad os begynde med lidt om din baggrund. Kan du fortælle os lidt om din karriereudvikling, og hvordan du endte hos Heap?

Vijay Umapathy: Ja, selvfølgelig. Jeg begyndte med at studere ingeniørvidenskab – jeg læste datalogi på MIT – og jeg begyndte inden for produktområdet lige efter studierne. Jeg kom med i APM-programmet hos Google. En sjov ting er, at jeg var en af de tidlige personer, der lod sig overbevise af budskabet: “Som produktchef er du den lille administrerende direktør”, hvilket overhovedet ikke passer, og som nu betragtes som en virkelig forældet måde at beskrive området på – og det er helt korrekt.

Men én ting vil jeg sige: Fra begyndelsen kunne jeg virkelig godt lide idéen om at bære mange forskellige hatte. For eksempel at have en kundeorienteret rolle, en designrolle, en ingeniørrolle eller en produktrolle og på en måde skifte mellem alle de forskellige perspektiver, når det handler om at hjælpe mennesker med teknologi.

Og den del har været sand, når det gælder at være produktchef; det var ikke helt forkert beskrevet, hvordan det ville være.

Hannah Clark: Jeg ville spørge dig om noget, der står i din biografi på din Medium-konto: at du virkelig elsker at skabe værktøjer, som giver mennesker superkræfter. Jeg syntes, det var en virkelig sjov måde at formulere det på, og jeg ville gerne vide, hvordan det ser ud i forbindelse med Heap, som for dem, der ikke kender det, er et værktøj, produktfolk også kan bruge.

Vijay Umapathy: Ja. Heap er et værktøj til produktanalyse. For at give dig en idé om, hvordan jeg tror, mange produktchefer oplever analysearbejde, kan jeg fortælle lidt om, hvordan det var hos den seneste virksomhed, jeg arbejdede i. Jeg arbejdede tidligere i en robotstartup, og vi havde sådan en dataansvarlig – en slags overordnet datafyr.

Hvis jeg nogensinde havde et spørgsmål om brugeradfærd – hvor mange mennesker bruger denne funktion, hvad gør de, og hvor går de i stå? – skulle jeg oprette en opgave til denne person, og så måtte jeg vente i ugevis på, at den blev prioriteret. Og det var vel at mærke bare for at få lavet et diagram, der kunne besvare mit spørgsmål.

Det var virkelig forældet, og det fratog os i høj grad handlekraften. Derfor tror jeg, at det, der virkelig tiltrak mig ved Heap, da jeg overvejede virksomheden, var, at jeg så, at de byggede noget til produktchefer. Hvad var det særlige? Jeg synes, det virkelig smarte ved Heap er, at de automatiserer arbejdet med manuelt at skrive kode for at registrere hver eneste brugerhandling, man interesserer sig for.

Hvis jeg for eksempel har en netbutik og gerne vil vide, hvor mange der klikker på “Læg i kurv”, skal man normalt med analyseværktøjer skrive en kodelinje, der siger, at nogen klikkede på knappen “Læg i kurv”, ikke? Derefter skal man vedligeholde det over tid. Det bliver hurtigt noget rod. Med Heap indsamler vi automatisk alle disse data.

Vi automatiserer altså meget af registreringsarbejdet. Men det virkelig kraftfulde er, hvis jeg stiller et spørgsmål seks måneder senere og siger: Okay, hvor mange udførte denne handling eller brugte denne funktion? Og jeg glemte at bede nogen om at registrere det eller oprette opgaven – eller spørge den dataansvarlige, ikke?

Så behøver jeg ikke vente. Jeg kan stille spørgsmålet, har øjeblikkelig adgang til alle historiske data og kan bare besvare det – på få sekunder. For at give dig en idé om, hvad der er smart ved det, så tænk på, hvor mange møder der finder sted, hvor nogen siger: “Hvor mange gør dette?”

Og man har ikke svaret lige ved hånden med det samme. Så overtager den mest højtråbende person. Jeg var bogstaveligt talt med til et af disse møder ret tidligt i min tid hos Heap, hvor vi arbejdede på denne side. Den havde en gennemse-funktion og en søgefunktion.

Tænk for eksempel på Google Drev. En person sagde: Okay, lad os antage, at mange bare søger på denne side. Det var en mærkelig antagelse at komme med. Jeg sagde: Fint, lad os tale om fremtidens søgning og redesignet af dette. Mens personen begyndte at tale løs, gik jeg ind i Heap og oprettede en hændelse for personer, der søgte på siden.

Jeg havde øjeblikkelig adgang til alle historiske data. Derefter kunne jeg lave et diagram, der viste, hvor stor en procentdel af brugerne der gjorde dette. Jeg tænkte faktisk: Det er kun 27 %. Og så sagde jeg: Undskyld mig? Det ser ud til, at mindretallet søger her. Kan vi tale lidt mere om gennemse-funktionen? Det ændrede mødets retning.

Det er det, jeg mener med superkræfter. Jeg tror, at vi om ti år vil se tilbage og tænke, at det er absurd, at man i sådan en situation ikke kunne besvare spørgsmålet med det samme.

Hannah Clark: Du har personligt en stor passion for at bruge dataanalyse i beslutningstagningen. Hvordan tror du, at nogle af dine passioner har påvirket udviklingen af produktet og nogle af de indsigter, du kan opnå?

Vijay Umapathy: Jeg ved ikke, om det nødvendigvis har påvirket produktet. Jeg tror, at vi ofte læner os op ad vores kunder, når det gælder det, men jeg vil sige, at det nok har påvirket, hvordan vi taler om bedste praksis.

Noget af det virkelig spændende er muligheden for at stille alle disse ad hoc-spørgsmål, ét efter ét. Det, jeg har erfaret, er, at når man giver folk mulighed for at stille spørgsmålene og få svar meget hurtigt, bliver problemet faktisk ens processer.

Mange er organiseret sådan, at man siger: Okay, når du lancerer en funktion, sætter du dig ned og definerer de fem målepunkter, du vil måle. Derefter sætter du dig ned igen, ser på dette kontrolpanel, deler det med ledelsen på et møde og går videre med livet.

Hos Heap har vi i stedet forsøgt at arbejde på en anden måde – vi har faktisk lavet skabeloner til det. Man bør være meget hypotesedrevet. Når man begynder med at sige: Jeg vil løse et problem med dette produkt eller denne funktion, har vi en skabelon til noget, der hedder en problembeskrivelse, hvor man grundlæggende siger: Jeg vil ikke foreskrive en løsning.

Jeg vil beskrive problemet i detaljer. Og i slutningen står det, vi mener er den vigtigste del: en målbar hypotese. Det vil sige: Jeg tror, at denne gruppe brugere vil ændre deres adfærd på denne målbare måde. Og måske også: Jeg tror, at ændringen vil være så stor.

Hvad er et godt resultat? Derefter har vi en fast praksis, som vi har udviklet efter lanceringer af funktioner, og som vi selv har brugt mange gange. Vi skrev skabeloner, blogindlæg og alt muligt om den. Den kaldes rapporter efter gennemført handling. Grundlæggende begynder man med: Hvad var min hypotese, før vi byggede dette, og havde jeg ret?

Flyttede tingene sig, som vi troede, de ville? Og hvad overraskede os ellers? Det sidste spørgsmål kan føre én ned ad et kaninhul. Jeg tror, at det er den del, hvor Heap har opmuntret vores team såvel som vores kunder til at gå ned ad dette kaninhul med yderligere spørgsmål.

Hvilke brugersegmenter havde meget anderledes adfærd? Hvilke forskellige veje fulgte folk gennem den funktion eller arbejdsgang, vi tilføjede til produktet, men som vi ikke forventede, at de ville følge?

Hannah Clark: Kan du give os et eksempel på et kaninhul, du for nylig gik ned ad, som kan give os en god referenceramme for, hvordan den kraft kan se ud?

Vijay Umapathy: Ja, selvfølgelig. Et virkelig godt eksempel er, da vi for omkring seks måneder siden lancerede en funktion til gengivelse af brugersessioner i Heap. Vi opkøbte en virksomhed, der arbejder med gengivelse af sessioner, hvilket betyder, at man kan se en visuel rekonstruktion af, hvad én bruger foretager sig, klik for klik.

Da vi lancerede funktionen, overvejede vi oprindeligt at tilbyde den som en integration. Derfor byggede vi en række indgange til den inde i vores analysefunktioner. Vi kunne se, at mange brugte dem og prøvede funktionen. Men vi fandt også en vis friktion, når nye konti skulle sættes op, fordi brugerne forventede arbejdsgange, der først var lidt mere kvalitative.

Vi kunne se mønstre, hvor de navigerede til andre dele af vores websted for at finde disse oplysninger. Derfor arbejder vi blandt andet på nogle ændringer, som gør det meget lettere for dem at navigere i den slags arbejdsgange.

Jeg tror faktisk, at det er et meget almindeligt mønster inden for produktudvikling: Man lancerer noget med en række antagelser, noget går godt, og noget overrasker én – og det er helt fint.

Derefter fortsætter man med at iterere, indtil man til sidst når frem til et sted, hvor adfærden normaliserer sig omkring noget, der ligner de veje, man har banet. Men i begyndelsen er det aldrig sådan.

Hannah Clark: Okay. Lad os skifte emne lidt. Noget, jeg har tænkt meget over, er gennembrud – de øjeblikke, hvor man får en aha-oplevelse, som på en måde bliver en del af baggrunden for ens processer. Kan du fortælle om et gennembrud, du har haft i forbindelse med at bruge brugerindsigter og skabe noget virkelig interessant med dem?

Vijay Umapathy: Ja. Jeg tror faktisk, at det største gennembrud, vi har opnået med vores produkt, og som også har medført mange ændringer i den måde, vi arbejder på som produktteams, og i den måde vores kunder arbejder på, udspringer af den funktion til gengivelse af sessioner, som vi føjede til produktet.

For at give lidt kontekst: Det, der normalt sker – og vi er selv et eksempel på det – er, at man har sine kvantitative data i ét værktøj. Man har altså én silo med alle sine adfærdsdata, laver diagrammer ud fra dem, tragtanalyser og så videre. Separat har man en anden silo med kvalitative data.

Der kan også være to forskellige teams, der ser på de to forskellige datasiloer. Måske ser designteamet jævnligt nogle gengivelser af sessioner. Men det, der ender med at ske, er, at data hober sig op. Man har millioner og atter millioner af timers sessionsgengivelser – flere, end man overhovedet kan nå at se.

Et af de store problemer er, at man ikke ved, hvilke sessioner man faktisk bør se. Og man ved heller ikke, hvis man åbner en af sessionerne, der varer en time, hvilke øjeblikke der er vigtige.

Man ved heller ikke, hvilke øjeblikke der er vigtige på en måde, der faktisk påvirker virksomheden samlet set – ikke kun hos én bruger, men på tværs af flere brugere.

Vi havde faktisk et møde, hvor vi satte os ned hver fredag og så nogle forskellige sessionsgengivelser. Det var en normal proces. Jeg kender masser af produktteams, der gør det i dag.

Målet var at opbygge en fast praksis, så man kunne udvise empati med kunden, og samtidig målrette diskussionen mod en bestemt arbejdsgang, vi interesserede os for eller arbejdede på, for at finde frem til nogle idéer. Hvad kunne vi ændre, som måske ville have en effekt?

Det var det, vi forsøgte at gøre. Men her var problemet: Der var én stakkels person, som skulle forberede mødet. Mødet varede 30 minutter og havde 20-30 deltagere, så det var et dyrt møde. Én person skulle bruge omkring tre timer før mødet på at se timevis af disse sessioner, hvoraf de fleste var ubrugelige.

Derefter skulle personen udvælge tre, som gruppen skulle se sammen. Et forfærdeligt og møjsommeligt arbejde. Og når der er travlt, er det meget let, at personen ikke har tid til det. Det er ikke det, personen får løn for. Så falder hele ritualet fra hinanden, og brugen af de kvalitative data går i stå.

Dataene bliver liggende ubrugt. Da vi opkøbte virksomheden Oric, der arbejdede med sessionsgengivelse – det gjorde vi i juni sidste år – integrerede vi dem i Heap. Vi satte ikke bare en side til sessionsgengivelse ind i produktet. Vi integrerede den dybt i selve analysen.

Når man ser på en hvilken som helst kvantitativ tendens, får man i praksis en “Vis mig”-knap. Den knap udvælger ikke blot de rigtige sessioner i den sammenhæng, man ser på; den kan for eksempel handle om, at man netop har lanceret en funktion og vil vide, om den har ændret sig fra sidste uge til denne uge, eller hvordan folk klikker sig anderledes gennem den.

Det er let at besvare. Eller måske falder mange brugere fra på trin tre i arbejdsgangen. Hvad sker der dér? Vi integrerede funktionen dybt, gav brugerne “Vis mig”-knappen, udvalgte de rigtige sessioner og sprang direkte til det rigtige øjeblik i sessionerne.

Så hvad ændrede sig med dette møde? Vi genindførte en version af mødet, men som en brainstorm, der faktisk blev ledet af vores vækstteam.

Jeg husker stadig, at jeg gik rundt på mit kontor helt rundtosset, efter vi havde gennemført den, fordi teamet ikke havde forberedt noget. De tog eksisterende tragtanalyser for forskellige dele af vores opsætnings- og onboardingforløb. Derefter fordelte de forskellige personer mellem rum og sagde: Gå ind i dette rum, gå ind i det andet rum, se så mange af disse gengivelser som muligt, og generér så mange virtuelle post-it-sedler som muligt om områder med friktion.

Hvert team valgte altså en anden tragt eller et andet trin. Og igen: Intet forarbejde. De tre timers sortering var væk. De kom ud med hundredvis af idéer på 30 minutter.

Det var et øjeblik, der ændrede alt. Vi tænkte: Hold da op, det her kan hjælpe teams med at udvikle idéer meget hurtigere, end de nogensinde havde forestillet sig.

Hannah Clark: Det er fantastisk. Og det har virkelig stor betydning, ikke?

Vijay Umapathy: Jo, absolut. Det smarte er også, at det er datadrevet. Jeg tror, at mange glemmer, at 90 % af produktbeslutningerne i verden lige nu bare træffes ud fra folks meninger.

Har du hørt om HIPPO? Den højest lønnede persons mening. Det er en sjov forkortelse blandt produktchefer, men jeg tror, den rammer meget præcist. De fleste af disse ting afgøres bare ud fra mavefornemmelsen.

Selv hvis man ser på nogle anekdoter og laver et indlæg under et af disse møder, er det en sejr, hvis anekdoten er informeret af en kvantitativ kontekst – for eksempel en del af en arbejdsgang, der ikke fungerer godt.

Man er gradvist mere informeret, end man ellers ville have været. Det er det, jeg tror, folk skal forstå: Man kan vinde ved at tage tusind små skridt i den rigtige retning.

Når det handler om at være datadrevet, behøver det ikke være en stor tænd/sluk-knap. Man er enten ikke datadrevet eller datadrevet. Man kan langsomt bevæge sig op ad den stige.

Hannah Clark: Når vi vender tilbage til idéen om innovation: Hvordan balancerer du behovet for at innovere og iterere med at sikre, at det produkt, du leverer, altid er stabilt og pålideligt og fortsat giver kunderne en ensartet oplevelse?

Vijay Umapathy: Jeg vil gerne udfolde spørgsmålet lidt, hvis det er i orden.

Hannah Clark: Selvfølgelig.

Vijay Umapathy: For eksempel for at besvare den første del om pålidelighed og stabilitet: Hvis man overvåger grundlæggende målepunkter for pålidelighed og stabilitet, vil data normalt også fortælle ret tydeligt, hvornår man skal droppe alt andet og løse problemet. I andre tilfælde handler det måske om ydeevne.

Og hvis man overvåger disse ting, vil data normalt tydeligt vise, hvornår man skal droppe alt og løse problemet. Jeg synes, et langt mere interessant spørgsmål med mange nuancer, som skaber udfordringer for produktchefer, er: Hvordan håndterer man teknisk gæld sammen med sit ingeniørteam, samtidig med at man bygger helt nye produktfunktioner og løser problemer for kunderne?

Der findes for eksempel en almindelig kliché blandt produktchefer: En produktchef siger, at vi skal blive ved med at bygge nye funktioner for at løse alle disse problemer for kunderne. Ledelsen elsker den person, fordi alle idéerne er skinnende, og de kan se tegn på indtjening.

Samtidig sidder ingeniørteamet måske i et hjørne og siger: Vi har virkelig brug for at opgradere vores version af Node. Og de bliver mere og mere bitre, fordi deres idé hele tiden bliver nedprioriteret.

Jeg tror, at det skaber splittelser mellem produkt- og ingeniørteams, som ikke behøver at opstå. Noget, vi er begyndt at praktisere på flere teams hos Heap, er at bruge køreplanen til at prioritere vores tekniske investeringer i fundamentet.

Vi gjorde noget, der hedder at lave et agilitetsscorekort. Grundlæggende sagde vi: Lad os begynde med det driftsprincip, at computere skal arbejde for os. Det skal blive lettere og lettere for os at udføre de ting, vi har brug for at gøre oftere og oftere på vores køreplan.

Første trin er at se på sin køreplan og spørge: Hvilke slags ændringer vil jeg foretage i mit produkt oftere end andre? Hvis jeg ser på de ting, jeg vil gøre oftere, er jeg så hver gang begrænset af dem? Hver gang jeg ændrer noget som dette, opbygger jeg så teknisk gæld?

Måske tager det uger, selvom det føles, som om det burde tage minutter, og det er utrolig irriterende. Eller er jeg understøttet? Er det forholdsvis let at gøre? Det er ligetil, men kræver stadig arbejde. Eller er hele området optimeret? Er det designet til, at jeg kan gøre det tusind gange om dagen?

Man vil faktisk ikke være optimeret til alt, for så er man optimeret til ingenting. Man skal træde et skridt tilbage og spørge: Hvilken del af dette ved vi, at vi kommer til at gøre hele tiden?

Et eksempel fra Heap er, at vi indså, at vi kommer til at bygge nye typer datavisualiseringer for evigt. Vi indså også, at vi altid kommer til at bygge grænseflader, hvor folk kan stille spørgsmål til data.

Vi så på disse ting og spurgte: Hvor lang tid tager det? Hvor lang tid burde det tage? Hvilke klager hører vi fra udviklingsteamet, når de bygger den slags?

Vi kunne faktisk træde et skridt tilbage og sige: Vi sætter udviklingen af nogle funktioner på et par af disse teams på pause i et stykke tid og prioriterer at flytte vores frontend til React. Det er noget, mange virksomheder har gjort de seneste år. Store, smertefulde projekter.

Og det er vel at mærke ikke sjovt. Det tager lang tid. Det er ret brutalt. Der er masser af særtilfælde. Men det er vigtigt, hvis man fra starten – også over for ledelsen – fremstiller det som at opbygge sin egen hastighed i fremtiden.

Jeg investerer en måned nu for at tage noget, som jeg ved, jeg kommer til at gøre hundrede gange, og få det til at gå fra én uge til én time. Det kommer til at betale sig meget hurtigt.

På den måde går man fra teknisk gæld til teknisk udbytte. Når man tænker på det på den måde, bliver det en spændende, samarbejdsorienteret opgave, man løser sammen mellem produkt- og ingeniørteamet. Så skaber man ikke en splittelse mellem teams.

Hannah Clark: Vijay, hvilke tendenser ser du lige nu inden for produktledelse og dataanalyse? Og hvordan holder du dig foran disse tendenser for at sikre, at dit team altid er på forkant?

Vijay Umapathy: Jeg tror, at en af de store tendenser er at nedbryde datasiloer.

Der er et par ting, der driver dette. Den ene er idéen om ødelagte arbejdsgange. Vi talte tidligere om det i eksemplet med sessionsgengivelse. Når man kombinerer det med den kvantitative datas kontekst, kan man opnå værdi og indsigter dramatisk hurtigere, end man ellers ville kunne.

En faktor er altså, at man kan gøre arbejdsgange bedre, når de i øjeblikket foregår på tværs af flere værktøjer. Derfor ser man mere værktøjssamling. Det fascinerende er, at dette er blevet fremskyndet af hele den teknologiske afmatning – de makroøkonomiske udfordringer for mange af disse teknologivirksomheder, der antog, at de bare ville vokse uendeligt, og at kapitalen ville være gratis for evigt.

Derfor er der kommet et skift, hvor økonomidirektører og indkøbsafdelinger i virksomheder, efterhånden som budgetterne bliver strammere, presser folk til at samle værktøjerne.

Det vigtige, især for B2B-virksomheder, er, at mange produktchefer arbejder i B2B-SaaS-virksomheder. Derfor oplever man sandsynligvis et stort pres for at bygge en version af hvert værktøj inden for alle områder, der ligger op ad ens eget værktøj. Hvorfor? På grund af samlingen.

Men her er problemet: Når man gør det, er der en stor risiko for at sprede sig selv for tyndt. Man skal derfor være meget forsigtig og gennemtænkt i sin tilgang.

Man skal træde et skridt tilbage og spørge: Er der en mulighed for faktisk at skabe en bedre kundeoplevelse ved at kombinere disse værktøjer? Kombinerer jeg dem bare for kombinationens skyld? Eller er der en reel mulighed for at skabe noget bedre?

Og endnu vigtigere: Ud over at skabe noget bedre, er der så noget, jeg er særligt egnet til at gøre for at skabe noget bedre?

Når man bygger noget som dette og laver version ét af et værktøj fra et nærliggende område, der har eksisteret i årevis, vil man pr. definition være bagefter. Man kan ikke materialisere mange års arbejde fra den ene dag til den anden.

Men hvis man har en reel differentieringsfaktor og en reel arbejdsgang, som man nu har forbedret markant for slutbrugeren, har man en krog, der kan hjælpe med at levere værdi og slå konkurrenterne.

Det er derfor virkelig vigtigt, når folk tænker på tendensen med værktøjssamling og nedbrydning af siloer, at de er gennemtænkte i forhold til, hvordan de løser problemerne, og hvordan de bygger funktionerne.

Hannah Clark: Det er fascinerende. Som et sidste spørgsmål, nu hvor vi snart løber tør for tid: Hvad er der på din afspilningsliste lige nu? Hvad kan du lide at lytte til, når du arbejder eller har fri?

Vijay Umapathy: Jeg lytter til meget elektronisk musik. Jeg er stor fan af Above and Beyond, hvis du kender dem. De har eksisteret for evigt, men de har et par forskellige pladeselskaber. Det, jeg lytter mest til, og som har afspilningslister på Spotify, hedder Anjunabeats, og de har masser af nye kunstnere.

Der er mange mennesker, som lige er begyndt at slå igennem i deres karriere, og de har skabt et helt økosystem af musik, der lyder fantastisk. Så det lytter jeg som regel til. Det er det, der er på min afspilningsliste.

Hannah Clark: Nå, fedt. Det må jeg tjekke ud. Vijay, hvis folk gerne vil følge med hos dig eller følge dit arbejde, hvor kan de så finde dig online?

Vijay Umapathy: Du kan finde mig på Medium, og du kan finde mig på Twitter @vijayumapathy. Og sørg endelig for at tjekke Heap ud, hvis du bygger digitale produkter. Vi hjælper dig med at træffe beslutninger virkelig hurtigt. Forhåbentlig har jeg gennemgået nogle eksempler her, som kan hjælpe dig med at se, hvordan du kan gøre det og få større handlekraft – og ja, lad ikke HIPPO’en vinde.

Hannah Clark: Det er fair. Ja. Mange tak, fordi du ville være med. Vi sætter virkelig pris på din tid.

Vijay Umapathy: Okay, mange tak.

Hannah Clark: Tak, fordi du lyttede med. Hvis du vil have flere gode indsigter, vejledninger og anmeldelser af værktøjer, kan du abonnere på vores nyhedsbrev på theproductmanager.com/subscribe. Du kan høre flere samtaler som denne ved at abonnere på The CPO Club dér, hvor du får dine podcasts.