Kartläggning för att skapa en produktorganisation

Written by

Att skapa en ny organisation från en gammal handlar till stor del om att reda ut och förstå vad som tillhör var. Om du har gjort det tidigare kan du se mönster som är till hjälp. Att använda visualisering och att arbeta på ett strukturerat sätt, steg för steg och involvera människorna är några hjälpsamma sätt att arbeta på.

Precis som alltid i den komplexa domänen är det bättre att inte använda sig av goda praxis (samma lösning som andra). Genom att gå tillväga experimentellt, steg för steg, kan du säkrare hitta bra lösningar baserat på designprinciper och mönster.

När du tänker på det kanske du inser att det faktiskt är ganska likt att bygga fantastiska produkter som kunder älskar – baserat på ett äldre system. Så varför inte använda liknande arbetssätt?

När vi börjar behöver vi se vad vi har för närvarande, och även det är en komplex strävan. För att få en gemensam bild av den nuvarande organisationen kan du använda olika tekniker, och vanligtvis behövs en bra mix. I detta inlägg kommer vi att titta på hur du kan kartlägga nuvarande team, produkter och kundresor, samt systemens tillstånd och börja se vilka team som kanske tar ansvar för vad, i en steg-för-steg-approach.

Produkter och tjänster

Som en start kan du börja tillsammans att kartlägga de produkter som dina kunder betalar för. Det är det vi vanligtvis kallar produkter i en agil organisation. Det är där någon form av pengar utbyts, och om det sker på månatlig basis så kan det vara en tjänst.

Nedan ser du ett exempel på de övergripande produkterna och tjänsterna som är kartlagda, både för B2B och B2C. Det finns ingen anledning att göra det mer avancerat än så här. Om du senare förstår att du faktiskt har fler produkter, kan du enkelt lägga till dem om du skapar ett skalbart system.

Kundresan

Många organisationer har också en kundresa som användaren genomgår. Varför är då kundresan så viktig när man utformar organisationen? Det har att göra med kundupplevelsen. När en användare rör sig genom många olika touchpoints och kanske använder flera av dina produkter är det kritiskt att den övergripande kundupplevelsen är samstämmig, och det är svårt att uppnå om man inte fokuserar på detta när man utformar organisationen. Om vi inte tar med detta som en viktig parameter kan det bli så att vi utformar organisationen baserat på våra interna preferenser och inte för den bästa kundupplevelsen – och det skulle inte vara en produktorganisation.

Ovan ser du en kundresa kartlagd under en workshop när vi kartlade alla produkter och tjänster i små grupper. Gjort på bara några få timmar, och sedan digitaliserat i en gemensam vy.

Kombinerad kundresa och produktvy

Som du ser är kundresan kombinerad med alla produkter på vänster sida, vilket ger en bra gemensam förståelse för vad användaren gör i varje del av kundresan och hur det är anpassat till produkterna.

När detta är klart kan vi börja kartlägga systemfunktionerna och vilken typ av team vi kanske behöver.

Mappa teamen till mixen

Målet bör vara att möjliggöra samordning genom autonomi, och kundresan är ett utmärkt sätt att möjliggöra mer av båda. I denna kartläggning kan vi lägga till två ytterligare perspektiv.

På vänster sida ser du en skala från toppen, synligt, till botten, osynligt. Detta visualiserar hur synligt det är för användaren. Användaren använder det som är närmast kundresan.

I botten ser du en förklaring över tre tillstånd för IT/digitala system som kan vara värdefulla att överväga. Dessa tre är:

Osäkert, ovanligt, konstant i förändring – Frågetecknet 
Dessa system/komponenter är mestadels nya. Här behöver vi oftast bygga, mäta och lära mer för att kunna lära oss vad som fungerar eller inte. Att göra stora förberedande planer för dessa är inte hållbart och skulle innebära hög risk. Att ha ett team som arbetar med detta är ofta en bra plan.

Känt and stabilt – Lådan
Dessa system/komponenter är kända och stabila över tid. Här inträffar inte många överraskningar och vi kan planera mer långsiktigt. Här kan det vara okej att ha flera team som arbetar eftersom vi kan bygga expertis över tid i fler team.

