(Komma runt) problem med designers i tvärfunktionella team

På Hemnet organiserar vi oss i tvärfunktionella produktutvecklingsteam.

Tvärfunktionella betyder att teamen inte bara består av utvecklare utan också dedikerad Product manager och andra kompetenser som UX Designer, Digital analytiker, Konverteringsoptimerare eller User researcher. Vi har lite olika designkompetenser i olika team men gemensamt är att alla ska ha en Product manager, utvecklare och någon/några som kan driva processen för research, design och uppföljning.

Produktutvecklingsteam betyder för oss att varje team har ansvar för ett produktområde, vilket för oss oftast innebär att teamet även har helhetsansvar för en viss målgrupp. Teamet jag hör till jobbar exempel med målgruppen mäklares behov och drivkrafter för att bygga nya och förbättra befintliga mäklarprodukter.

Det finns en massa bra saker med att organisera sig på det här sättet:

• Alla kompetenser är med i hela processen. Det skapar förståelse och engagemang i teamet. Det minskar kommunikationsproblem och gör att vi kan ha både teknik-, affärs- och användarperspektiv på allt vi gör. Det suddar också ut gränserna mellan exempelvis UX designer och utvecklare – vi har mycket att lära av varandra.
• Teamet kan ta ansvar fullt ut för sin målgrupp och produkt. Vi kan jobba med visionen för vår målgrupp, optimera och prioritera det som är bäst för målgruppen. Teamet lär sig hela tiden, blir bättre och bättre på att förstå sin målgrupp och sina produkter.
• Teamet kan jobba med snabba experiment. Klassisk user research som djupintervjuer eller användningstester är bra sätt att förstå sina användare. Men de har sina begränsningar. Ett annat kraftfullt sätt är att experimentera med att släppa olika lösningar och följa upp resultaten (vilket jag skrivit om här). Om detta ska gå snabbt behöver vi hitta kreativa sätt att utforma/utveckla experiment och fejka saker när det går. Experimenterande kräver alltså ett tight samarbete mellan utvecklare och designers/analytiker.

Att organisera designers i tvärfunktionella team är bra. Men det finns också en del problem som man behöver ha koll på och jobba med. Några har synts på min arbetsplats, andra har jag tänkt på efter att läst boken Org Design for Design Orgs av Peter Merholz och Kristin Skinner (bra bok!).

Använda människor och kompetens på rätt sätt

Ett teams uppgifter varierar. I perioder har mitt team jobbat med teknisk infrastruktur som bara måste göras och jag har haft svårt att bidra. I andra perioder har det varit för mycket jobb på design/analysfronten för en person. Ibland har jag känt att jag är fel person, att en kollega från ett annat team skulle göra ett bättre jobb.

Man ska inte försöka optimera så alla har 100% att göra under 100% av tiden (flödesoptimering istället för resursoptimering, en grundpelare i Lean). Men att inte kunna bidra med sin kompetens under en längre tid är jobbigt och påverkar arbetsmoralen.

Några sätt att minska problemet

• Jobba med kompetensutveckling och kunskapsspridning – skapa möjligheter att bredda sig.
• Uppmuntra folk att göra saker som inte ingår i deras kärnkompetens.
• Ha sätt att ”låna ut” personer till andra team under perioder. Här krävs det förstås synkronisering mellan team så man både kan be om hjälp och säga till om någon komma ha alldeles för lite att göra.
• Kunna byta team. Det tar tid för ett team att hitta ett effektivt samarbete så man vill inte byta för ofta. Men om en person passar bättre i ett annat team eller vill utvecklas åt något håll ska det gå att byta utan att det är någon big deal.

Kontakt med andra designers

Precis som utvecklare gärna vill jobba med andra utvecklare vill designers träffa andra designers. För att utvecklas, må bra och för att kunna lösa kluriga problem. Som designer får man ofta en rätt stor och svår roll vilket kräver en hel del stöd. Speciellt i början när man ska hitta sin roll i teamet.

Några lösningar

• Göra tid för att hjälpa varandra. Se till att alla prioriterar att hjälpa sina kollegor, även när det finns mycket att göra i det egna teamet.
• Träffas regelbundet i olika sammanhang för att prata ihop sig och lösa problem tillsammans.
• Ha regelbunden kontakt med designers från andra team genom till exempel mentorskap eller coachning.

Sammanhållen användarupplevelse och arbetssätt

Ett annat problem som Merholz och Skinner skriver om är att teamen designar på olika sätt. Även om teamet jobbar med lösningar för sin målgrupp så överlappar målgrupper.

På Hemnet har vi exempelvis målgruppen bostadsköpare som ofta samtidigt är (eller kommer bli) bostadssäljare. Vi vill att användare ska känna igen sig i tjänsten oavsett vilken målgrupp man för tillfället hör till.

Vi vill också ha gemensamma arbetssätt när det gäller vissa saker. Så teamen slipper uppfinna hjulet på nytt när de exempelvis vill rekrytera användare till intervjuer eller visualisera sin målgrupps kundresa.

Hur löser vi det här?

• Att ha gemensamma sätt att designa saker på är grundtanken med designsystem. Vissa har ett dedikerat designsystem-team som jobbar med gemensamma komponenter, mönster och riktlinjer. Andra delar upp ansvaret mellan team.
• Att vi träffas och löser problem tillsammans minskar inte bara ensamheten. Det gör också att vi kan hitta gemensamma designprinciper, gemensamma arbetssätt och värderingar.
• Att vi tänker utanför vårt eget team och satsar på kunskapsdelning. Hur kan det här nya verktyget jag hittat gynna andra team? Finns det någon annan som kan dra nytta av det här designmönstret?

