Samordning genom produktfärdplaner (med Brandon Blackman från Crema)

Michael Luchen

Produktfärdplaner, det centrala dokument som kan stärka samarbetet i så många produktteam eller minska deras potential genom bristande samordning. Vi känner alla till färdplaner, men tänk om de kunde användas för att främja ett genuint och äkta samarbete? Tänk om vi i stället för att se dem som statiska dokument kunde se dem som organiska, transparenta och iterativa. I dag har vi med oss en produktchef i världsklass, med erfarenhet från allt från sjukvård till utveckling av företagsprodukter, för att prata om produktfärdplaner och hur de bäst kan användas för att skapa fantastiska produkter. Fortsätt lyssna.

Det här är podcasten för produktchefer, rösterna från en gemenskap som skriver handboken för produktledning, utveckling och strategi. Vi sponsras av Crema, en byrå för digitala produkter som hjälper individer och företag att blomstra genom kreativitet, teknik och kultur. Läs mer på crema.us.

Fortsätt lyssna för praktiska och autentiska insikter som hjälper dig att lyckas inom produktledningens värld.

I dag är jag så glad att få välkomna

Brandon Blackman till podcasten. Brandons expertis inom produktledning började på ett nystartat teknikföretag inom sjukvården och utvidgades till att omfatta ansvar för utveckling av e-handelsbutiker, mobilappar och webbaserade företagsapplikationer. Han brinner för att förverkliga idéer.

Brandon brinner för att motivera högpresterande agila och tvärfunktionella produktteam. Förutom att jag själv haft förmånen att samarbeta med Brandon på Crema är han även styrelseledamot i HealthSplash, en sjukvårdsplattform med fokus på att lösa problemet med nekade medicinska ersättningsanspråk på grund av felaktiga uppgifter.

Brandon, välkommen till programmet.

Brandon Blackman

Hej. Det är fantastiskt att vara här.

Michael Luchen

Tack så mycket för att du är med oss. Produktfärdplanering – är du redo att sätta i gång?

Relaterad läsning: Så använder du kartläggning av användarberättelser för att förbättra prioriteringen av den agila backloggen

Brandon Blackman

Ja. Jag ser verkligen fram emot att prata om det.

Michael Luchen

Okej. Jag ser också verkligen fram emot det här. Det är ett av de ämnen där jag tycker att det finns många åsikter och många rätta sätt att göra saker på.

Om vi börjar med grunderna: vilken personlig bakgrund har du när det gäller färdplaner?

Brandon Blackman

Jag har förstås mycket erfarenhet av dem, eftersom de är nödvändiga i rollen som produktchef. De är en viktig del av vår process och vårt arbetsflöde för produktutveckling. Jag skulle dock säga att min bakgrund framför allt bygger på försök och misstag och på erfarenheter jag har lärt mig av. Jag minns några av de första färdplanerna jag satte ihop. De var väldigt datumfokuserade, nästan vattenfallsbaserade, och ingenting blev någonsin klart i tid enligt färdplanen. Därför blev de mest ett irritationsmoment och en källa till stress och oro för mig när någon av mina intressenter eller någon på företagsledningsnivå hörde av sig och frågade: "När kan vi förvänta oss XYZ, eller kan jag få se färdplanen?" Då tänkte jag: Oj då, nu har jag målat in mig i ett hörn, men jag måste ändå dela den med dem. Så började jag ursprungligen arbeta med färdplaner. Det fick mig att börja tänka att det måste finnas ett bättre sätt. Jag har därför läst och undersökt mycket, och även experimenterat mycket i de produktteam jag varit involverad i. Jag är verkligen nöjd med var vi befinner oss nu.

Jag tycker faktiskt mycket om färdplanen. Den har blivit ett ovärderligt verktyg för mig, mitt team och våra användare eller intressenter, både internt och externt, och det är något jag verkligen har tyckt om att lära mig att skapa.

Michael Luchen

Det är fantastiskt. Du berättade om din bakgrund och hur du började med de väldigt fasta, vattenfallsbaserade färdplanerna och stötte på begränsningar under processen.

Vilken är din personliga filosofi kring produktfärdplaner, som du utvecklade genom den erfarenheten?

Brandon Blackman

