Utforskandet

35% av nystartade företag misslyckas för det inte finns något marknadsbehov 😱När CB Insights undersökte 111 post-mortems  var det på grund av avsaknad av marknadsbehov och den andra största orsaken varför de inte lyckades överleva.

Att bygga rätt produkt är verkligen inte en lätt sak verkar det som, och där jag ofta kan se företag saknar förmåga att utforska utifrån ett kund-, affärs- och organisatoriskt perspektiv för att hitta rätt produkt eller tjänst.

Det vanligaste sättet jag ser att man utvecklar produkter är genom att man börjar med lösningen och sedan försöker hitta ett problem där lösningen passar in. Jag vill att vi istället börjar med att utforska kunden och dess behov och problem och sedan tar fram en lösning utifrån detta.

För att fortsätta behöver du vara medlem, vilket är gratis

Det låter som en självklarhet och att vi gör det naturligt, ofta och enkelt. När jag träffar ledare och team så hör och ser jag många gånger följande utmaningar

• Teamet har en väl optimerat leveransprocess men ingen vana av att utforska nya möjligheter
• Teamet prioriterar inte utforskande och lärandet då de har så mycket som "måste levereras"
• Utforskande aktiviteter i teamet sker ad-hoc och det finns ingen struktur eller stöd kring metodik
• Ledare och andra personer på taktisk nivå har inte vana att utforska nya möjligheter, har liten struktur och metodik och vet inte hur de ska kommunicera med teamet på en lagom nivå. Hur de kan beskriva ett önskemål eller krav utan att bli för detaljerad och styra teamet för hårt
• Det är andra i organisationen som utforskar och vi ska bara leverera features och lösningar. Ofta får vi klar dokumentation som vi ska tolka och genomföra
• Teamet mäts på aktiviteter (output) istället för effekt (outcome) som t.ex. att en feature är i produktion men vi vet inte om den skapar något värde. Teamet mäts på antal färdiga klara saker (burndown), antal timmar arbetat, eller kostnad.
• Teamet uppskattas och bedöms på vad de gjort (demo) istället för vilket värde som skapats. Ofta på agila demos så visar teamet upp vad de skapat men det blir sällan prat kring vilket värde som skapats.

Kan du känna igen dig i något av detta?  Hur kan vi då komma åt några av dessa utmaningar?

Pusselbitar

Här är några pusselbitar som jag ser behövs för att lösa detta

• Det behövs en (1) process för produkt- eller tjänsteutveckling som beskriver både bygga rätt produkt (product discovery) och bygga den på rätt sätt (product delivery)
• Ledare och teamet måste ha tid för att få arbeta med utforskande aktiviteter och det måste vara synligt i deras arbetsmängd (backlog)
• Det behövs rätt förhållningssätt, kompetens, metodik och verktyg för att kunna arbeta utforskande. Alla i teamet och taktiska ledare behöver kunna arbeta utforskande
• Om utforskande arbete görs utanför teamet behöver det finnas ett format och visualisering som fungerar bra som handskakning. Det kan handla om vilka frågor som behöver vara besvarade innan teamet börjar arbete. Det kan vara på vilken grad möjliga lösningar ska vara visualiserade. Det kan vara vilka möten och ceremonier som behövs för att överföra kunskap mellan människor.
• Att börja planera och följa upp på teamets arbete på värde och effekt istället för bara aktiviteter. Att inte bara lyfta teamet för deras aktiviteter utan även för vilken effekt de skapat.

Det låter väl enkelt, eller? Jag kommer nedan att fokusera lite på processen och balansen mellan utforskande (product discovery) och leverans (product delivery).

Process

En utmaning är ju själva processen där jag ser att det finns lite olika sätt att arbeta. Jag kommer här beskriva fem olika sätt som jag ser att företag använder sig av.

