Hur produktchefer kan använda datasuperkrafter för att besegra konkurrenterna

Läs utskriften:

Vi provar att skriva ut våra poddar med hjälp av ett program. Ursäkta eventuella stavfel eftersom roboten inte är korrekt till 100 procent hela tiden.

Hannah Clark: I en perfekt värld skulle varje beslut vi fattar vara datadrivet. Så vad händer när hjärtat är villigt, men den data vi vill ha helt enkelt… inte finns? Eller när processen för att få fram datan är så besvärlig att det inte är värt besväret? För många produktteam bygger alltför många beslut i slutändan på bara ett enda tal – lönen för personen som fattar beslutet.

I dag pratade jag med Vijay Umapathy, chef för produktledning på Heap. Vijay berättar hur hans produktteam stegvis har blivit mer datadrivet, samt om de genombrott de har gjort för att generera fler insikter på kortare tid. Han tog också upp en verkligt briljant taktik som hans team har använt för att förebygga konflikter mellan produkt- och ingenjörsteamen. Nu kör vi.

Vijay, tack så mycket för att du är med oss i dag.

Vijay Umapathy: Toppen. Tack för att jag fick komma. Det är roligt att vara här.

Hannah Clark: Ja. Vi börjar med lite om din bakgrund. Kan du berätta lite om din karriär och hur du hamnade på Heap?

Vijay Umapathy: Absolut. Jag började med ingenjörsstudier, läste datavetenskap på MIT och började arbeta med produkt direkt efter utbildningen. Jag gick med i APM-programmet på Google. Det roliga är att jag var en av de tidiga personerna som trodde på budskapet: ”Som produktchef är du den lilla vd:n”, vilket naturligtvis inte stämmer och numera ses som ett väldigt ålderdomligt sätt att beskriva området.

Men en sak stämmer: från början tyckte jag verkligen om tanken på att bära många olika hattar. Att ha en kundinriktad roll, en designroll, en ingenjörsroll eller en produktroll och växla mellan alla dessa perspektiv när man hjälper människor med teknik.

Och den delen har varit sann när det gäller att vara produktchef; bilden av hur arbetet skulle vara var alltså inte helt fel.

Hannah Clark: Jag ville fråga dig om något i din biografi på Medium, där det står att du verkligen tycker om att skapa verktyg som ger människor superkrafter. Jag tyckte att det var ett väldigt roligt sätt att uttrycka det och ville veta hur det ser ut i Heap-sammanhang. För dem som inte känner till Heap är det ett verktyg som produktmänniskor också kan använda.

Vijay Umapathy: Ja. Heap är ett verktyg för produktanalys. För att ge en bild av vad jag tror att många produktchefer upplever med analys kan jag berätta hur det var på mitt förra företag. Jag arbetade på ett robotikföretag och vi hade någon slags ansvarig för instrumentpanelen, en dataexpert.

Om jag hade en fråga om användarbeteende – hur många som använde en funktion, vad de gjorde eller var de fastnade – var jag tvungen att skapa ett ärende åt den personen och vänta i flera veckor på att det skulle prioriteras. Och det handlade alltså bara om att skapa ett diagram som kunde besvara frågan.

Det var väldigt ålderdomligt och gjorde oss fullständigt maktlösa. Det som verkligen lockade mig till Heap när jag övervägde att börja där var att jag såg att de byggde saker för produktchefer. Jag tänkte: vad är det som är speciellt? Det häftiga med Heap är att de automatiserar arbetet med att manuellt skriva kod för att spåra varje användaråtgärd som man bryr sig om.

Om jag till exempel har en e-handelsbutik och vill veta hur många som klickar på ”lägg i varukorg” måste jag vanligtvis skriva en kodrad som säger att någon klickade på knappen ”lägg i varukorg”. Sedan måste jag underhålla det över tid. Det blir ett helt projekt. Med Heap samlar vi däremot automatiskt in all den datan.

Vi automatiserar alltså mycket av spårningsarbetet. Men det riktigt kraftfulla är att jag sex månader senare kan ställa frågan: hur många utförde den här åtgärden eller använde den här funktionen? Jag behöver inte komma ihåg att be någon spåra det, skapa ett ärende eller gå till instrumentpanelens gud.

