Hemnets resa till designsystem

Nådens år 2020 lider mot sitt slut. Det där uttrycket, ”i nådens år” låter lite ålderdomligt och apokalyptiskt. Tydligen skrev man så förr för att komma ihåg att varje nytt år är en oerhört fin och generös gåva från Gud. Tack för 2020. Dags att reflektera över vad som varit och hoppas på en lite bättre gåva nästa gång.

Under 2020 har Hemnets sex produktutvecklingsteam tagit stora kliv i skapa ett designsystem. Vi har idag en gemensam webbplattform med delade webbkomponenter som kan användas överallt. Vi har infört komponenter och vår nya grafiska profil på många ställen både i våra appar och på webben. Vi har kommunikationskanaler och forum där vi jobbar fram gemensam design, principer och komponenter.

Vi har gjort det här gemensamt och parallellt med annat produktarbete, utan att ha något team som ansvarar för designsystemet. Här tänkte jag berätta hur vi har gjort.

Hur allt började

När den här historian börjar (sisådär två år sedan) hade vi en webb-styleguide med lite gemensam styling och guidelines för hur vi använder bland annat typografi och färger. En bra grej men tyvärr hade den inte uppdaterats på ett tag, den användes bara av en av våra webbplatser (hemnet.se) och var webbspecifik. Designers använde den inte heller utan hade sina egna komponenter i Sketch. Både front end-utvecklare och designers ville göra detta bättre och mindre initiativ började poppa upp.

Vi började prata en del om fördelarna med gemensamma designguidelines och komponenter. Mindre dubbeljobb när byggstenarna redan finns, bättre kommunikation mellan utvecklare och designers, lättare för alla teammedlemmar att jobba självständigt och ta egna designbeslut.

Delar av Hemnets nya grafiska profil

2019 tog Hemnet fram en ny grafisk profil med hjälp av varumärkesbyrån Bold. Den innehöll bland annat nya färger, typografi och en tweakad logga. Vi ville förstås få det här att synas i våra webbar och appar men mycket återstod. Vi behövde komma fram till vad profilen innebär digitalt.

Det blev naturligt att dra igång på allvar med ett bättre designsystem och samtidigt införa den här nya grafiska profilen. Vi bestämde att designsystemet skulle bygga helt på den nya grafiska profilen. Det skulle också öka incitamenten för teamen att införa komponenter från designsystemet. Man kan använda färdiga byggstenar och får dessutom nya fräscha färger och typsnitt.

Verktyg och infrastruktur

Vår nya grafiska profil levererades i Frontify, en plattform för varumärken och grafiska profiler. Vi bestämde oss för att fortsätta använda den som ett innehållssystem för designsystemet och skapade tre delar:

• Identity: Vår grafiska profil, det grundläggande som färger och typsnitt
• Components: Gemensamma byggstenar för våra webbar och appar, plus guidelines för dem
• Text: Guidelines för hur vi uttrycker oss i text och vilka ord vi använder

Vi använder Frontify som en samlingsplats för allt Hemnet-designrelaterat. Alla på Hemnet har tillgång och det går enkelt att editera text eller ladda upp bilder.

En stor del av designsystemarbetet har handlat om att göra det möjligt att skapa delade webbkomponenter som vi kan använda på olika webbplatser. Våra viktigaste webbar är hemnet.se och Kundportalen där mäklare loggar in och bland annat kan administrera bostadsannonser.

Guidelines och webbkomponent i Frontify

Kort om hur webbkomponentbiblioteket fungerar tekniskt:

• Våra webbkomponenter utvecklas i ett eget Git repository, paketeras och importeras till våra applikationer (som Hemnet.se och Kundportal) med hjälp av npm.
• Vi använder Storybook för att testa och visa upp komponenterna.
• En komponent kan användas via React eller HTML/CSS – Storybook innehåller kodexempel för båda.
• I Frontify visas guidelines för varje komponent, och själva komponenten från Storybook (delen med grå bakgrund i bilden ovan).

Androidvarianten av primär knapp i Frontify

För våra native appar (iOS och Android) finns förstås också komponenter men de är svårare att visa upp på webben. Där har vi i nuläget bara tagit skärmdumpar för att visa hur komponenten ser ut.

Våra designers jobbar numera i Figma. Där speglar vi (manuellt) komponenterna för att kunna använda i skisser och prototyper men det är de riktiga kodade komponenterna som är sanningen.

Hur vi jobbat

Vi har jobbat med det här i lite olika former under året.