Målgruppsteam – inte featureteam

Det är rätt vanligt att organisera team kring en specifik feature eller teknik, till exempel varukorgen. Men för att kunna skapa maximalt värde behöver vi förstå hela kundresan. Från att det dyker upp ett behov hos en potentiell köpare till att köparen använt och kanske sålt vidare eller återvunnit produkten. Om vi inte jobbar med hela kundresan och stirrar oss blinda på varukorgen kommer vi göra fel prioriteringar, suboptimera och viktiga förbättringar kommer falla mellan stolar.

För att kunna optimera behöver team organisera sig kring målgrupper, exempelvis köpare. Om det blir för stort att ha ansvar för en hel målgrupp kan man organisera sina team runt en del av kundresan, till exempel före köp, under köp och efter köp.

Centralized partnership-modellen

I större organisationer med många team blir det mer komplext och svårare att jobba med helheten om designers sitter dedikerat i team med ansvar för bara en liten del av kundresan. I boken presenteras en sorts hybridmodell som kallas Centralized Partnership. Den innebär att designers organiserar sig runt målgrupper (t.ex. köpardesignteamet) även om produktutvecklingsteamen inte gör det. Vissa i köpardesignteamet jobbar mer dedikerat med någon del i kundresan (och med ett produktutvecklingsteam) medan andra jobbar mer övergripande.

Centralised partnership-modellen från Org Design for Design Orgs (Merholz/Skinner 2016)

I stora organisationer kan något i den här stilen behövas. Men jag tror att man ska hålla sig borta från separata designteam när det är möjligt. Det finns som sagt en massa fördelar med att designers, utvecklare och andra jobbar tight tillsammans. Speciellt i experimenterande organisationer. Hur man än gör kommer man skapa barriärer och kommunikationsproblem om man har ”designteam” och ”utvecklingsteam”.

Hela kapitlet om Centralised Partnership finns att läsa här om man är nyfiken.

Vill du också jobba i tvärfunktionella produktutvecklingsteam?

Tänker du som jag? När jag skriver det här söker vi på Hemnet både utvecklare, UX designer och product manager. Här finns jobbannonserna.

Annonser

Mål och OKR i agila tvärfunktionella team

Jag skrev för ett tag sedan om att jobba med mål enligt OKR och fördelarna med det. Idag har vi kompetensutvecklingsdag på Hemnet och jag läste Radical focus av Christina Wodke. Boken gav några fina insikter kring hur man bör jobba med OKR i agila tvärfunktionella team.

Vaddå agila tvärfunktionella team?

Agila tvärfunktionella team är självgående team där all kompetens som behövs för att förstå problem och leverera värde finns. När alla kompetenser finns i teamet behövs inga ”beställningar” uppifrån – bara målsättningar. Ledningen pekar ut en riktning och berättar varför vi bör röra oss i den riktningen. Teamet utforskar problem (genom till exempel user research eller konkurrentanalys) och levererar lösningar.

Det finns en massa styrkor med att inte vara ett leveransteam utan ett agilt tvärfunktionellt och värdeskapande team:

• Teamet är mest kapabla att förstå problem och designa lösningar eftersom de både vet vad som är tekniskt möjligt och hur användarnas behov ser ut (även om det är en resa för många team att inte bara kunna tekniken utan också vara bäst på användare och affär).
• Teammedlemmar blir motiverade när de inte blir tillsagda vad de ska göra utan förstår problemen och får tänka själva.
• Vi reducerar kommunikationsproblem som uppstår när lösningar ska lämnas över från en avdelning till en annan.
• Vi bygger kunskap om varandras kompetenser och utvecklas tillsammans.

Innan du sätter mål, ha en mission

Using OKRs without a mission is like using jet fuel without a jet. It’s messy, undirected and potentially destructive.

Teamet behöver veta vad deras riktning bör vara och hur den förhåller sig till andra team. Agila team är brukar vara uppdelade utifrån produktområde, värdekedja eller målgrupp. Men om teamet ska skapa värde och inte bara ”jobba på” med att förbättra produkt X så behövs något mer.

Ett mission statement är teamets långsiktiga uppdrag som svarar på varför teamet finns och vad vi vill uppnå långsiktigt. Lite som ett företags vision, fast på teamnivå. Här finns en massa inspirerande exempel på stora företags mission statements.

Hur ska vi veta åt vilket håll vi ska svänga om vi inte vet var vi är på väg? Med ett tydligt mission statement blir det betydligt lättare för team att sätta kortsiktiga mål, som kvartals-OKR. Det blir också lättare att förstå vad andra team jobbar med.

Ha mål som uttrycker vart vi ska – inte hur

We start our journey to our dreams by wanting, but we arrive by focusing, planning and learning

Det kanske allra svåraste med OKR är att sätta dem på rätt nivå. OKR ska svara på vad vi vill uppnå – inte hur. Ett objective ska vara ett ambitiöst mål och key results berättar hur vi mäter att vi rört oss närmare målet. Sedan behöver vi ju självklart också definiera hur vi ska nå målen, men det är något annat. Det gör vi till exempel i sprintplaneringar, där vi kollar på hur vi rört oss närmare våra mål sedan sist och prioriterar vad vi behöver göra de följande veckorna för att komma närmare våra mål.