Jag behöver inte vänta. Jag kan ställa frågan och får omedelbar tillgång till all historisk data. Sedan kan jag besvara frågan på några sekunder. För att ge en bild av vad som är så bra med detta: tänk på hur många möten som äger rum där någon säger: ”Hur många gör det här?”

Och om du inte omedelbart har svaret framför dig tar den mest högljudda personen över. Jag satt bokstavligen i ett sådant möte ganska tidigt under min tid på Heap. Vi arbetade med en sida som hade en bläddringsfunktion och en sökfunktion.

Tänk ungefär som Google Drive. Någon sa: ”Okej, låt oss anta att många bara söker på den här sidan.” Det var ett märkligt antagande. Jag sa: ”Okej, låt oss prata om framtidens sökning och göra om det här.” Medan personen började prata gick jag in i Heap och skapade en händelse för personer som sökte på sidan.

Jag fick omedelbar tillgång till all historisk data. Sedan skapade jag ett diagram som visade hur stor andel av personerna som gjorde detta. Jag trodde att det bara skulle vara 27 procent. Jag sa: ”Ursäkta? Det verkar som att minoriteten söker här. Kan vi prata lite mer om bläddring?” Det förändrade mötets riktning.

Det är det jag menar med superkrafter. Om tio år kommer vi att se tillbaka och tycka att det är absurt att man i stunden inte kunde besvara en sådan fråga.

Hannah Clark: Du har personligen ett stort intresse för att använda dataanalys i beslutsfattandet. Hur tror du att det intresset har påverkat produktens utveckling och de insikter ni kan få fram?

Vijay Umapathy: Jag vet inte om det nödvändigtvis har påverkat produkten. Ofta lutar vi oss mot våra kunder för det. Men det har nog påverkat hur vi pratar om bästa praxis.

En sak som är väldigt bra är möjligheten att ställa alla dessa ad hoc-frågor, en efter en. Det jag har upptäckt är att när man ger människor möjlighet att ställa frågorna och få svar snabbt blir processerna själva problemet.

Många är organiserade så här: när man lanserar en funktion sätter man sig ner och definierar de fem mätvärden man ska följa. Sedan sätter man sig efteråt och tittar på instrumentpanelen, delar den med ledningen på ett möte och går vidare med livet.

På Heap har vi i stället försökt arbeta hypotesdrivet. Vi har till och med mallar för det. När man börjar med att säga att man vill lösa ett problem med en produkt eller funktion har vi en mall som kallas problemformulering. Där beskriver man problemet i detalj utan att föreskriva en lösning.

I slutet finns det som vi anser vara den viktigaste delen: en kvantifierbar hypotes. Jag tror att den här användargruppen kommer att förändra sitt beteende på det här mätbara sättet. Kanske kan man också uppskatta hur stor förändringen kommer att bli.

Vad innebär ett bra resultat? Efter lanseringar har vi en återkommande process som vi själva har använt många gånger. Vi har skrivit mallar och blogginlägg om den. Den kallas efteranalys. Man börjar med hypotesen från tiden innan man byggde funktionen och frågar om den stämde.

Förändrades saker på det sätt vi trodde? Vad överraskade oss? Den sista frågan kan leda ner i ett kaninhål. Jag tror att Heap har uppmuntrat vårt team och våra kunder att ställa fler följdfrågor.

Vilka användarsegment uppvisade helt andra beteenden? Vilka olika vägar tog människor genom funktionen eller arbetsflödet som vi lade till i produkten, men som vi inte förväntade oss?

Hannah Clark: Kan du ge oss ett exempel på ett kaninhål du nyligen gick ner i, som kan ge oss en bra bild av vilken kraft det kan innebära?

Vijay Umapathy: Absolut. Ett bra exempel är när vi lanserade möjligheten att spela upp användarsessioner i Heap för ungefär sex månader sedan. Vi köpte ett företag som arbetade med detta. Det innebär att man kan se en visuell rekonstruktion av vad en användare gör, klick för klick.

När vi lanserade funktionen tänkte vi först göra den till en integration. Vi byggde därför flera ingångar till den i våra analysfunktioner. Vi såg att de användes och att människor provade funktionen. Men vi upptäckte friktion när nya konton konfigurerade den, eftersom de förväntade sig arbetsflöden som först var lite mer kvalitativa.