I början behövde vi göra grundläggande arbete för att sätta upp Storybook och få våra webbar att använda gemensamma komponenter. Några representanter från olika team jobbade fokuserat med det under några veckor.

Under större delen av året har det handlat om att införa komponenter (inklusive ny grafisk profil) överallt, ta fram nya komponenter och vidareutveckla designprinciper. Vi har jobbat stegvis del för del och prioriterat de komponenter som används mest och gör mest skillnad visuellt, till exempel rubriker och knappar. Vi har prioriterat att införa komponenterna där de syns och märks mest.

En del av hemnet.se med ny design

En eller ett par utvecklare per team har varit designsystem-representant och fokuserat på detta någon dag i veckan. Ibland har vi haft en fast dag där alla jobbar tillsammans, ibland har det varit upp till teamet. Men vi har hela tiden haft ett möte varannan vecka där vi sprider vad vi jobbar med på designsystem-fronten och lyfter problem. Vi har också ett annat forum varannan vecka mer dedikerat till att diskutera designdetaljer.

I övrigt sker mycket av kommunikationen kring designsystemet i Slack. I kanalen #designsystem postar vi allt från frågor kring designdetaljer till tekniska frågor kring webbkomponentbiblioteket.

Allt det här har fungerat bra, mycket tack vare några personer (både utvecklare och designers) med extra engagemang för designsystemet. Tack!

En annan framgångsfaktor tror jag har varit vår inställning, att allt alltid kan ändras och inte behöver vara perfekt från början. Det är ju faktiskt tvärtom, nu när vi har gemensamma komponenter kan en smart förbättring införas överallt med en knapptryckning. Typ.

En tredje framgångsfaktor tror jag är att utvecklare och designers jobbat tillsammans hela tiden. På Hemnet är vi rätt vana vi det med det är ingen självklarhet överallt. Att designa och bygga saker funkar absolut bäst när alla inblandade har förståelse för både teknik och design.

Tips

Avanzas resa till designsystemteam

InVisions gratis Design Systems Handbook

Shopify Polaris – ett designsystem vi inspirerats av

Material Design – ett annat designsystem vi inspirerats av

Ritualer är magiska

I Dungeons & Dragons (rollspel) är en ritual en sorts trollformel som kräver extra lång förberedelse. Du kanske behöver rita upp ett pentagram eller koka en gryta på fladdermusvingar. När du väl är klar kan du uträtta något stort och häftigt, som att återuppliva någon som dött eller prata med djur.

Photo by Oleg Magni on Pexels.com

I produktutvecklingsteam är en ritual en återkommande händelse, något som händer varje vecka eller månad. Precis som i D&D krävs lite förberedelse (göra bokningar) men resultatet blir ofta magi. Långsökt liknelse tänker du? You bet!

Ritualer på Hemnet

I Hemnets produktutvecklingsteam har vi både teamritualer och ritualer som är gemensamma för alla team.

Teamritualerna varierar lite från team till team men alla jobbar i tvåveckorssprintar, börjar sin sprint med en sprintplanering och avslutar med ett teamretrospektiv. Många har en daglig synk på morgonen varje dag och någon sorts förberedande möte inför nästa sprint (grooming) mot slutet.

Vi har också gemensamma ritualer för alla team för att promota kommunikation, samarbete och feedback. De har lite olika timing och de flesta är valfria:

• Demo (60 min en gång per sprint, obligatorisk för alla) – teamen visar upp vad de gjort och lärt sig
• Heads up (10 min en gång per sprint, obligatoriskt för en representant per team) – ett synkmöte för att lyfta beroenden mellan team
• Design system status (60 min en gång per sprint) – alla som är involverade i att jobba med det gemensamma designsystemet berättar om vad som gjorts och lyfter saker man behöver hjälp med
• Speedback friday (30 min en gång per sprint) – en möjlighet att få snabb feedback på vad som helst man jobbar med som du kan läsa mer om här
• Design feedback (60 min en gång per sprint) – feedback-tillfälle med fokus på detaljdesign
• Feedback friday (en gång per sprint) – varannan fredag bokar vi upp och träffar ett gäng användare för intervjuer och användningstester
• Experiments (60 min en gång per sprint) – vi delar och förbättrar hur vi jobbar med experiment
• Artikelklubben (30 min en gång per vecka) – alla som vill är med och diskuterar en intressant artikel/video som har med produktutveckling att göra

Jag tror det var alla! Vi har också ett gäng olika kompetensforum (front end, back end, UX, analys, arkitektur) som träffas lite olika ofta beroende på behov. Och ritualer som händer mer sällan, som kompetensutvecklingsdag och labbvecka.