Det är en bra fråga. Den är inte vackert formulerad och kanske lite hackig, men jag skulle säga att grundprinciperna i min filosofi är: håll den på en hög nivå. Ju mer detaljerad den blir, desto fler områden med missade förväntningar kommer du sannolikt att få. Håll den alltid uppdaterad – underhåll den hela tiden – och den sista principen är att alltid släppa. Jag tillhör dem som tror på att släppa tidigt och ofta när det gäller digitala produkter.

Michael Luchen

Låt oss börja med grunderna i produktfärdplanering. Vad bör vara färdplanens yttersta mål?

 

Brandon Blackman

Det är en bra fråga. Jag skulle säga att färdplanens yttersta mål är att kommunicera produktens riktning. Den bör egentligen också kommunicera riktningen för hela företaget eller organisationen, eftersom kärnan i det färdplanen ska göra är att skapa samordning för alla som är involverade i produkten. Det kan vara extern samordning med våra användare eller intern samordning med det egna produktteamet eller företagets ledning. Hela poängen med en färdplan är att samordna många olika människor med många olika perspektiv kring vad de kan förvänta sig i framtiden. Det är en stor utmaning. Målet är därför att på ett tydligt och koncist sätt berätta för alla intressenter vart vi är på väg med produkten.

Michael Luchen

Det är nästan som en berättelse som hela tiden förändras på något sätt, eftersom

Brandon Blackman

Absolut.

Michael Luchen

Den riktar sig till flera intressenter.

Brandon Blackman

Ja, precis. Och precis som med en bra berättelse vill du inte tråka ut någon med för många detaljer. Jag tycker därför om tanken på att den är en berättelse, eftersom du vill hålla den engagerande och leverera precis tillräckligt med information för att uppnå målet, som är att skapa samordning, men inte bli så detaljerad att den faktiskt leder till att vi missar vissa krav eller tidsfrister.

Michael Luchen

Ja, definitivt. Vi har börjat närma oss frågan, men jag vill ställa den direkt: bör en färdplan vara ett statiskt dokument som bara skapas – vi har skapat färdplanen och den finns där – som vi tittar på under utvecklingen, eller bör den vara något mer organiskt och iterativt?

Brandon Blackman

Jag står definitivt på sidan som säger att den bör vara mer organisk och mer iterativ. Om den är statisk tror jag att vi sannolikt har gjort felaktiga antaganden om användarna och om hur produkten kommer att fungera i verkligheten när den har lanserats. Färdplanen kommunicerar trots allt något om framtiden. Den gör en prognos över något som du aldrig kan veta säkert förrän du är där, oavsett hur mycket du planerar eller lägger ned på den. Färdplanen bör därför betraktas som just det: en prognos, en blick in i framtiden. Det bästa sättet att alltid ha den mest träffsäkra prognosen är att titta på nuläget och justera prognosen utifrån det. Jag tycker därför att den alltid bör vara iterativ och att man aldrig ska anta att det finns en slutgiltig version av något.

Michael Luchen

Ja. Att behandla den som en slutgiltig version kan i princip motverka de slutliga resultat som den försöker uppnå.

Du använder ordet prognos, vilket jag gillar, eftersom den bygger på vår nuvarande kunskap om produkten, vår nuvarande förståelse av användare och behov, affärsmiljön och konkurrenssituationen. Men medan vi bygger förändras alla dessa variabler, vilket innebär att färdplanen också bör stödja dessa variabler och förändras och utvecklas.

Brandon Blackman

Till hundra procent. Jag håller helt med.

Michael Luchen

Om jag sätter mig ned för att skapa en produktfärdplan för min fantastiska ABC-produkt, vad bör den fokusera på?

Brandon Blackman

Det är en fantastisk fråga. Du bör verkligen fokusera på varför och vad du bygger. Frestelsen, särskilt om du inte har så mycket erfarenhet av färdplanering, är att fokusera på hur, eftersom det egentligen är den fråga som bra färdplaner väcker: hur tar vi oss dit?

Du bör undvika den frågan. Hur-frågan hör hemma i backloggen. Backloggen beskriver hur vi ska göra det, medan färdplanen fokuserar på varför och vad. Varför rör vi oss i den här riktningen? Varför fokuserar vi på de här specifika delarna? Vad fokuserar vi på? Besvara den typen av frågor med färdplanen och undvik hur-frågan.

Michael Luchen

