Från spret till spets

Spretig backlog, trasslig kod och en konkurrent som hinner före? Diskussionen ser ofta likadan ut. Verksamheten vill framåt, användarna efterfrågar förbättringar och konkurrenterna lanserar nya lösningar. Samtidigt har er produkt vuxit fram under många år. Affärsregler har lagts ovanpå affärsregler, specialfall har blivit standardfall och integrationer har tillkommit längs vägen. Varje beslut har varit logiskt när det fattades, men tillsammans har de skapat en produkt som blivit allt svårare att utveckla, förvalta och förstå.

Spretigheten, eller utmaningen, beror sällan brist på idéer eller kompetens. Problemet är att organisationen fortsätter investera i en grund som inte längre ger rätt förutsättningar för förändring. Konsekvensen blir att utveckling tar längre tid, att nya initiativ skjuts på framtiden och att konkurrenter kan röra sig snabbare. Vi ser den här situationen oftare än många tror, särskilt nu. Känner du igen dig i det jag hittills beskrivit så känner du nog igen dig i nedanstående situationer också.

”Vi tappar kunder eller affärer för att vi saknar funktionalitet vi egentligen borde kunna bygga”

Många organisationer vet vilka behov som finns, vilka krav marknaden ställer och ofta även hur lösningen skulle kunna se ut. Utmaningen är att varje ny investering måste vägas mot risken att röra delar av systemet som redan är svåra att underhålla.

Det som borde vara en naturlig vidareutveckling blir istället ett tekniskt projekt med hög komplexitet och osäkerhet. Till slut börjar plattformen styra verksamhetens möjligheter snarare än tvärtom.

”Kravdokumentet är vår främsta källa till prioritering”

När osäkerheten ökar är det naturligt att försöka skapa tydlighet genom fler krav, fler specifikationer och längre backloggar. Men kravdokument beskriver ofta vad som ska levereras, snarare än varför det är viktigt.

Resultatet blir att team implementerar lösningar innan organisationen är överens om vilket problem som faktiskt ska lösas. När marknaden, användarna eller verksamheten förändras finns därför en risk att man bygger rätt funktion - för fel behov.

”Vi arbetar i en beställare- och leverantör-relation”

I många organisationer lever beställar- och leverantörsmodellen fortfarande kvar. Verksamheten beställer, utveckling levererar och design involveras sent, eller inte alls.

På pappret är ansvarsfördelningen tydlig, men i praktiken uppstår ofta ett glapp mellan intention och resultat. Verksamheten ansvarar för kraven och tekniken för leveransen, men ansvaret för att säkerställa att man bygger rätt lösning riskerar att hamna mellan stolarna.

”Vi bygger bara det konkurrenterna bygger”

Att bevaka konkurrenter är viktigt. De kan ge värdefulla insikter om trender, förväntningar och marknadsrörelser. Problemet uppstår när konkurrentanalysen blir den främsta drivkraften bakom produktutvecklingen.

Nya funktioner prioriteras för att täppa till upplevda gap snarare än för att de löser de viktigaste behoven hos användare och verksamhet. Då finns en risk att organisationen börjar reagera på marknaden istället för att leda den. Resultatet blir ofta att man bygger ikapp istället för att skapa verklig differentiering.

Beslut om vad som ska utvecklas härnäst bör därför i första hand baseras på användarbeteenden, kundfeedback, verksamhetsmål och data.

”Vi vet att vi borde göra något större - men vågar inte”

De flesta organisationer känner igen signalerna: teknisk skuld som växer, en arkitektur som inte längre stödjer verksamhetens ambitioner och en användarupplevelse som blivit svår att utveckla vidare.

Samtidigt upplevs det som svårt att stanna upp. Kunder väntar, projekt pågår och varje större förändring innebär både kostnader och risker. Därför fortsätter många att lappa och laga - inte för att det är den bästa vägen framåt, utan för att alternativen upplevs som för stora.

Omstart med stöd

Om flera av situationerna ovan känns bekanta är ni långt ifrån ensamma. Den goda nyheten är att lösningen sällan handlar om att arbeta hårdare eller leverera snabbare. Ofta handlar det istället om att skapa samsyn kring vad som faktiskt behöver lösas innan nästa investering görs.

Vilka problem är viktigast att adressera? Vad fungerar redan bra? Vad skapar störst värde för användarna? Hur bör strategi och roadmap se ut framåt? Och vilka delar av plattformen hjälper er att utvecklas - respektive håller er tillbaka?

Det är den typen av frågor som en design sprint hjälper till att besvara. Inte genom fler dokument eller fler möten, utan genom att samla verksamhet, produkt, design och teknik kring samma utmaning under en begränsad period.

Målet är inte att producera fler idéer. Målet är att skapa tillräcklig förståelse för att kunna fatta bättre beslut.

Vad får ni med er?

Efter en design sprint har ni vanligtvis:

  • En gemensam bild av problemet som ska lösas
  • Tydligare prioriteringar och ett mer realistiskt scope
  • En testad prototyp validerad med användare
  • Insikter kring teknik, arkitektur och framtida investeringar
  • En konkret plan för nästa steg

Minst lika viktigt är att ni får ett nytt sätt att arbeta tillsammans. Vi ser inte relationen som beställare och leverantör, utan som ett partnerskap där verksamhet, produkt, design och teknik gemensamt ansvarar för resultatet.

För i slutändan handlar produktutveckling sällan om att bygga mer. Det handlar om att förstå vad som är värt att bygga, varför det är viktigt och vilken grund som krävs för att kunna fortsätta utvecklas även imorgon.

Nyfiken på oss?

Kul! Vi är nyfikna på dig med. Hör av dig så lär vi känna varandra.