Vad som gör ritualer magiska

Ritualer påminner oss om saker vi gör varje sprint så vi slipper tänka. Som att få feedback från andra team, kommunicera vad vi jobbar med eller dela kunskap. Vi skulle förstås kunna göra de här sakerna ändå men våra hjärnor är begränsade. Ritualerna gör att vi slipper tänka på allt vi måste göra i en sprint. Teammedlemmarna kan slippa tänka på när och hur man ska inhämta feedback eller visa vad man gjort. Det kommer automatiskt, även om det förstås kräver en insats varje gång.

Photo by Andrea Piacquadio on Pexels.com

Ritualer minskar mötesadministration. Det blir förstås en mindre insats att boka upp återkommande aktiviteter. Och när bokningarna redan finns där i folks kalendrar sedan länge blir det inget jobb med att hitta tider då alla är tillgängliga. När saker händer samma dag och tid varje vecka börjar man komma ihåg ritualerna efter ett tag vilket underlättar för vår stackars stenåldershjärna.

Ritualer kan pusha oss åt rätt håll. Att förändra hur man jobbar kan vara svårt och jobbigt. Flera av våra ritualer är uppsatta som en lösning på ett problem. ”Heads up” tillkom eftersom teamen inte tyckte sig ha tillräcklig koll på beroenden till andra team. ”Feedback friday” tillkom eftersom vi ville träffa våra användare oftare. Vi ska förstås hela tiden ha ett öga på problemet, finns det fortfarande? Är den här ritualen fortfarande en bra lösning, ska den tweakas eller tas bort?

Lästips

Speedback friday – om en av våra ritualer på Hemnetbloggen

Product development at Hemnet – vår CPO och CTO om hur Hemnet jobbar

Hur vi satte Team Missions

De senaste veckorna har jag jobbat med att tillsammans med Hemnets produktteam definiera nya team missions. Alltså teamets syfte på lång sikt, en kort beskrivning av varför varje team existerar.

Vi vill att teamen på Hemnet ska vara autonoma för vi tror det är effektivt och skapar engagemang. Teamen ska själva sätta sina mål (vi använder OKRs) och jobba självständigt mot målen. Men för att kunna veta hur ett team ska kunna bidra till Hemnets mål behöver de förstå sitt uppdrag. Teamen behöver också förstå andra teams uppdrag för att veta vad de inte ska jobba med, samarbeta och hantera beroenden mellan team. Att sätta team mission löser inte allt men vi tror att det kan bidra till bättre diskussioner kring vad teamen gör och hur de förhåller sig till varandra. Plus ökat engagemang kring teamets egna mål och uppdrag.

Vi har sex team, där fyra av teamen är produktteam som ansvarar för ett produktområde. Produktområdesansvaret är mestadels skuret utifrån målgrupp – bostadsköpare, bostadssäljare, mäklare, annonsörer och partners. De övriga två teamen, appteamet och plattformsteamet, jobbar inte mot någon speciell målgrupp eller produktområde.

Det finns lite olika definitioner av mission och man kan lätt hamna i metadiskussioner om vad som är vad och vad ett mission ska innehålla. Så här har jag presenterat det:

• Det ska rama in vårt teams syfte och ansvar är
• Det får gärna innehålla vad vi gör, för vem vi gör det och varför
• Det ska vara kort och koncist
• Det ska vara vårt syfte idag, inte någon långsiktig ambition (detta är snarare vision tänker jag)

Hur vi gjorde

Våra team satte sina missions i en workshop som resulterade i en idé om mission statement. De fick börja med att svara på enklare frågor som ”om du träffade en ny kollega, vad skulle du säga att ditt team gör?”. Sedan fick de två och två komma fram till ett mission statement och presentera för varandra på den digitala whiteboarden i Miro. Där kom vi sedan fram till en gemensam mission genom att hitta gemensamma nämnare i förslagen och diskutera vad som skulle vara med, ord för ord.

En person (jag) faciliterade alla workshops, vilket rekommenderas. Man lär sig en massa, blir för varje gång bättre på att sätta rätt kontext och fokusera på det som är viktigast. Jag lärde mig till exempel att vara noggrann med hur vi definierar mission. Några team hade gjort liknande övningar förut och hade olika definitioner med sig in i workshopen.