Vi kunde se mönster där de navigerade till andra delar av webbplatsen för att försöka hitta detta. Därför arbetar vi med förändringar som ska göra det mycket enklare att navigera i den typen av arbetsflöden.

Det är ett vanligt mönster inom produktutveckling: man lanserar något, har vissa antaganden, vissa saker går bra och andra överraskar en. Det är helt okej. Sedan fortsätter man att iterera tills användarnas beteende till slut stabiliseras kring de vägar man har byggt.

Hannah Clark: Okej. Vi byter ämne lite. Jag har tänkt mycket på genombrott på sistone – sådana ögonblick där man får en aha-upplevelse som sedan blir en del av bakgrundsbruset i processerna. Kan du berätta om ett genombrott ni haft när det gäller att använda användarinsikter och skapa något intressant med dem?

Vijay Umapathy: Jag tror faktiskt att det största genombrottet i vår produkt, som också förändrat hur vi arbetar som produktteam och hur våra kunder arbetar, kommer från möjligheten att spela upp användarsessioner.

Vanligtvis har man kvantitativa data i ett verktyg. Man har en silo med beteendedata, skapar diagram och trattanalyser därifrån. Separat finns en annan silo med kvalitativa data.

Det kan dessutom vara två olika team som tittar på de två silorna. Designteamet kanske regelbundet tittar på uppspelningar av sessioner. Problemet är att man samlar på sig miljontals timmar av sådana uppspelningar – fler än någon rimligen kan titta på.

Man vet inte vilka sessioner man faktiskt bör titta på. Om man öppnar en timslång session vet man dessutom inte vilka ögonblick som är viktiga eller vilka som påverkar verksamheten i stort, inte bara en enskild användare.

Vi brukade ha ett möte varje fredag där vi tittade på några olika sessioner. Det var en normal process. Jag vet att många produktteam gör detta än i dag.

Målet var att skapa en vana som gav oss empati med kunden och samtidigt rikta diskussionen mot ett arbetsflöde som vi brydde oss om eller arbetade med, för att hitta idéer och möjliga förändringar.

Problemet var att någon behövde förbereda mötet. Det var ett 30-minutersmöte med 20–30 personer, alltså ett dyrt möte. En person behövde sitta i ungefär tre timmar innan mötet och titta på timmar av sessioner, varav de flesta var oanvändbara.

Sedan skulle personen välja ut tre som gruppen skulle titta på. Ett hemskt och mödosamt arbete. När det blev mycket att göra hade personen ofta inte tid, och det ingick egentligen inte i arbetsrollen. Då föll hela rutinen samman och användningen av de kvalitativa uppgifterna stagnerade.

De blev hyllvara. När vi köpte företaget Oric, som arbetade med uppspelning av sessioner, gjorde vi det i juni förra året. När vi integrerade dem i Heap lade vi inte bara till en sida för sessionsuppspelning. Vi integrerade funktionen djupt i själva analysen.

Varje gång du tittar på en kvantitativ trend får du i princip en knapp som heter ”visa mig”. Den väljer ut rätt sessioner utifrån sammanhanget. Kanske har du precis lanserat en funktion och vill veta om beteendet förändrades mellan förra veckan och den här veckan. Hur klickade människor annorlunda? Det är enkelt att besvara.

Eller så tappar många användare bort sig i steg tre i arbetsflödet. Vad händer där? Vi integrerade funktionen, lade till knappen och hoppar direkt till rätt ögonblick i de utvalda sessionerna.

Det förändrade mötet. Vi återinförde en version av mötet, men som en idéstorm. Vårt tillväxtteam ledde den. Jag minns att jag gick runt omtumlad på kontoret efteråt, eftersom teamet inte hade förberett något.

De tog befintliga trattanalyser för olika delar av vår konfiguration och introduktion. De delade upp deltagarna i grupper, skickade dem till olika rum och bad dem titta på så många uppspelningar som möjligt och skapa så många virtuella post-it-lappar som möjligt om friktionsområden.

