Första steget mot datadriven tjänste- och produktutveckling
Att öka andelen beslut som fattas utifrån data är högt upp i många företags produktstrategi. Första steget verkar ofta vara att samla ihop, få koll och kvalitetssäkra data. Och läser man valfri ”bli data-driven”-guide på internet så beskrivs det ofta på det viset: 1. Samla in data 2. Förstå och 3. Agera. Superenkelt! Och det är inte fel på något sätt, men det riskerar att leda till inköp/implementation av nya analys-system, att nya kompetenser ska rekryteras och att anpassad spårning ska implementeras.
Som sagt – Jag påstår inte att det är fel väg att gå. Men i min erfarenhet så är risken stor att organisationer fastnar i det där första ”samla in data”-steget. För i många organisationer växer det till ett extremt omfattande jobb – ny kompetens, nya konsulter, nya verktyg. Många organisationer fastnar i den där fasen och lägger mycket energi och pengar för att få koll på data men upplever att de aldrig har tillräckligt med data eller tillräcklig reliabilitet för att kunna agera utifrån sina data. Också kommer vi inte till det i komplexitet så avgörande görandet.
Iterativt och småskaligt datadrivet experimenterande
När en organisation har hamnat i det läget och fått insikten om att de har fastnat i samla in data-stadiet så får de istället ett annat råd från valfri ”bli data-driven”-guide på internet: Arbeta iterativt med småskaliga experiment. Och det är ett bra råd, för det flyttar fokus datainsamling till agerande, görande och experiment. Men i min erfarenhet så riskerar det att kännas lite konstigt för teamen som labbar med att öka antalet data-drivna beslut i sin produktutveckling.
För en konsekvens av småskaligheten kan vara att det är lite svajiga data som ska ageras på, eller åtminstone så är förståelsen svajig. Det sprids lätt en känsla av att det inte går att lita på de data vi får in genom ett experiment, eller frågor och problem börjar ta omvägar runt de team som är tänkt att arbeta med dem. Förtroendet för den strategiska ambitionen att bli data-driven (och teamen som arbetar med det) har urholkats.
Men småskaligheten är bra – Testa det om du ska försöka sätta igång datadrivna rörelser inom service design och tjänsteutveckling. Men det finns faktiskt en variant på det här spåret, vi kan kalla det en tredje väg att gå.
Fokusera på att agera i verkligheten
Den tredje vägen handlar om att börja med sista fasen – Börja med att agera. För att agera är det absolut svåraste. Data-insamling och förståelse-skapande är inte enkelt, men det är inte så svårt som görande. Datainsamling må ta tid, men det kräver i regel inte förändrade arbetssätt i ett initialt skede. Att experimentera utifrån data kräver däremot förändrade arbetssätt typ alltid.
Så genom att börja i den svåra änden så kommer vi ner till kärnan direkt, utan att ha spenderat energi och pengar på datainsamling, dashboards och dataorientering. Och det kan resultera i två saker: den strategiska ambitionen att bli mer data-driven rinner ut i sanden (men då har den kostat minimalt med tid och energi). Eller så börjar det växa fram nya arbetssätt för att agera utifrån resultat som kommer ur experiment.
Händer det sistnämnda så kommer datainsamlingen bli enklare och kvickare för helt plötsligt så finns det det ett problem att samla in data runt, det finns en fråga att besvara eller en problematisk fas som behöver ökad spårbarhet. Det brukar vara särskilt värdefullt för team som arbetar mycket med product discovery.
Sense-making är centralt i datadriven utveckling av produkter och tjänster
För att vara tydlig: det jag menar är alltså att teamet faktiskt ska agera på mer eller mindre påhittade data som om de hade hög reliabilitet.
Gör så här: Låt den med mest förståelse, spelar ingen roll hur lite, lägga två timmar i de analysverktyg ni har och konstruera en resa eller en funnel, utifrån hens best guess av nuläget. Tips är att börja med de klassiska flöden (i relativt utzoomat läge) som vi alla vet är centrala. Kanske onboarding-flödet om det är en SasS-tjänst, eller checkout-flödet vid e-handel, eller landningsflödet vid erbjudanden, eller kanske signup på nyhetsbrev.
Konstruera ett flöde som överensstämmer så bra som möjligt med verkligheten utifrån er nuvarande förståelse (men alltså inte behöver representera verkligheten) och arbeta med det. Lek med tanken att det är den här typen av data ni kommer få ta del av när den data-drivna rörelsen är igång på riktigt.
Men stanna inte vid att fundera över det. Utan agera för att lösa det påhittade problemen som fejk-analyserats fram. Skriv text, skriv kod, designa prototyper och ut med det i produktion, ut till kunderna. Gör det på riktigt, hela vägen. Och oroa er inte för att något ska gå sönder eller bli sämre. För om ni tidigare har fattat en stor del av besluten utifrån bristande data-underlag så är det troligt att era flöden är långt ifrån optimala. Och en förändring som ni tror på kommer troligtvis inte vara till det sämre.
Så börja med görandet, börjar med att agera på data. För då tenderar nuläget för teamet att förändras, helt plötsligt är det lätt att besvara frågan vilka data vi behöver ha koll på närmaste månaden. Också är det just de där experimentet som följs upp. Och även om det inte ger en fullständig bild av hela verksamheten så är vi igång med en datadriven rörelse. Vi är lite bättre än vad vi var i går. Då blir det också avsevärt lättare att förstå vilka data som ni kommer få ut värde ifrån när ni väl drar igång med datainsamlandet.
För tydlighetens skull: Att skapa förståelse för den faktiska verkligheten är avgörande för en organisation. Problemet är att det inte är ett särskilt bra ställe att börja på för ett team som vill fatta fler data-drivna beslut.