Efter workshopen fick teamet feedback från produkt/utvecklingsledning utifrån helhetsbilden. Vi vill att bitarna i teampusslet ska passa ihop, att inget viktigt faller utanför teamens ansvar och att ett teams mission inte överlappar något annat team för mycket. Några team körde sedan uppföljningsworkshops, andra fick feedback och kunde enas via Slack.

Resultatet

Så här blev en av våra team missions:

Team Agent Products makes Hemnet an obvious choice for agents by giving them the best possible conditions to make successful property transactions and reach new customers

Någon vecka senare, när vi börjat prata om teamens mål för nästa kvartal, har jag hört missions användas i diskussioner kring vilket team som ska ansvara för vilket mål. Jag hoppas våra missions kommer fortsätta hjälpa oss framöver.

Lästips

Team Objectives – Empowerment av Marty Cagan – om att stärka teamet genom målsättande

Good Product Team / Bad Product Team av Marty Cagan – om vad som utmärker starka produktteam

Jag har skrivit om OKRs i agila tvärfunktionella team

När Hemnet byggde onlinevisningar på en vecka

I lördags förmiddag höll Elin Bjurevall från Skandiamäklarna den första livestreamade visningen på Hemnet någonsin. Ett gulligt rött hus med vita knutar utanför Tystberga visades för ca 40 spekulanter. När jag kollade streamen blev jag helt varm i kroppen av stolthet. För en dryg vecka tidigare fanns ingenting. Noll.

Det är förstås en speciell situation med coronavirus och mycket av energin bygger på en vilja att hjälpa till. Minska smittspridningen på öppna visningar och förhoppningsvis bidra till att bostadsmarknaden inte dyker under krisen. Och vi har jobbat i ett högt tempo, ohållbart på sikt. Men det är ändå kul att reflektera över vad som hände egentligen. Hur kunde vi vara så snabba? Finns det något vi kan ta med oss i hur vi jobbar med produktutveckling även när det inte är krisläge?

Den öppna Slack-kanalen #hemnet-live startades 13 mars och kommunikationen exploderade snabbt. Här kan man se aktiviteten på Slack i alla kanaler:

Vi har sedan 13 mars skickat dubbelt så många meddelanden som vanligt och en del av ökningen beror på att alla jobbar hemma på grund av viruset. Men #hemnet-live står för en stor del av ökningen. Det har postats 1844 meddelanden i kanalen på nio dagar vilket är mer än vad som postats någon annan kanal på en månad.

Några saker som har kännetecknat kommunikationen i #hemnet-live:

• Snabba svar. Ingen vill fördröja någon annans arbete genom väntetider. Det gäller också code review (som sker i Github), man har fått sin kod granskad snabbare än kvickt.
• Snabba beslut. I normalfall kan det bli utdragna diskussioner om olika vägval. Här föreslog någon något, andra tyckte det var good enough och så körde man på det direkt. En viktig förutsättning var att det var tydligt kommunicerat ”uppifrån” att vi som jobbade med tjänsten hade mandat att ta beslut själva.
• Transparens. Vi har vanligtvis en kultur av att visa upp och få feedback på det vi gör. I och med Hemnet Live boostades även den. Kanalen var öppen och vi var flitiga med att visa upp halvfärdiga fulskisser, få tidig feedback på copy, testa lösningar och dela idéer. Mycket av kommunikationen var visuell. Visualiserade flöden, skärmdumpar, skisser.
• Ständiga diskussioner om målet. Vårt mål var att komma ut med livestreamade visningar till visningshelgen vecka 12 men exakt vad som skulle finnas på plats visste ingen. Vad måste vara på plats för att vi ska kunna komma ut? Vad kan läggas till senare? Vad kan göras manuellt? Vårt mål var inte att ha en perfekt lösning ute från början, utan att komma ut snabbt så vi kunde lära oss vad som fungerar.

Det där sista, att bygga en halvfärdig men så bra lösning att den kan användas fullt ut, tror jag vi kan bli ännu bättre på i normalläge. Vi pratar ofta om att jobba med MVP (Minimum Viable Product) eller RAT (Riskiest Assumption Test) – men gör vi verkligen det? Kan vi fuska mer och lära oss snabbare?

Efter den här första visningshelgen har ca 50 mäklare livetreamat sina visningar. Vi har snappat upp mängder av frågetecken och problem från både mäklare och besökare. Vi har kunnat delta själva och fått en känsla för vad spekulanterna upplever.  Vi kan nu förklara för mäklare vad de bör tänka på för att göra en bra onlinevisning. Vem hade till exempel kunnat förutse att vissa mäklares skor med hård sula skapar ett ljud som tränger igenom allt prat?