Varje team valde en annan tratt eller ett annat steg. Återigen krävdes inget förarbete. Personen som tidigare hade behövt sålla i tre timmar behövde inte längre göra det. Teamen kom tillbaka med hundratals idéer på 30 minuter.

Det var ett avgörande ögonblick. Vi insåg att detta kunde hjälpa team att utveckla idéer mycket snabbare än de någonsin hade kunnat föreställa sig.

Hannah Clark: Fantastiskt. Och vilken enorm påverkan det får.

Vijay Umapathy: Ja, verkligen. Det fina är att det också är datadrivet. Många glömmer att 90 procent av produktbesluten i världen i dag fattas utifrån människors åsikter.

Har du hört talas om HIPPO? Den högst betalda personens åsikt. Det är en rolig akronym bland produktchefer, men den är väldigt verklig. De flesta sådana beslut fattas på magkänsla.

Även om man tittar på några anekdoter och skapar ett inlägg i ett sådant möte är det en vinst om anekdoten bygger på ett kvantitativt sammanhang, till exempel en del av ett arbetsflöde som inte fungerar bra.

Man är då lite bättre informerad än man annars hade varit. Det är det människor måste förstå: man kan vinna genom att ta tusen små steg i rätt riktning. Att bli datadriven behöver inte vara en stor av- eller påknapp. Man kan långsamt klättra uppför den stegen.

Hannah Clark: Om vi återgår till innovation: hur balanserar du behovet av att förnya och iterera med att säkerställa att produkten alltid är stabil, pålitlig och ger en konsekvent kundupplevelse?

Vijay Umapathy: Jag vill gärna resonera lite kring frågan. När det gäller tillförlitlighet och stabilitet: om man övervakar grundläggande mätvärden för tillförlitlighet och stabilitet och har ett servicenivåavtal med kunderna om exempelvis drifttid, kommer datan vanligtvis tydligt att visa när man måste släppa allt och åtgärda problemet.

En mer intressant fråga, med många nyanser som skapar utmaningar för produktchefer, är hur man hanterar teknisk skuld tillsammans med ingenjörsteamet samtidigt som man bygger helt nya produktfunktioner och löser kundproblem.

Det finns en vanlig stereotyp där produktchefen säger att man ska fortsätta bygga nya funktioner för att lösa kundernas problem. Ledningen älskar den personen eftersom idéerna är glänsande och verkar kunna ge intäkter.

Samtidigt sitter ingenjörsteamet i ett hörn och säger att de verkligen behöver uppgradera sin version av Node. De blir allt bittrare när deras önskemål nedprioriteras. Det skapar onödiga konflikter mellan produkt- och ingenjörsteam.

På flera team på Heap har vi därför börjat använda färdplanen för att prioritera våra tekniska investeringar i grunden för produkten.

Vi skapade något som kallas ett rörlighetskort. Vi började med principen att datorer ska arbeta för oss. Det ska bli enklare och enklare att göra de saker vi behöver göra oftare enligt färdplanen.

Första steget är att titta på färdplanen och fråga vilka förändringar vi vill göra oftare respektive mer sällan. Om vi tittar på det vi vill göra ofta: är vi varje gång hindrade av teknisk skuld? Tar något veckor fast det borde ta minuter och känns det väldigt irriterande? Eller är vi aktiverade – relativt enkelt att göra, även om det fortfarande kräver arbete? Eller är allt optimerat och utformat för att göras tusentals gånger om dagen?

Man vill inte optimera allt, för då är man i praktiken optimerad för ingenting. Man måste ta ett steg tillbaka och identifiera den del som man vet att man kommer att göra hela tiden.

På Heap insåg vi till exempel att vi alltid kommer att bygga nya typer av datavisualiseringar. Vi kommer också alltid att bygga gränssnitt där människor kan ställa frågor om data.

Vi frågade hur lång tid detta tog, hur lång tid det borde ta och vilka klagomål utvecklingsteamet hade när de byggde sådana saker.

Då kunde vi ta ett steg tillbaka och säga att vi skulle pausa viss funktionsutveckling på några team under en period och prioritera att flytta vårt gränssnitt till React. Många företag har gjort detta under de senaste åren. Det är stora och smärtsamma projekt.