Det ändå kan lätt bli att man när man sätter sina mål också börjar definiera vad man ska göra och hur. Vill man vara ett agilt tvärfunktionellt team så tror jag man gör sig själv en otjänst. Inte nog med att målen blir otydliga och mindre motiverande, man riskerar att planera vad man ska göra för långt på förhand och tappa förmågan att byta riktning när man lär sig saker.

Tanken är ju att man vid varje givet tillfälle ska göra det som bidrar mest till målen. Om man på förhand sagt att det är X blir det svårt att styra mot en annan lösning när man lärt sig att X inte alls var någon bra idé.

Dessutom blir det jobbigare och mer tidsödande att sätta sina kvartals-OKR om man samtidigt ska sätta någon sorts backlog eller roadmap för kvartalet.

Prioritera målen, eller ha ett mål

Set only one OKR. It’s about focus.

Okej, så säg att vi har satt mål (inte lösningar) och vet hur vi mäter dem. Hur vet vi vad vi ska ta tag i först? För att få ut något av OKR vill vi ju faktiskt jobba aktivt mot våra mål, att de ska styra vad vi faktiskt gör. Annars finns det ingen poäng.

Wodke rekommenderar att alltid prioritera och fokusera på ett mål i taget. Både vad gäller företagets och teamens mål. När vi har uppnått vårt viktigaste mål kan vi jobba på nästa.

Varför? Fokus. Jobbar vi mot flera olika mål samtidigt minskar effektiviteten eftersom vi måste vänta på varandra, vi behöver context switcha, vi ökar behovet av kommunikation i form av ”synk” och dessutom tappar vi teamkänslan i att jobba tillsammans mot ett gemensamt mål.

Ett team jobbar inte bara med sina OKR

OKRs are not the only thing you do; they are the one thing you must do

Att jobba självständigt mot sina mål och enligt sin mission statement är alltså en viktig grej ett agilt tvärfunktionellt team gör. Men det är inte allt. Det behöver också finnas andra delar:

• Hjälpa andra team. Det måste finnas utrymme för att hjälpa andra uppnå sina mål. Här behövs det alignment – teamen behöver synka med varandra och ha koll på varandras mål.
• Underhåll. Det måste finnas utrymme att underhålla befintliga system och tjänster. Här behövs ett kontinuerligt arbete och en vakenhet så man hela tiden betar av buggar, håller tekniken uppdaterad och inte bygger upp teknisk skuld.
• Företagsövergripande initiativ. Vissa initiativ handlar inte om att skapa värde utan bara måste göras. Till exempel att efterleva GDPR eller andra regelverk. Här krävs också alignment och synk mellan team.

Tack Mia Kolmodin på Dandy people för kategorierna ovan.

Lästips

Quit Planning Ahead and Keeping People Busy av John Cutler

Why Outcomes Over Outputs? av John Cutler

Boken Radical focus av Christina Wodke

Boken Outcomes Over Output av Josh Seiden

Boktips: The Principles of Product Development Flow

Jag har ibland svårt att ta mig tid att läsa böcker.  Speciellt långa och svåra böcker. Men den här våren har jag läst en av de jobbigaste böckerna om produktutveckling, helt tack vare Hemnets bokklubb (och tack vare Marcus Kempe som startade den).

Den här jobbiga men briljanta boken heter The Principles of Product Development Flow och är skriven av Donald Reinertsen. Jobbig eftersom den är skriven av en ingenjör på ett ingenjörsmässigt sätt, innehåller formler och referenser till tunga saker som köteori. Briljant eftersom den känns helt komplett. Att följa principerna i boken, även om man bara följer några, kommer göra ens bolag eller team effektivt. Principer som att mäta rätt saker, inte ha för mycket igång samtidigt eller prioritera på ett rationellt sätt.

Min minst lika briljanta kollega Kristofer jämförde boken med en komplett referens till allt man behöver tänka på för att laga god mat. Om man ska baka en lax perfekt ska ugnen till exempel vara på 180 grader eftersom [lång förklaring]. Men den är rätt värdelös när barnen skriker av hunger och man snabbt behöver sno ihop något hyggligt krubb.

Jag har svårt för sådana här böcker, vill gärna ha inspirerande och konkreta exempel snarare än formler. Men kanske just därför har jag lärt mig en massa av att läsa boken. Just att den saknar det konkreta gör att man själv behöver fylla i en massa luckor, exemplifiera och konkretisera gör den till en perfekt bokklubbsbok. Sen skadar det inte alls att ha fantastiska kollegor att diskutera med.

Prioritera utifrån ekonomiskt värde över tid

Jag gillar att sätta mål, mäta och följa upp vad tjänster levererar. Man försöker alltid hitta mål och metrics som man känner är bra mått på att vi levererar nytta för användare och affär. Det blir lite gissningsarbete.

Reinertsen menar att vi oftast använder fel metrics och har alldeles för dålig koll på vad vi faktiskt tjänar. Vi behöver koppla allt vi gör till ett enda mått; Life-cycle profit impact. Alltså hur mycket pengar en förbättring kommer inbringa under en produkts hela livscykel. Det här gäller allt från att ta fram nya produkter till hur vi till exempel jobbar med teknisk skuld eller hur vi sätter samman team.

Jag är tveksam till att mäta allt, och det tror jag inte Reinertsen menar heller. Men jag tror absolut vi alldeles för ofta prioriterar baserat på känsla snarare än på vad som är rationellt. Några exempel:

