För tidigt eller för sent. Eller hela tiden.

Tidningarna rapporterar att Volkswagen lanserar sin första elbil, ID.3, med stora mjukvaruproblem. Ett gott betyg förutsatt att de har förmågan att hantera problemen. När mjukvara utgör en bärande del av produkten får problem en lite annorlunda betydelse. Ett problem med hårdvaran på en bil kan innebära en katastrof. Hårdvara som strular innebär ofta en betydande kostnad att korrigera och tar lång tid att åtgärda. Att lansera tidigt och låta kundernas feedback bli en del av utvecklingen av hårdvaran är sällan ett alternativ.

Men problem med mjukvara är just bara problem i ordets rätta bemärkelse. Det vill säga ”svårighet som det krävs ansträngning att komma till rätta med” som ordet problem betyder enligt SAOL.

I en uppkopplad värld som till stor del bygger på mjukvara gäller det att lansera tidigt och ofta. Och låta kundernas feedback bli en del av utvecklingen. Inte bara för att kapitalisera tidigt utan även för att få feedback tidigt och därmed lära sig tidigt.

Det Volkswagen kan göra med ID.3 är att få faktisk kunskap om vad användarna har för behov och vilka problem med mjukvaran som behöver prioriteras. Innan lansering är våra idéer bara hypoteser som väntar på validering eller falsifiering. En validering och falsifiering som sker av kund.

Producers innovate; customers validate.

Hårdvara/mjukvara exemplet går att applicera även på digital kommunikation. När kommunikation bara skedde genom “hårdvara” det vill säga via analoga kanaler med hjälp av fysiska trycksaker var ledtiderna långa och användarinvolveringen inte lika enkel. I skiftet till digital kommunikation med “mjukvara” går det att lansera tidigt och ofta och med hjälp av användarna justera och uppdatera kommunikationen löpande. I det paradigment finns det fortfarande exemel på digital kommunikation som bedrivs som den vore analog, dvs med stora kommunikationsplaner som ger långa ledtider och liten förståelse för den iterativa processen där läsaren är en del av processen att ständigt förbättra budskapet.

Mer värde på marknaden tidigt

Att lansera tidigt och ofta ger oss inte bara fördelar av att vi lär oss tidigt och kapitaliserar tidigt. Det finns också mer värde på marknaden att ta del av om vi lanserar tidigt.

Ett annat exempel från fordonsindustrin visar på det. Vad hade hänt med SAAB om de hade lyckats komma ut tidigt på den populära cross-country marknaden med sin 9-3 modell? Det spekuleras i om historien kring SAAB skulle ha blivit en helt annan om de hade lyckats få ut modellen på marknaden redan 2006. Modellen visades upp på bilsalonger 2005 och i vanliga fall kommer bilen ut till konsument året efter. Istället dröjde det till 2009 (!) och då hade bland annat XC70 ätit upp en stor del av marknaden. Det finns mer värde på en marknad tidigt än sent.

Osäkerhet kring volym = risk

I produktutveckling är volym en av de stora riskerna kopplat till värde. Vi kan ha bra koll på utvecklingskostnad, tänkt pris till kund och ledtider men vi kan inte veta det faktiska värdet eftersom volym (antal konverteringar) är en del av värdet och volymen är resultatet av hur produkten konverterar på marknaden. Och volym föregås av intresse. Volym kan inte uppstå utan intresse på en öppen marknad. Det enda sättet att veta hur många som är intresserade är att göra produkten, eller med fördel en MVP av produkten, tillgänglig på marknaden. När Filmstaden vill ta reda på intresset för en film släpper de helt sonika biljetterna till filmen. Framgången för produkten (filmen) är helt avhängt volymen.  

Dagens Nyheter, augusti 2020.

Låga omställningskostnader är en förutsättning för innovation

För att lansera tidigt och ofta och kunna ha inställning att mjukvaruproblem bara är behov som går från ökända till kända måste vi ha låga omställningskostnader (anges även ibland som transaktionskostnad) i vår utveckling. Det betyder att varje experiment behöver kosta så lite som möjligt – att de har en så låg omställningskostnad som möjligt. När vi lanserar tidigt behöver vi inte se hela markanden som vår arena för test. IT-förmåga att bedriva A/B-tester och toggling gör att små experiment via små batchar kan lanseras tidigt till utvalda kundgrupper för snabb feedback.

Det behöver både vara enkelt och billigt att lansera tidigt och ofta. Och vi behöver kunna minimera risk genom att lansera till mindre utvalda kundsegment.

Låga omställningskostnader får vi bland annat om vi:

  • Organisera människor kring värde i värdeströmmar med få överlämningar och väntetider med fokus att utveckla end-to-end – ”from concept to cash”
  • Fokus på DevOps
  • Automatisering, bla automatiserade tester
  • Små batchar

Sammanfattning

För att tämja “leveransparadoxen”, dvs att vi måste leverera för att veta vad vi behöver leverera behöver vi se på mjukvara och mjukvaruproblem på ett annat sätt. Mjukvaruproblem får en helt ny innebörd när vi kan leverera tidigt och ofta. Problemen är ju bara faktisk data på vad vi behöver uppdatera och justera.

Problem är ju bara faktisk data på vad vi behöver uppdatera

Har vi inte låga omställningskostnader och förmågan att leverera tidigt och ofta då har vi inte problem, då har vi en begynnande kris.

När allt kommer omkring är vi aldrig bättre än vår senaste mjukvaruuppdatering. 

Läs mer

Lämna ett svar