Det är jobbigt och tar lång tid, med många specialfall. Men det är viktigt att från början, även tillsammans med ledningen, rama in det som en investering i framtida utvecklingshastighet. Jag investerar en månad nu för att ta något som jag vet att jag kommer att göra hundra gånger och minska tiden från en vecka till en timme.

Det kommer att löna sig snabbt. Man går från teknisk skuld till tekniska utdelningar. När man tänker på det så blir det ett spännande samarbete mellan produkt- och ingenjörsteamet, och man bygger inte längre en klyfta mellan teamen.

Hannah Clark: Vijay, vilka trender ser du just nu inom området produktledning och dataanalys? Hur håller du dig före trenderna så att ditt team alltid ligger i framkant?

Vijay Umapathy: En stor trend är att bryta ner silor mellan data. Det finns ett par saker som driver detta. En är uppenbart trasiga arbetsflöden. Som i exemplet med sessionsuppspelning: när man kombinerar den med kvantitativa data kan man skapa värde och få insikter mycket snabbare.

När man kan förbättra arbetsflöden som i dag sträcker sig över flera verktyg ser man mer konsolidering av verktyg. Det som har påskyndat detta under de senaste månaderna är den ekonomiska situationen i teknikbranschen. Många teknikföretag utgick från att de skulle växa för evigt och att kapital alltid skulle vara i princip gratis.

När budgetarna stramas åt pressar ekonomichefer och inköpsteam människor att konsolidera verktyg. Detta är särskilt viktigt för B2B-företag. Många produktchefer arbetar på B2B-SaaS-företag och får säkert pressen att bygga någon version av varje verktyg inom angränsande områden.

Men problemet är att man riskerar att sprida sig för tunt. Därför måste man vara mycket försiktig och eftertänksam. Finns det en möjlighet att skapa en bättre kundupplevelse genom att kombinera verktygen? Kombinerar man dem bara för kombinationens skull? Finns det en verklig möjlighet att skapa något bättre?

Ännu viktigare: finns det något man är unikt lämpad att göra för att skapa något bättre?

När man bygger version ett av ett angränsande verktyg som har funnits i flera år kommer man definitionsmässigt att ligga efter. Man kan inte återskapa många års arbete över en natt. Men om man har en verklig differentiering och ett arbetsflöde som man har förbättrat kraftigt för slutkunden har man en krok som kan börja skapa värde och besegra konkurrenterna.

Det är viktigt att vara eftertänksam när man funderar på trenden med verktygskonsolidering och nedbrytning av silor, både när man löser problemen och bygger funktionerna.

Hannah Clark: Fascinerande. En fråga från ingenstans eftersom vi snart måste avsluta: Vad finns på din spellista just nu? Vad tycker du om att lyssna på när du arbetar eller är ledig?

Vijay Umapathy: Jag lyssnar på mycket elektronisk musik. Jag gillar Above and Beyond. De har funnits länge och har ett par olika skivbolag. Det jag lyssnar mest på och som har spellistor på Spotify heter Anjunabeats, och där finns massor av nya artister.

Många håller precis på att slå igenom i sina karriärer och de har skapat ett helt ekosystem av musik som låter fantastiskt. Det brukar jag lyssna på. Det är vad som finns på min spellista.

Hannah Clark: Kul. Det måste jag kolla upp. Vijay, om människor vill hålla kontakten med dig eller följa ditt arbete, var hittar de dig på nätet?

Vijay Umapathy: Jag finns på Medium och på Twitter @vijayumapathy. Och titta gärna på Heap om ni bygger digitala produkter. Vi hjälper er att fatta beslut snabbt. Förhoppningsvis har exemplen här visat hur man kan göra detta och få större handlingskraft. Låt inte den högst betalda personens åsikt vinna.

Hannah Clark: Det låter bra. Tack så mycket för att du var med. Vi uppskattar verkligen din tid.

Vijay Umapathy: Tack själv.

Hannah Clark: Tack för att ni lyssnade. För fler fantastiska insikter, guider och verktygsrecensioner kan ni prenumerera på vårt nyhetsbrev på theproductmanager.com/subscribe. Du kan höra fler samtal som detta genom att prenumerera på The CPO Club där du hittar dina poddar.