• Produktledare lutar ibland åt att prioritera nya produkter för högt. Snabba intäkter värderas högre än långsiktiga förbättringar även om de kan ge bättre ekonomi.
• Utvecklare lutar ibland åt att prioritera teknisk kvalitet för högt. Snygg och förvaltningsbar kod är ofta bra långsiktigt men mindre viktigt för ett experiment eller en tjänst som bara ska leva några månader.
• Designers lutar ibland åt att prioritera snygga detaljer för högt. Detaljer som transitioner och animeringar kan göra en del för helhetsupplevelsen. Men om de är dyra att implementera är värdet ibland tveksamt jämfört med annat som att förbättra texter, informationsstruktur eller tillgänglighet.

Ett steg i rätt riktning är att alltid fundera på hur saker kan mätas på ett rättvist sätt där vi kan lägga vår känsla åt sidan och fokusera på vad som ger effekt för affär och användare. På Hemnet jobbar vi med målstyrning enligt OKR vilket lett till en massa bra diskussioner kring mätning och mål.

Optimeringar är ofta u-formade

En annan grej jag tar med mig är att i valet mellan två extremer är det oftast optimalt att lägga sig någon stans mitt emellan.

Batch size, till exempel. Att minska scopet för en uppgift gör att man kan få feedback snabbare, minskar kötid (vi kan gå vidare till nästa uppgift snabbare), minskar risk, minskar overhead och minskar behovet av planering och synkning.

Att dela upp eller minska storleken på uppgiften leder ofta till minskade kostnader. Men vi kan inte göra uppgiften för liten, eftersom det också finns en ”transaktionskostnad” i att starta igång och avsluta uppgifter. Som att fördela uppgifter mellan personer eller deploya kod.

Det finns en massa andra exempel på U-formade optimeringar i boken. Hur många uppgifter ska man ha igång samtidigt om man vill maximera genomflöde? Inte en, inte oändligt många.

Hur ”belagda” bör teammedlemmar vara för att jobba så effektivt som möjligt? Jobbar alla 100% finns ingen tid att hjälpa andra med sina uppgifter eller styra om när förutsättningar ändras vilket leder till fördröjningar. Lite slack är bra. Men det är inte heller mest effektivt att alla jobbar 50%. Den optimala beläggningen ligger någonstans däremellan, runt 80%.

Man kan aldrig kan vara dogmatisk kring något. Sanningen finns alltid mitt emellan två extremer. Det tycker jag är en väldigt bra sak att ha med sig när det gäller typ allt.

Tack!

Jag skulle aldrig läst klart den här boken utan bokklubben (som minskade i storlek i takt med att folk tröttnade). Men jag rekommenderar den absolut. Dels till den som är processnörd, gillar ingenjörsmässiga beskrivningar, vill förstå varför agile/lean är bra och kunna tänka ut egna lösningar på processproblem. Dels till den som har en snäll kollega att diskutera med och få moraliskt stöd av.

Mob tuesday – testa att jobba hela teamet i en mobb

För några månader sedan startade mitt produktutvecklingsteam på Hemnet ett experiment. Flera i teamet var nyfikna på att jobba i en mobb. Alltså att jobba på samma problem samtidigt i samma rum på samma dator. Hela teamet, som består av utvecklare, product manager, ux designer och visuell designer. Fördelarna med detta är enligt mobbförespråkarna många. Gemensam förståelse för problemet vi löser, inga överlämningar eller ledtider, vi kan ta alla beslut direkt, tydligt fokus och bättre kvalité. Men hur funkar det i verkligheten?

Vi hade gjort några spontana försök med mobb tidigare men insåg att vi behövde avsätta tid för att mobben verkligen skulle hända. Vi jobbar i tvåveckorssprintar och måndag är planeringsdag. Det gör tisdag till en optimal mobbdag. Vi har sprintmålet färskt i huvudet och alla har ännu inte hunnit spridas ut och hugga tag i olika uppgifter. Måndagens planering innebär också ofta att vi har nya större problem att hugga tag i som kräver delad förståelse och där alla kompetenser i teamet behövs extra mycket.

Mobbregler

De första stapplande mobbsessionerna körde vi utan regler. Det funkade okej men alla var överens om att det blev för dåligt fokus. Flera datorer och telefoner jobbades på parallellt utan att man riktigt visste vad folk jobbade med. Uppgiften vi skulle lösa var otydligt definierad vilket gjorde att vi började lösa ett problem men efter ett tag grävde ner oss i ett hål och försökte lösa ett annat. Vi behövde regler.

Våra mobbregler revideras förstås varje gång men just nu ser de ut som följer:

• Tydligt mål med sessionen
  • Vilken uppgift ska vi lösa och när är vi klara?
• Om man är med i mobben så fokuserar man på det som händer i mobben
• Om man inte bidrar eller lär sig något är det helt okej att gå iväg och jobba ensam
  • Även okej att komma tillbaka. En person onboardar.
• Om man inte bidrar eller lär sig något är det helt okej att sitta kvar i rummet och jobba ensam
  • Meddela mobben tydligt att man inte deltar just nu
• En dator, en “driver” som lyssnar snarare än bestämmer
  • Roteras var 30:e minut
  • Alla erbjuds att vara driver men alla behöver inte vara driver
• Lyssna på alla och respektera allas åsikter
• Alltid utvärdera efteråt
  • Revidera dessa regler och göra det ännu bättre nästa gång

De regler som tillkommit sedan start är framför allt de som har med frivilligt deltagande att göra. Vi har försökt använda mobben för att lösa problem som alla kan bidra till, till exempel att detaljera ett flöde och skissa wireframes eller ta reda på vilken tredjepartslösning vi ska välja utifrån olika kriterier. Men vi vill inte att mobben bara ska bli en workshop utan att vi också ska kunna skriva kod.