Insikterna vi fått från riktig användning gör att vi nu, vecka två, kan fokusera på att fixa rätt saker istället för att bygga potentiellt onödiga saker eller lägga tid på att spekulera kring potentiella problem. Det är verkligen guld värt och något jag hoppas vi tar med oss framåt.

Med det sagt, otroligt imponerad av alla kollegor som gjorde detta möjligt. Ni är bäst!

Skilja på problem att lösa och features att bygga

Jag är ett fan av tvärfunktionella agila team och har tidigare skrivit om OKRs som ett sätt att jobba med mål i sådana team. Vi pratar om team som inte får ”beställningar” i form av lösningar eller krav, utan har en målsättning i form av ett önskat värde som man tar ansvar för från ax till limpa. Ett team jag jobbat i på Hemnet hade till exempel ansvar för målgruppen mäklare. Det betyder att vi göra allt vi kan för att utifrån Hemnets vision driva Hemnets affär framåt genom att förstå mäklare, hitta på lösningar och bygga lösningar för mäklare.

När vi jobbar så här, istället för det klassiska featureteamet som får lösningar att bygga ”uppifrån”, kan vi:

• Utnyttja all kreativitet och hjärnkraft hos teammedlemmarna
• Ta hänsyn till både affärs- användar- och teknikperspektiv när vi utforskar och bygger
• Skapa medarbetarengagemang

Det här låter väl jättebra? Det är det. Det är också rätt svårt att lyckas med. Det kräver till exempel att:

• Ledningen har förtroende för teamen och deras förmåga att självständigt ta rätt beslut, men också att ledningen ställer krav på teamens ansvarstagande
• Teamen tar sitt ansvar och intresserar sig för vad ledningen vill, vad användarna vill, vilken kunskap som finns hos andra team och andra avdelningar. Teamet behöver alltså inte bara vara tvärfunktionellt utan också ansvarstagande, utåtblickande, innovativt och nyfiket. För många personer är det här betydligt svårare än att få lösningar att bygga.

Mycket ovan handlar om kulturen i teamen och på hela bolaget, vilket tar tid att förändra och kräver aktivt ledarskap som Marty Cagan skriver om i den här bloggposten.

På Hemnet har vi tvärfunktionella team och en kultur av att ta stort ansvar i teamen. Men teamen får också ibland agera featureteam och bygga saker som redan är definierade. Att blanda dessa två modeller funkar ibland bra men ibland leder det till att teamet:

• Får ett problem att lösa men inte tar tillräckligt ansvar för att förstå och lösa hela problemet. Det blir ett blame game där man förväntar sig att någon annan ska ta ansvar när ”någon annan” förväntade sig att teamet skulle ansvara. Vanlig kommentar: ”Hur ska det här funka egentligen? Och vad är planen på längre sikt? Det här verkar inte genomtänkt”
• Får en feature att bygga och blir sura för att någon annan redan bestämt vad som ska göras. Att vara ett team som kämpar för att ta ansvar för helheten men gång på gång får features att bygga är jobbigt. Vanlig kommentar: ”Vi får ju aldrig tänka själva, man borde lita på teamet”

Strunt är strunt och snus är snus, om ock i gyllne dosor

– Gustaf Fröding

Lösningen på det här tror jag är att uppmunta team som vill och kan ta ansvar samt vara tydligare med vilken roll teamet behöver ta i vilket läge:

1. Skilja på olika initiativ som kommer till teamet – är det här ett problem att lösa eller en feature att bygga? Och vara ärlig med det, inte försöka få en feature att bygga att se ut som ett intressant problem. Om vi är tydliga med vad som är vad kan team som vill ta mer ansvar också börja följa upp och utvärdera hur mycket tid man lägger på features att bygga.
2. Ställa krav på ”beställare” att antingen ta ansvar för (äga) lösning och uppföljning själva eller lämna det helt åt teamet. Vi vill inte hamna i ett mellanläge, det är då vi börjar skylla på ”någon annan”.
3. Ge team som vill ta ansvar möjlighet att göra det genom att få utrymme att jobba med vision och med innovation (utifrån bolagets mål).

Tips

Team Objectives – Empowerment – bloggpost av Marty Cagan

Escaping the Build Trap – talk med Melissa Perri

Outcomes vs. Outputs – talk med John Cutler

How to Break Free of the Feature Factory – talk med John Cutler

Outcome Based Roadmaps – blogginlägg av Jason Doherty

(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.

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

Introduktion till OKR på svenska – och en gratis e-bok