En del av det vi tar med i många av våra färdplaner är statusar, teman och resultat. Kan du prata om dem i samband med en färdplan?

Brandon Blackman

Status innebär att om en färdplan har statusar på sig är det saker som: det här arbetar vi med nu, det här kommer vi att arbeta med härnäst och det här arbetar vi med senare. Lägg märke till att dessa statusar inte har några datum kopplade till sig. Så fort du lägger till ett datum har du låst in dig i ett krav som kanske inte hade varit nödvändigt om du hade utelämnat datumet.

Med ett statuskoncept handlar det om idén att detta är vad vi arbetar med just nu. Det kan vara i dag, i morgon eller dagen därpå, men just nu arbetar vi med detta. En nästa-status ger användarna eller intressenterna en uppfattning om vad som kommer härnäst.

Återigen utan något datum. Du kan börja i morgon eller nästa vecka. Det enda vi vet är att det här är nästa steg. Senare visar riktningen längre fram i tiden. Vi vet alltså vad vi arbetar med nu, vad som kommer härnäst och att vi vid någon tidpunkt även kommer fram till andra frågor. Teman är ett annat vanligt perspektiv på färdplaner. Ett tema kan vara kundrelationer. Då kan du börja tänka på delar, epik och användarberättelser som bidrar till temat kundrelationer. En resultatfokuserad färdplan säger exempelvis att vi ska öka kundinteraktionerna med 30 procent. Det är ett resultat som vi kan förvänta oss och som kanske kopplas till temat kundrelationer.

Det är ett bra varför och vad. Hur lämnas återigen till backloggen och experterna, alltså personerna i produktteamet, utifrån vad vi vet just nu. Det kan finnas många olika sätt att öka kundinteraktionerna med 30 procent, men allt färdplanen behöver kommunicera är att vi är på rätt väg mot resultatet att öka kundinteraktionerna med 30 procent.

Michael Luchen

Det är fantastiskt. Tack för översikten över de möjliga vägarna. Personligen har jag sett stor kraft i att använda ett så agilt förhållningssätt till färdplanering. Det fokuserar verkligen på att bryta ned det vi vet nu, samtidigt som det finns ett område på tur – nästa område att gå vidare till – för att stödja antingen teman eller resultat.

Samtidigt finns resten av backloggen och alla andra idéer vi har kvar. De kanske är värdefulla eller inte, beroende på när eller om de genomförs. Vi har fortfarande kvar dem, men de är inte något vi har förbundit oss till eller stämplat in i en permanent färdplan.

Brandon Blackman

Ju mer du förbinder dig och ju mer du stämplar fast, desto fler krav och förväntningar skapar du som måste uppfyllas.

Michael Luchen

En sak du nämnde flera gånger var att man inte ska ange datum. Jag vet att många som lyssnar tänker: Jag skulle gärna slippa datum, men mina intressenter säger absolut att vi måste lansera för en kund senast ett visst datum, eller göra något för en intressent senast ett visst datum. Hur hanterar du det?

Brandon Blackman

Om jag kunde kontrollera allt precis som jag ville skulle datum aldrig finnas i en färdplan. Men det är den ideala verkligheten. Ofta har du en vd som vill veta när något kan förväntas, marknadsavdelningen behöver veta när något blir klart för att kunna planera kampanjer och kundtjänsten vill veta när något kan förväntas. Världen fungerar tyvärr med datum, så du måste inkludera dem i någon form. Jag försöker dock alltid ge det mest övergripande datum som möjligt för att uppfylla det teamet eller intressenten behöver veta.

Oftast kan det uppnås med kvartalsvisa färdplaner. Du kan exempelvis säga att vi senast under andra kvartalet ska kunna öka kundinteraktionerna med 30 procent och att vi planerar funktioner som bidrar till det. Det ger marknadsavdelningen tillräckligt mycket information för att skapa kampanjer, och kundtjänsten kan förbereda sina kanaler inför andra kvartalet. En temabaserad eller resultatbaserad färdplan kommunicerar alltså riktningen till alla intressenter. Kvartal ger dessutom en bra tidsmarginal på tre månader.

Michael Luchen