Att alla i teamet inte kan koda behöver inte vara något problem egentligen, att koda är ju att lösa problem och det går att förstå problemet även om man inte kan tolka koden. Men när problemlösningen blir på en för tekniskt detaljerad nivå blir det svårt för icke-kodande mobbdeltagare att bidra eller känna engagemang. Därför tillåter vi att man slutar delta och jobbar med något annat men sitter kvar i rummet. På så sätt går det lätt att börja delta igen när mobben  börjar jobba med en uppgift där man kan bidra eller lära sig något.

Hur gick det då?

Mob tuesday har fått positiva effekter i teamet:

• Vi upplever att vi har blivit mer sammansvetsade som team och gör mer jobb tillsammans
• Vi har fått mersmak. Vi vill jobba mer i mobb och det jobbas mer i mobb eller par spontant
• Team happiness (en mätning där vi betygsätter vårt mående och gemensamma under varje sprint) har gått upp

…och säkert en massa andra saker som vi inte tänkt på. Experimentet upplevs positivt och verkar bli ett permanent inslag i våra sprintar.

Att testa och utvärdera nya arbetssätt är så himla kul tycker jag. Och enkelt. Att avsätta en dag av två veckor till något nytt kan alla team göra utan någon vidare risk. Just do it!

Lästips

100% av teamet i en mobb i 12 månader av Lea Kovac Beckman om SVT Sport-teamets mobb

Mob programming – a whole team approach av mobb-farfar Woody Zuill

Is Agile the Enemy (of Good Design)? av John Cutler om att jobba agilt med design

Jobba på Hemnet – vi söker bland annat utvecklare!

OKR – ett sätt för team och företag att jobba med mål

Det finns två saker jag tycker är lite magiska. Det första är tvärfunktionella team. Att verkligen samarbeta, dra nytta av varandras kunskap, olika perspektiv, driv och kreativitet i allt man gör. Det andra är gemensamma mål. Att alla är överens om åt vilket håll vi ska, och känner sig delaktiga och engagerade i våra mål.

Där jag jobbar just nu (Hemnet) finns det jättefina ambitioner på båda fronterna vilket är kul. Vi jobbar med OKR både på företagsnivå och teamnivå.

Vad är OKR?

Objectives and Key Results betyder ungefär mål och mätbara resultat. Det är helt enkelt ett sätt att jobba med mål och uppföljning.

Ett Objective är ett ambitiöst och inspirerande mål som man vill uppnå, som att vara banken med nöjdast kunder eller se till att alla medarbetare stortrivs på jobbet. Man bör ha 2-4 objectives, blir det fler tappar man lätt fokus.

Varje Objective har sedan ca 3 Key Results som beskriver hur målet ska nås. De ska ha en stark koppling till målet och vara mätbara. För att få lojalast kunder skulle vi till exempel kunna öka nöjdheten med våra digitala tjänster med 20% eller minska telefonköerna till max 2 minuter i snitt. För att göra att alla trivs på jobbet skulle vi kunna satsa på att  alla medarbetare ska bli coachade minst två gånger under kvartalet och att öka snittnöjdheten i medarbetarenkäten med 25%. Key results ska vara mått som visar på att vi rör oss närmare målet men kan också innehålla konkreta åtgärdsområden. Fast helst inte detaljerade lösningar.

Det kan till en början vara klurigt att sätta sina OKR. Men det finaste av allt är att man jobbar iterativt. Mitt team reviderar våra OKR varje kvartal och företaget varje år.

Mål på flera nivåer

En grundtanke med OKR är att man ska jobba med mål i hela organisationen och på flera nivåer. Övergripande OKR sätts på företagsnivå och varje team/avdelning sätter sina egna mål.

Teamets mål kan inspireras och guidas av de övergripande målen, men företagets mål kan också inspireras av teamens mål. Det här skiljer sig lite från andra mer traditionella sätt att jobba där målen bara kommer uppifrån. En hierarkisk vattenfallsprocess, alltså. Med alla problem det innebär, som beroenden, överlämningar och bristande engagemang. OKR funkar bra i agila miljöer med autonoma och självorganiserande team.

Hur det kan funka

Där jag jobbar sätts hela företagets årliga OKR av ledningsgruppen. De här målen följs upp på gemensamma frukostmöten där alla på företaget är bjudna.

Teamet sätter sina OKR varje kvartal och det brukar ske i form av en eller flera workshops. Vi börjar med att utvärdera om hur det gått att jobba med målen senaste kvartalet. Sedan går vi igenom företagets OKR och utifrån det genereras några Objectives med hjälp av faciliterade diskussioner, post-its och whiteboard. Efter det Key results för varje objective. Det är ofta svårt att veta vilken nivå man ska lägga målen på eller hur det ska mätas så varje Key result får en ägare som ansvarar för att sätta detaljerna och göra själva mätningen.

Våra OKR (inklusive siffror – hur ligger vi till just nu?) förs in i ett Google spreadsheet och inför varje sprintplanering (varannan vecka) uppdateras resultaten av den som är ansvarig. Vi går igenom resultaten och utgår från målen i planeringen.

Här är några exempel på hur våra team-OKR skulle kunna se ut:

• Objective: Kundgrupp X upplever att produkt Y är riktigt värdefull
• • Key result: Ökning av antal återkommande köp med 40%
• • Key result: Snittbetyg i enkäter minst 9/10
• Objective: Supersmidigt för användare att utföra uppgift X
• • Key result: Task completion rate ökar med 100%
• • Key result: Inga supportärenden på området
• Objective: Ett produktivt och glatt team
• • Key result: Upplevd produktivitet och nöjdhet i intern enkät ökar till 4/5 i snitt
• • Key result: Ha minst ett team-event

Vad jag gillar med OKR

Jag tycker OKR är bra eftersom:

• Strukturen är enkel. Det inte finns så mycket formalia vilket gör lättare för alla att engageras. Det viktigaste av allt är ju att det finns mål och att man jobbar med dem, inte hur de är formulerade.
• Insatsen för att komma igång är liten. Det räcker med en workshop för att ta fram målen och det behöver inte bli en stor insats att jobba in mål i sin vanliga process.
• Målen ska uppdateras löpande vilket gör att man övar sig och blir bättre och bättre på att jobba med mål.
• Företaget har mål på samma format, det gör det lättare att förstå och jobba mot företagets mål.
• Andra team har också mål på samma format, det underlättar kommunikationen mellan team och man kan inspireras av hur andra team jobbar med sina OKR.

Saker som varit kluriga

Allt blir självklart inte perfekt från början och OKR ska som sagt jobbas med iterativt. Några saker jag tycker varit svåra:

• Ofta vill man mäta saker som inte går att mäta idag. Det är lätt att tänka att ”det löser vi sen”. Men att skapa nya mätningar kan ta tid så tänk till en extra gång, finns det någon mätpunkt som är nästan lika bra men redan finns?
• Det är lite trist att uppdatera siffrorna (vilket vi gjort varannan vecka) och ofta krävs det lite manuellt jobb. Det är bra om alla i teamet kan vara delaktiga, det ökar nog också engagemanget.
• När vi kollat hur det går har vi bara tittat på hur vi ligger till just nu. Det är nog bättre att spara siffrorna från varje uppdatering och visualisera i en graf. Då blir det lättare att få en känsla för hur det går.

Användaren då?

Jag har tidigare skrivit en hel del om effektstyrning och effektkartor som ett sätt att jobba med mål. Effektkartan är bra för att den sätter fokus på att designa för användarens behov och koppla behoven till mätbara mål. OKR fyller andra funktioner, de fokuserar på hur man jobbar med mål på olika nivåer i hela företaget. Inte på hur målen formuleras eller kopplas till användarbehov, design eller features.

Men mål och mätbara resultat är inte det enda teamet eller företaget behöver ha en gemensam bild av. Det behövs också gemensam förståelse för användarens behov och utmaningar. Till exempel genom att man delar med sig av kundinsikter och jobbar med andra kommunikationsmodeller. Som personas, kundresor, user story maps eller effektkartor.

Att man börjar jobba mer med mål och uppföljning betyder inte att man gör rätt saker för rätt målgrupp. Men det underlättar för kommunikationen och engagemanget i teamet och företaget. Det är inte illa det!

Mer om OKR och mål

Googles guide till OKR – bra och konkret guide

Jag har tidigare skrivit om effektmål för team

 

Visualisera mål och behov

Det bästa och roligaste är när hela teamet tillsammans jobbar med att tänka ut hur en lösning ska funka och se ut. Design och research är allas sak, inte bara UX designerns eller produktägarens. Samma sak med teknik. Även om alla inte kan koda så ska alla förstå tillräckligt för att kunna komma med input på hur det ska funka tekniskt. Design och teknik hänger ju ihop. Vilken lösning vi väljer är alltid en avvägning mellan vad som är bra för användare/affär och vad som går snabbt att utveckla.

För att få det här att funka måste både designers, affärsfolk och utvecklare kommunicera flitigt. Vi är experter på olika saker men måste bjuda in andra, hjälpa dem att förstå våra perspektiv såpass väl att de kan bidra utifrån sitt eget. Det viktigaste för att få till den här kommunikationen är att man jobbar tätt tillsammans. Men jag tror också olika visualiseringar hjälper.

Synliggöra det osynliga

Photo by Jaymantri on Pexels.com

Mycket av det vi jobbar med är osynligt och abstrakt. Effektmål och användarbehov finns i våra huvuden eller dokumenterade någonstans. Men om vi ska kunna samarbeta kring sånt här måste de synliggöras, och då inte i något bortglömt textdokument i någon mapp. Det ska upp på väggen!

Vad som är bra att visualisera

Visualisering låter kanske avancerat. Det behöver det absolut inte vara. Jag menar egentligen bara att få upp saker man jobbar med på en vägg. Exempel på saker som kan vara bra att visualisera:

• Effektmål – vad vill teamet uppnå och hur mäter vi att vi lyckats? hur långt har vi kommit?
• Användargrupper/beteenden/personas – vilka olika människor bygger vi för? finns det olika grupper som beter sig på olika sätt?
• Kundresor/användarflöden/scenarios – vad gör användarna steg för steg?
• Experiment – vilka hypoteser håller vi på att testa?

Alla sakerna ovan är sådant alla i teamet behöver samarbeta kring oavsett kompetens. Det finns ”färdiga” modeller som effektkartor och user story maps som är superbra att inspireras av men det viktiga är inte hur du visualiserar utan att du gör det.

Om du är osäker på hur du ska visualisera så börja med något enkelt. Som en text som beskriver teamets mål. Eller fulritade gubbar med namn på prioriterade målgrupper.

Se till att visualiseringen används

Det svåra eller det du ska lägga mest energi på är inte att hitta ett bra sätt att visualisera. Det svåra, som du ska lägga energi på, är att se till att visualiseringen används.