Utdaterat – Utropstecknet
Dessa system/komponenter blir föråldrade och behöver ersättas. Det är oftast en bra idé om teamet som äger en utdaterad komponent/system också ersätter den. Om det kan göras stegvis är det vanligtvis mycket säkrare och du kan dra nytta av de nya delarna mycket snabbare än om du skulle göra en stor mega-leverans.

Vem äger vad?

När man definierar vem som ska ta ansvar för vad måste de som arbetar i teamen vara involverade för att identifiera vad som ska vara var, men utan överblicken som du skapat ovan kanske det inte är så lätt. Med denna kartläggning går det ofta lite lättare, men det är aldrig helt enkelt. Att ha ett “Good enough for now and safe enough to try” tankesätt är avgörande. Du kommer att fatta dåliga beslut, och det måste finnas ett sätt att göra det på ett säkert sätt och för teamen att kunna iterera och anpassa sig över tid. Om du har ett agilt tankesätt och agila ledarskapsprinciper kan ni göra detta tillsammans.

Att definiera värdefulla principer för hur man ska tänka när man delar upp och försöka identifiera vad som hör hemma var och vilken typ av team man kan behöva hjälper också mycket.

Några hjälpsamma principer kan vara:

  • Teamen som bygger någonting äger också underhållet – och byter ut det
  • Alla team ska kunna arbeta med varandras komponenter (men det måste finnas ett säkert sätt att göra så)
  • Ansvar är lika med mandat
  • Team som arbetar med att supportera kundresan eller produktteamen har alltid sina behov som prio 1 för att möjliggöra flöde.
  • Team som behöver samarbeta arbetar med samma kadens.
  • Team som behöver samarbeta bör skriva ett samarbetsavtal.
  • Team bör kunna hantera alla kundkontaktpunkter inom det området
  • Team ska ha kapacitet att hantera både discovery och leverans
  • Den långsiktiga kundupplevelsen ska alltid vara viktigare än kortsiktiga interna behov.
  • Allt tillhör ett team, såväl människor som teknik och användargränsnitt

Vilken typ av team behövs?

Här har vi definierat 4 olika typer av team som kan vara värdefulla att överväga. Alla dessa team (förutom tjänsteteamen) bör vara vad vi kallar produktteam, som har alla möjligheter att arbeta från början och göra både discovery och leverans och optimera produkten/tjänsten. Detta för att skapa den högsta presterande, autonoma och lättanpassade organisationen.

Kundreseteam
Levererar strategier kopplade till kundresan, som att öka antalet nya kunder, livstidsvärde eller ökad användning.

Produktteam
Levererar strategier kopplade till specifika produkter och underhåller plattformen för långvarig hög kvalitet och hastighet.

Plattformsteam
Plattformsteam levererar funktionalitet i plattformen för att stödja behov från Kundrese – och Produktteam.

Serviceteam
Serviceteam agerar för att leverera självbetjäning för alla andra team. Kan också coacha, utbilda, mentorera och stödja i anpassning och strategisk input.


Vill du lära dig mer om agil produktutveckling?

Denna utbildning vänder sig till dig som idag arbetar med digital produktutveckling, eller om du vill börja med det, och vill använda effektdrivna metoder för att bättre anpassa lösningen till användarens och verksamhetens behov. Du och ditt team får en definierad process och en kraftfull verktygslåda för innovation med korta feedbackloopar och en tydlig koppling till Scrum och Agil produktutveckling.

Läs mer om utbildningen

Shopping basket
Related Trainings
Build the Right Product – Product Ownership Training – 2 dagar på plats
Target Group: Produktchefer, Produktägare, Affärsutvecklare, Arkitekter och utvecklare, User- and Customer Experience (UX/CX) (User Researcher, Interaktionsdesigner, Grafisk formgivare, Art Director) Alla som jobbar i produktprocessen, och som faciliterar den.
Teachers: Mia Kolmodin
Nytt datum inom kort
Our Trainings
DesignOps – Bli snabbare, få bättre affärsvärde och ta nästa steg inom DesignOps, DesignSystems och Design Ledadership
Target Group: Head of Design, UX Team Lead, UX Lead, DesignOps Manager, DesignOps Specialist eller liknande roll, Konsult inom dessa områden, alla med intresse av DesignOps.
Teachers: Jens Wedin, Monica Enecrona
1, 8, 15, 22 oktober - Stockholm