Jag älskar ordet marginal och att använda det som ett verktyg när man skapar färdplaner. En annan användbar mental modell är det vi kallar osäkerhetskonen. Föreställ dig en triangel som ligger på sidan, där den bredaste delen är i dag. När du rör dig framåt finns det mycket utrymme, marginal och osäkerhet kring leveransen av funktioner eller uppnåendet av resultaten och temana i färdplanen. Men ju längre tiden går och ju närmare du kommer målen eller milstolparna, desto mer kunskap och säkerhet får du. I en agil miljö kan man dessutom använda exempelpoäng för att följa upp detta. Efter några sprintar börjar teamets arbetstakt stabiliseras och du förstår bättre vilka tekniska risker, användarupplevelserisker och marknadsrisker som kan påverka. Då kan du närma dig datumen med större säkerhet utan att överge det agila arbetssättet.

Brandon Blackman

Jag gillar verkligen idén med osäkerhetskonen. Den påminner mig om något jag gjorde förra veckan när jag tittade på mitt pensionssparande. Det finns en prognos som visar osäkerhetskonen, ungefär som min färdplan mot pensionen. Den säger att om vi ställer in investeringarna och de månatliga insättningarna på ett visst sätt kommer du med 90 procents säkerhet att gå i pension med ett visst belopp. Det går naturligtvis inte att förutsäga framtiden, särskilt inte 30 år framåt, men det hjälper dig att välja hur du vill fördela investeringarna. Jag tycker att färdplaner fungerar på ett liknande sätt. När en intressent frågar vad vi kan förvänta oss senast ett visst datum kan man fråga: Vill du ha svaret med 90 procents säkerhet eller svaret med 30 procents säkerhet? Då förstår de att vi med en viss säkerhet kommer att vara på en viss plats, även om vi kanske hamnar närmare den lägre säkerhetsnivån.

Michael Luchen

Det är en fantastisk liknelse. Om vi går över till datumhantering: hur hanterar du beroenden i en färdplan?

Brandon Blackman

Det är svårt att besvara med ett generellt svar. Det bästa sättet är att dokumentera och kommunicera dem. De bör finnas i färdplanen. När du skapar en tema-, resultat- eller statusbaserad färdplan ska du koppla relevanta delar till de beroenden som finns. Om du planerar för ett visst resultat under ett visst kvartal ska du skriva att detta beror på X, Y och Z. Då kommunicerar du den samordning vi talade om tidigare.

Vi gör ofta detta med frontend- och backendteam. Frontend har ofta beroenden till backend och backend har beroenden till frontend. Därför skapar vi faktiska kontrakt, till exempel ett API-kontrakt. Ur ett produktledningsperspektiv är det ett dokument som beskriver allt vi kan förvänta oss av API:t som skapas. Frontend kan bygga utifrån kontraktet även om API:t ännu inte finns. Om kontraktet är bra och tydligt blir det lätt att koppla ihop frontend- och backendberoendena.

Samma sak kan göras mellan utvecklingsteamet och marknadsavdelningen eller mellan produktteamet och kundtjänsten. Skapa kontrakt som beskriver vad den andra parten kan förvänta sig när arbetet är klart. Då kan det team som är beroende av ert arbete börja bygga sina processer och system.

Michael Luchen

Det är mycket bra. Det är inte bara affärs- eller innehållsberoenden, utan även tekniska beroenden och hur man strukturerar utvecklingsteam så att samarbetet fungerar på ett hälsosamt och utvecklingsfokuserat sätt.

Brandon Blackman

Absolut. Saker kommer att gå fel. Hela idén med beroenden är att vissa saker är beroende av att andra saker sker, och ibland fungerar det inte. Vi bör faktiskt förvänta oss att det ibland inte fungerar. Därför är det viktigt att dokumentera beroendena i färdplanen. När något måste ändras kan du kommunicera exakt varför – på grund av ett visst beroende eller för att något visade sig vara mycket större än väntat. Om det kommuniceras från början kan du eliminera 80–90 procent av problemen med att prognostisera framtiden. Det är därför det övergripande målet med en färdplan återigen är att skapa samordning med intressenterna.

Michael Luchen

Vilka andra utmaningar brukar du möta, särskilt när det gäller lanseringshantering och leverans i kombination med agila färdplaner?

Brandon Blackman