Det här har jag lärt mig:

• Skapa visualiseringen tillsammans med teamet. Jeff Pattons bok User Story Mapping innehåller bra exempel på det här (och är i övrigt awesome bok om tvärfunktionellt samarbete).
• Sänk ambitionsnivån. För mycket detaljer gör att visualiseringen lätt blir inaktuell och glöms bort.
• Var inte rädd för att slänga bort saker. Den bästa visualiseringen är den som speglar vad vi jobbar med just nu. Det kan vara frestande att ha kvar saker som kanske eventuellt ska jobbas på i framtiden. Men sådant gör lätt att den känns irrelevant. Bra idéer kommer alltid dyka upp i huvudet på nytt om de är bra nog.
• Var inte rädd för att slänga allt och börja om. När en visualisering är irrelevant och inte längre levande är det dags att reflektera över varför den blev irrelevant, slänga bort allt och börja om från början.

 

Experiment i produktutveckling – så funkar det

Det finns olika sätt att lära sig om hur en tjänst bör funka för att den ska passa människorna som påverkas av den. Djupintervjuer och användningstester är två favoritmetoder bland många designers. Intervjuer kan svara på hur människors behov ser ut och användningstester kan visa hur en tjänst fungerar att använda och svara på vilka delar som funkar dåligt och varför.

Men vad folk säger och hur de beter sig i ett användningstest är inte samma sak som vad folk gör när de sitter hemma framför skärmen med miljontals tjänster som pockar på deras uppmärksamhet. För att förstå hur folk verkligen använder en tjänst eller en förbättring behöver vi realisera en enkel version av den (kanske olika versioner), släppa till en testgrupp och observera data. Jag gillar att kalla det för experiment. Jag skulle kunna skriva om A/B-tester, MVP, Lean UX eller Lean experiments men de här buzzwordsen kommer med ett bagage. Och buzzwords har en förmåga att exkludera och få saker att låta svårare än vad de är.

Så: experiment. Oavsett vad man väljer att kalla det så är det awesome. Och inte speciellt svårt.

Experiment som ett verktyg av många

På sistone har jag läst boken Designing with Data. Tyvärr en lite för pratig bok som skulle kunna vara betydligt tunnare men den har en hel del fina poänger. En är att experiment ska användas som ett komplement till andra metoder och som en del av design thinking. Alltså, en process där man utifrån insamlad kunskap tar fram flera olika idéer, plockar ut de bästa, utvärderar och itererar.

Experiment kan svara på hur en idé presterar i verkligheten, vilket gör dem till ett grymt bra verktyg för designers och produktteam. Äntligen kan vi få reda på hur våra idéer presterar i verkligheten!

Men bara för att vi kan testa idéer i verkligheten ska vi förstås inte testa vilket skräp som helst. Här är saker andra verktyg som kvalitativ research, designmönster, kognition och kreativ idégenerering viktigt. När vi har en eller flera starka hypoteser om vad som kommer göra skillnad för människor och affär är det bra på förhand formulera varför vi tror på idéerna och vad som är ett lyckat test. Alltså, vilken skillnad kommer idén göra om den är lyckad? Här är ett (fiktivt) exempel på en hypotes:

Eftersom folk har svårt att hitta till sin tandläkare (vilket vi lärt oss från intervjuer med patienter som kommit för sent till sin tid) förutser vi att om vi skickar med en länk till Google Maps i påminnelse-SMS:et kommer fler hitta rätt, vilket minskar antalet försenade patienter

Hur hypotesen formuleras (eller inte formuleras) är inte så viktigt. Det viktiga är att vi vet varför vi tror på hypotesen, vilken effekt den kommer leda till och vilken observerbar mätpunkt vi tittar på för att se om vi lyckats.

Hypotesen ovan skulle vara omöjlig att testa i ett användningstest. Visst, vi kan lära oss om huruvida folk fattar vad länken är, eller om den är ser klickbar ut, eller om folk har svårt att navigera i Google Maps. Men vi kan aldrig veta om patienten skulle komma i tid.

En annan styrka med experiment är att vi kan jämföra vilken skillnad flera olika lösningar gör. Vad händer om vi skickar påminnelse-SMS:et tidigare? Eller senare? Eller skriver på ett annat sätt?

Vad som krävs för att experimentera

För att kunna experimentera tror jag man behöver jobba tvärfunktionellt och ha ett lärande mindset.

Med tvärfunktionellt menar jag att teknikfolk, affärsfolk och designfolk behöver jobba tätt tillsammans. Ett storskaligt experiment kräver ofta programmering. Men inte alltid. Det går ibland att fejka lösningen genom att till exempel skicka ut påminnelse-SMS manuellt eller via något verktyg. Det finns också verktyg för att testa enklare förändringar på webben, till exempel Google Optimize.

Jämfört med traditionell produktutveckling där en lösning/förbättring väljs ut, kodas och lanseras vill vi snabbt ta fram lösningen (ofta flera olika varianter), lansera till en delmängd av användarna och utvärdera innan vi bestämmer oss. För att experimenten ska gå snabbt att ta fram behöver utvecklarna kunna ta genvägar, använda snabba tredjepartslösningar och ”fulkoda”. Då behövs engagemang kring och kunskap om både tekniska förutsättningar och lösningar/hypoteser hos alla i teamet.