1. Sekventiellt arbete i olika grupper — klassisk vattenfallsmodell, där en grupp tänker och en annan utför. Ofta med dokumentation som medel för att föra vidare information i processen
2. Parallellt arbete i olika grupper — lik en klassisk vattenfallsmodell men att det ofta finns en grupp som arbetar på strategisk eller taktisk nivå och utforskar nya möjligheter, t.ex. innovationslabb eller R&D. Ofta med dokumentation som medel för att föra vidare information i processen och där initiativ ofta behöver prioriteras för att få finansiering
3. Parallellt arbete inom samma grupp — teamet arbetar både med utforskande arbete och leverans. Ofta är det några roller som fokuserar på utforskande, som t.ex. Produktägare och UX Designer. Utforskande arbete görs ofta tidigare, en eller flera sprintar innan leverans startar. Detta kallas ofta för dual track eller mini-vattenfall. Ofta är det mindre dokumentation som medel för att föra vidare information utan mer kommunikation och samarbete.
4. Sekventiellt arbete inom samma grupp — teamet arbetar både med utforskande arbete och leverans. Hela teamet arbetar först utforskande för att sedan arbeta med leverans. Ofta är det mindre dokumentation som medel för att föra vidare information, utan mer kommunikation och samarbete.
5. Parallellt arbete inom samma grupp i vågor — teamet arbetar både med utforskande arbete och leverans. Lite beroende på vilken fas teamet är i, så lägger teamet mer fokus på utforskande eller leverans. Ofta är det mindre dokumentation som medel för att föra vidare information utan mer kommunikation och samarbete. Denna modell används ofta när det finns en mogen produkt som måste både förvaltas och utvecklas.

Vilken modell är bäst undrar du? Jag har satt dem i den ordningen som jag upplever som bäst. Men jag vet att det finns så många olika förutsättningar och kulturer som spelar roll kring vad som är bästa arbetssätt. Alla modeller har sina för- och nackdelar såklart. Jag värdesätter de olika modellerna utifrån några principer:

• Samarbete och inkludering framför dokumentation
• Att alltid utgå från perspektiven produkt, design och teknik
• Att fokusera på få saker, istället framför att göra flera saker samtidigt
• Värde och effekt framför aktivitet
• Långsiktigt ägarskap av en produkt eller tjänst framför kortsiktiga projekt

Tips kring utforskandet

Om jag ska ge lite tips kring att få ihop det här med att arbeta utforskande:

• Se utforskande som en prioriterad aktivitet. Se till att lägga tid på att bygga rätt sak
• Utforskande aktiviteter har som syfte att lära sig något som du inte vet. Det handlar inte om att bygga något riktigt för en kund. Se allt som experiment, prototyper och tester
• Om du jobbar på strategisk eller taktisk nivå, och du inte jobbar direkt med teamet. Prata ihop dig med dem för att se vad de behöver för att ta arbetet vidare och i vilken form ni kan samarbeta. Hur vill teamet bli involverat? Vilka frågor vill de ha besvarade? Går det att visualisera möjliga lösningar på en grov nivå för att enklare kunna förklara ett koncept?
• Prata ihop er, inom teamet eller i er organisation hur ni kan arbeta med både utforskande och leverans. Bra om ni även försöker beskriva denna process så alla har samma bild
• Inom teamet, prata ihop er hur mycket tid ni har att lägga på utforskande aktiviteter. Så att ni har samma bild och ambition, t.ex. vi ska har fyra perioder där vi alla jobbar med att lära oss mer kring en fråga
• Utforska alltid utifrån perspektiven affär (viability), kund (customer desirability) och organisatorisk förmåga (organizational feasibility)
• Ha med så många som möjligt som arbetar med leverans i utforskande aktiviteter. Detta gör att ni kan minska på dokumentation och överlämningar och lägga tid på värdeskapande aktiviteter.

Sammanfattning

Att jobba med utforskande aktiviteter i sig själv är ju inte svårt eller krångligt, men det blir ofta det är man är fler och det krävs större samarbete. Det jag ofta återkommer till är att du och de du arbetar med behöver ha en gemensam bild över hur ni ska arbeta tillsammans.

Ta gärna och sprid denna artikel till de du jobbar med och avsätt en stund för att prata kring hur ni bäst kan jobba tillsammans. Att arbeta med utforskande aktiviteter är roligt och spännande och leder till att ni bygger rätt produkt där ni skapar ett värde för kund, affär eller organisation.