Många utmaningar handlar om personer eller team som inte arbetar med produkt. Det kan vara interna intressenter, särskilt i större organisationer, som inte känner till den agila processen. En utmaning är därför att hela tiden kommunicera och utbilda längs vägen: vad agilt innebär och varför vi måste bygga på det sättet. Jag brukar säga att vi inte bara bygger ett hus. Hus har byggts i århundraden och vi vet hur det går till. Ofta bygger vi något som aldrig har gjorts tidigare, eller något som har gjorts för någon annan men på ett unikt sätt för oss. Det går inte att förutsäga framtiden helt, och den liknelsen hjälper andra att förstå det.

En annan utmaning är att erkänna det uppenbara: det finns mycket vi inte vet. Vi har kända kända, kända okända och okända okända. Med agilt arbete lever vi i den spänningen och arbetar med den typen av kaos på ett sätt som ändå låter oss skapa bra saker för användarna och göra deras liv bättre.

Michael Luchen

När man arbetar med programvaruutveckling handlar arbetet till sin natur om att skapa och samla kunskap. Det är så mycket mer än att bygga ett hus: hur lägger man tegelstenarna, hur skapar man tegelstenarna och hur lär man sig att skapa dem? Tänk om appen kräver ett annat material? Då måste man lära sig och bygga det. En stor del av programvaruutveckling handlar alltså om att bygga vår egen kunskap samtidigt som vi bygger produkten, vilket skapar ännu större variation i färdplanen.

Brandon Blackman

Det är bra.

Michael Luchen

Om vi växlar ned från färdplanens 50 000-fotsvy till nästa nivå, 30 000 fot, handlar det om sprintar och att bryta ned de stora delarna av färdplanen. Brandon, hur hjälper sprintar till att bryta ned färdplanen?

Brandon Blackman

En sprint bör ha ett mål. Varje sprint bör ha ett mål som ska vara uppnått när sprinten är slut, och målet bör alltid föra produkten, teamet och användarna längre fram längs färdplanen. Om målet är frånkopplat från eller inte överensstämmer med färdplanen bidrar arbetet inte till dess riktning.

På sprintplaneringen börjar jag därför alltid med den övergripande färdplanen innan vi går in på specifika berättelser och formulerar sprintmålet. När vi tittar på de kommande två veckorna och väljer vilka berättelser som kan genomföras ska målet tydligt peka mot den del av färdplanen vi befinner oss i. Det kan också vara ett indirekt steg, exempelvis ett backendexperiment som lägger grunden för en användarberättelse som är direkt kopplad till färdplanen. Sprintmålet är bron mellan dagens arbete och färdplanen.

Michael Luchen

Jag älskar sprintmål och att börja där. En utmaning är att sprintar riskerar att bli små vattenfallsprojekt. Hur hindrar man sprintar från att bli sådana små vattenfall i den större färdplanens sammanhang?

Brandon Blackman

Sprintar bör bestå av självständiga och användbara användarberättelser. Jag blir själv ibland lat när jag skriver användarberättelser och glömmer att de måste vara självständiga, testbara och användbara. Sprinten ska vara fokuserad så att målet är självständigt och användbart från början till slut. Du ska aldrig stå vid sprintens slut med något som inte kan användas förrän ytterligare två sprintar är klara.

Planera i stället så att varje sprint är självständig, möjlig att släppa och användbar. Användare ska i princip kunna gå in och använda den i produktionsmiljö. Det knyter an till idén om att släppa ofta. Det betyder inte nödvändigtvis att du ofta släpper till användare, utan att du släpper till någon form av förproduktionsmiljö där något kan användas och ge värde.

Michael Luchen

Det är mycket bra. När det gäller användarberättelser finns en fin balans: man vill inte vara för detaljerad, eftersom det kan göra berättelsen till ett vattenfall i sig, men man behöver tillräcklig tydlighet för att teamet ska kunna gå vidare och tillräcklig tvetydighet för att teamet ska kunna vara flexibelt och kreativt.

Brandon Blackman

Det är mycket viktigt. Om du blir för detaljerad hamnar du åter i hur-frågan. Som produktchef har jag begränsad insyn i utveckling och design. Om jag håller mig på en hög nivå lämnar jag utrymme för experterna att lösa problemen. Då har du stärkt de smartaste personerna i teamet och låter dem själva avgöra hur målet ska uppnås.

Michael Luchen

Hur ofta bör färdplanen granskas?

Brandon Blackman