Med lärande mindset menar jag att alla i teamet (plus intressenter utanför teamet) måste vara inställda på att allt som produceras, även kod, produceras för att lära sig mer om vad som funkar. Inget är ”klart” bara för att det finns ute på sajten eller i appen. Det är klart när vi vet att det gör saker bättre för människor och för vår affär. Idéer kan (och ska) kastas bort om de inte funkar.

Dra säkra slutsatser

Vi behöver förstås också ha användare att experimentera på, och tillräckligt många för att kunna dra säkra slutsatser. Det är lättare att experimentera om en sajt har en miljon besökare per dag jämfört med hundra. Om vi till exempel testar det nya påminnelse-SMS:et på bara 100 människor och antal förseningar minskar från 20 till 16 (-20%) jämfört med en kontrollgrupp kan skillnaden med hög sannolikhet bero på slumpen.

Statistisk signifikans är ett mått på sannolikheten att ett resultat inte beror på slumpen. Det är bra att på förhand vara säker på att man kommer kunna få statistiskt säkerställda resultat inom rimlig tid, så man inte göra en massa jobb med att ta fram ett experiment i onödan.

Hur statistiskt signifikant ett resultat är beror på två saker. Dels hur många som ser experimentet, dels hur stor skillnad som uppmäts. Det är lättare att få signifikans på en 40%-ig förbättring än på en 20%-ig. Man kan ofta i förväg ta reda på vilken den minsta observerbara skillnaden är (Minimum Detectable Effect, MDE) baserat på hur många man gissar kommer se experimentet. Här finns ett enkelt verktyg för att beräkna statistisk signifikans för skillnad i konvertering (funkar även för andra mått).

Mäta rätt saker på rätt sätt

Men något som är antagligen ännu viktigare än signifikans är vilken data man väljer att mäta och hur man tolkar resultaten.

• Välja rätt mål: Vad vill vi uppnå egentligen och hur kan vi mäta det? Att färre patienter kommer för sent? Gladare patienter? Gladare tandläkare? Här behövs kunskap om vad vi (affär/verksamhet) vill uppnå.
• Välja rätt hypoteser att testa: Finns det ens någon potential att minska antalet försenade patienter? De som kommer för sent kanske kommer fortsätta göra det oavsett lösning? Vi kanske skulle kunna anpassa tiderna istället, göra dem mer flexibla? Här behövs kunskap om målgruppen.
• Kvalitet på data: Har vi tillförlitlig data som vi kan använda? Det kan finnas tandläkarmottagningar som är dåliga på att registrera antal försenade patienter. Har vi data att jämföra med? Hur länge har man registrerat förseningar?
• Kan det finnas andra orsaker än påminnelse-SMS:et till att antal försenade patienter minskar? Säsongsvariationer kan spela in, det kan till exempel vara lättare att komma i tid på sommaren när trafiken rullar på bättre. Många typer av variationer kan lösas genom att ha en kontrollgrupp, där till exempel hälften får det ursprungliga SMS:et.

Sådana här utmaningar, och fler, skrev Daniel Hansson konkret om här.

En siffra är inte (den enda) sanningen

Measurement design is subjective. Someone decides what to measure, how to measure it and how to build the model. So all data is subject to human bias.

– Arianna McClain

Precis som i alla delar av designprocessen finns det bias i hypoteser, data och mätningar. Det betyder förstås inte att vi ska sluta experimentera, precis som vi inte ska sluta göra användningstester eller behovsanalyser. Men jag tror det är extra viktigt att vara medveten om när det gäller data. Folk (speciellt datahungriga chefer) har en tendens att se siffror som sanningen.

En siffra, hur signifikant den än är, representerar bara ett perspektiv och bakom den finns en grupp människor som valt ut och tolkat. Med sina fel och brister. Erika Hall pratade bra om detta på Webbdagarna.

Globala och lokala optimeringar

Experiment kan användas både för stora, konceptuella, idéer och för små, nästan omärkbara förändringar. Jag har undvikit begreppet A/B-tester eftersom jag (och kanske många andra?) associerar till små optimeringar. Som att ändra färg på en knapp eller ändra copy. Jag tror det finns en rejäl risk i att uteslutande jobba med den typen av mindre optimeringar (vilket min fördom är att området konverteringsoptimering handlar om).

Det viktigaste för användaren är förstås inte om knappen är röd eller blå, eller om det är två eller tre steg i köpflödet. Det viktigaste är om tjänsten uppfyller mina behov, gör mig glad/nöjd/inspirerad. Samtidigt som den uppfyller affärsmål, förstås. Det här är viktigt att tänka på i all produktutveckling men kanske extra mycket när man jobbar med experiment och kvantitativ data. Vi får aldrig glömma användarens (långsiktiga) mål eller de mjukare, känslomässiga aspekterna som är svårare att mäta. Per Axbom har pratat mycket om detta, här finns hans fina prat Problemet med sagolika användarupplevelser.

Tips

Det finns jättemycket mer att skriva om det här. Men den här bloggposten är redan för lång och andra har redan gjort bra jobb med att beskriva saker (med buzzwords!):

• Boken Designing with Data innehåller en massa bra tips för att experimentera på ett proffsigt sätt
• Sajten Experimentation Hub innehåller guider, tips och verktyg för att jobba med hypoteser och experimenterande.
• Melissa Perris bloggpost Finding the Truth Behind MVPs om (miss)uppfattningar om vad en MVP är.
• Validate or Die – bloggpost av Kunal Punjabi om att validera saker i flera led. Marknad, problem och lösning.
• The MVP is dead. Long live the RAT. – Rik Higham om att validera sina mest riskabla antaganden.