Som produktchef tittar jag antagligen på den dagligen eller åtminstone varannan dag. Ur produktteamets perspektiv bör den granskas vid varje uppstart eller planeringsperiod. Den ska hjälpa till att avgöra sprintarna och sprintmålet och därmed vilka användarberättelser som tas med eller vilka epik som prioriteras. Ur företagets bredare perspektiv bör färdplanen tas fram varje gång produktteamet kommunicerar något om produkten till en större grupp intressenter. Den ger sammanhang och hjälper användare och intressenter att förstå varför en lansering eller ett epik är viktigt. Ta fram den så ofta du kan.

Michael Luchen

Vilken är din favorittyp av färdplan och vilket är ditt favoritsätt att arbeta?

Brandon Blackman

Det beror på produkten. För de flesta produkter arbetar jag med en temabaserad färdplan. Jag tycker om att se temat kopplat till företagets viktigaste mål. Det ger produktteamet möjlighet att välja vad vi vill arbeta med och ger utvecklare och designers möjlighet att själva avgöra hur temana ska uppnås. För mindre produkter fungerar detta särskilt bra. Jag arbetar exempelvis med en produkt i ett innovationslabb där vi bara har 14 dagar per år att arbeta med produkten. Färdplanen måste därför vara mycket koncis och övergripande, men samtidigt kommunicera vad som ska levereras under året. Statusar gör det möjligt att snabbt och effektivt kommunicera vad vi arbetar med nu, vad som kommer härnäst och vad som kan förväntas senare.

Michael Luchen

Innan vi avslutar vill jag ställa några personliga frågor i snabbformat.

Brandon Blackman

Kör.

Michael Luchen

Vilken personlig vana har bidragit mest till din framgång?

Brandon Blackman

Jag är lite gammaldags när det gäller att anteckna analogt. Att skriva ned saker i en anteckningsbok hjälper till att prägla dem i minnet och flytta dem från korttidsminnet till långtidsminnet. Jag tycker också om att drömma om framtiden med analoga verktyg. Jag kan skissa att-göra-listor och mål, följa upp saker och vara kreativ på ett tomt papper. En bra anteckningsbok och penna hjälper mig att följa det förflutna, organisera nuet och planera och utforma framtiden.

Michael Luchen

Vilket annat verktyg använder du regelbundet?

Brandon Blackman

Det kommer nog inte som en överraskning: Miro, verktyget för virtuella whiteboards. Jag har inte skapat en färdplan utanför Miro sedan den första dagen jag upptäckte det. Alla mina färdplaner finns i Miro. Jag kan ha en ram för färdplanen och även lägga till bilder eller Figma-integrationer för alla designer som bidrar till den. Jag kan skriva användarberättelser på whiteboarden och integrera dem med Jira. Miro förändrade verkligen mitt arbetssätt.

Michael Luchen

Vilket råd skulle du ge någon som precis har börjat sin karriär inom produktledning?

Brandon Blackman

Jag skulle råda dem att ta ett jobb på ett nystartat företag och bli produktchef utan tidigare erfarenhet. Jag visste inte vad produktledning eller agilt arbete var när jag började, men jag kastade mig in i det. Hitta ett nystartat företag eller skapa kanske ett eget vid sidan av ditt vanliga jobb. Arbeta med det på kvällarna och lär dig den agila processen genom att skapa något som inte finns. Det kan vara ett tjänsteföretag, en digital produkt eller vad som helst. I bästa fall blir du framgångsrik och i värsta fall händer inget, vilket är min historia. Men du får erfarenhet och kan därefter hitta ett arbete där du gör det du älskar och använder de färdigheter du har utvecklat.

Michael Luchen

Mycket kloka ord. Tack så mycket, Brandon, för att du var med i podcasten och delade med dig av din expertis inom färdplanering, produktutveckling och andra områden. Du kan läsa mer om Brandons arbete på crema.us eller hitta honom på LinkedIn. Tack igen för att du var med, Brandon.

Brandon Blackman

Tack så mycket för att jag fick vara med.

Michael Luchen Och tack så mycket till alla som lyssnade.

Glöm inte att lämna en recension av podcasten och berätta vad du tyckte om, vad du vill se mer av eller om det finns något vi inte tog upp som du vill att vi följer upp. Följ och gå gärna med i vår community@theproductmanager.com. Tack igen för att ni lyssnade. Vi hörs i nästa avsnitt.