Skapa med empati för kunderna

"Nödvändigt är uppfinningens moder." Det här ordspråket fångar den mänskliga människans odelbarhet och vår naturliga enhet för att inventa. Som förklaras i Oxford English Dictionary , "När behovet av något blir imperativt, måste du hitta sätt att få eller uppnå det." Få skulle neka dessa universella sanningar om uppfinningar. Som beskrivs i Innovation i den digitala ekonomin kräver dockmolninnovation en balans mellan uppfinning och införande.

Om vi fortsätter med analogin kommer innovationen från en mer utökad familj. Kundens empati är den stolte överordnade av innovation. Att skapa en empatilösning för kunder som driver innovation kräver ett legitimt kund behov som håller kunden tillbaka för att lösa kritiska utmaningar. Dessa lösningar baseras på vad en kund behöver i stället för på deras önskemål eller problem. För att hitta deras verkliga behov börjar vi med empati, en djup förståelse för kundens upplevelse. Empati är en underutvecklad kompetens för många tekniker, produktansvariga och till och med företagsledare. Som tur är har molnarkitektrollens olika interaktioner och snabba takt redan börjat främja den här färdigheten.

Hur skapar vi empati och varför är kundens empati så viktig? Kundens empati hjälper oss att förstå och dela med oss av kundens upplevelse. Från den första versionen av en MVP (minsta fungerande produkt) till den allmänna tillgängligheten för en lösning i marknadsklass hjälper kund empati oss att skapa en bättre lösning. Ännu viktigare är att det är bättre för oss att hitta lösningar som uppmuntrar till införande. I en digital ekonomi kan de som är mest empatisera med kundernas behov skapa en bättre framtid som omdefinierar och leder marknaden.

Skapa med empati för kunder

Att definiera antaganden är en grundläggande del av planeringen. Ju mer vi planerar, desto mer ser vi antaganden som kryper in i grunden för en bra idé. Antaganden är vanligtvis produkten av själv empati. Vad skulle jag med andra ord vilja ha om jag hade den här positionen? Från och med byggfasen minimeras den period då antaganden kan skapa en lösning. Den här metoden påskyndar också feedback-loopen med verkliga kunder, vilket ger tidigare möjligheter att lära sig och förbättra empati.

Varning

Det kan vara svårt att korrekt definiera vad som ska byggas och det krävs lite övning. Om du skapar något för snabbt kanske det inte återspeglar kundernas behov. Om du ägnar för mycket tid åt att försöka förstå kundernas initiala behov och lösningskrav kan marknaden uppfylla dem innan du har möjlighet att skapa något alls. I båda scenarierna kan möjligheten att lära sig fördröjas eller minskas avsevärt. Ibland kan data till och med skadas.

De mest innovativa lösningarna i historien började med en intuitiv tro. Den mag känsla kommer från både befintlig expertis och förstahandsobservation. Vi börjar med byggfasen eftersom den möjliggör ett snabbt test av denna intuition. Därifrån kan vi fördjupa djupare förståelse och tydligare grader av empati. Vid varje iteration eller lansering av en lösning kommer balansen från att skapa MVP:er som demonstrerar kundens empati.

För att stabil denna balansgång ska fungera diskuterar följande två avsnitt begreppen för hur man skapar med empati och definierar en MVP.

Definiera en kundfokuserad hypotes

Att skapa med empati innebär att skapa en lösning baserad på definierade hypoteser som illustrerar ett specifikt kund behov. Följande steg syftar till att formulera en hypotes som uppmuntrar till att skapa med empati.

  1. När du skapar med empati är kunden alltid i fokus. Den här avsikten kan ha många former. Du kan referera till en kundarketyp, en specifik person eller till och med en bild av en kund för att se vilket problem du vill lösa. Och tänk på att kunder kan vara interna (anställda eller partner) eller externa (konsumenter eller företagskunder). Den här definitionen är den första hypotesen som ska testas: kan vi hjälpa den här specifika kunden?
  2. Förstå kundupplevelsen. Att skapa med empati innebär att du kan relatera till kundens upplevelse och förstå deras utmaningar. Det här tankesättet anger nästa hypotes som ska testas: kan vi hjälpa den här specifika kunden med den här hanterbara utmaningen?
  3. Definiera en enkel lösning på en enskild utmaning. Att förlita sig på expertis hos personer, processer och ämnesexperter leder till en potentiell lösning. Det här är den fullständiga hypotes som ska testas: kan vi hjälpa den här specifika kunden med den här hanterbara utmaningen genom den föreslagna lösningen?
  4. Ankommer till en value-instruktion. Vilket långsiktigt värde vill du ge dessa kunder? Svaret på den här frågan skapar din fullständiga hypotes: hur kommer dessa kunders liv att förbättras med hjälp av den föreslagna lösningen för att hantera den här hanterbara utmaningen?

Det sista steget är att skapa en kundhypotes med empati. Den definierar målgruppen, problemet, lösningen och det mått som förbättringen ska göras med, vilket är viktigt för kunden. Under mått- och lär dig-faserna bör varje hypotes testas. Ändringar i kunden, problemutdrag eller lösningar förväntas när teamet utvecklar större empati för den adresserbara kundbasen.

Varning

Målet är att skapa med empati för kunderna, inte att planera med den. Det är alltför enkelt att fastna i oändliga cykler av planering och justeringar för att få till ett perfekt empatiutdrag från kunden. Innan du försöker utveckla en sådan instruktion kan du läsa följande avsnitt om att definiera och skapa en MVP.

När grundläggande antaganden har visat sig kommer senare iterationer att fokusera på tillväxttester utöver empatitester. När empati har skapats, testats och validerats kan du börja förstå den adresserbara marknaden i stor skala. Detta kan göras genom en utökning av standardhypotesformeln som beskrevs tidigare. Beräkna storleken på den totala marknaden (antalet potentiella kunder) baserat på tillgängliga data.

Därifrån kan du beräkna procentandelen av den totala marknaden som har en liknande utmaning och som därför kan vara intresserad av den här lösningen. Det här är din adresserbara marknad. Nästa hypotes som ska testas är: hur kommer x % av kundernas liv att förbättras med hjälp av den föreslagna lösningen för att hantera den här hanterbara utmaningen? Ett litet urval av kunder visar på ledande indikatorer som tyder på en procentuell påverkan på poolen med kunder som är engagerade.

Definiera en lösning för att testa hypotesen

Under varje iteration av en feedbackslinga "skapa-mät-lär dig" definieras ditt försök att skapa med empati av en MVP.

En MVP är den minsta arbetsinsats (uppfinning, teknik, programutveckling eller dataarkitektur) som krävs för att skapa tillräckligt med en lösning för att lära sig med kunden. Målet med varje MVP är att testa några eller alla tidigare hypoteser och att få feedback direkt från kunden. Resultatet är inte ett snyggt program med alla funktioner som krävs för att ändra din bransch. Önskade utdata för varje iteration är en inlärningsmöjlighet, en möjlighet att mer djupt testa en hypotes.

Tidsboxning är ett standard sätt att se till att en produkt förblir lean. Se till exempel till att utvecklingsteamet tror att lösningen kan skapas i en enda iteration för snabb testning. Mer information om hur du använder hastighet, iterationer och versioner för att definiera vad minimalt innebär finns i Planera hastighet, iterationer, lansering och iterationssökvägar.

Minska komplexiteten och fördröja tekniska toppar

Innovationsområdet i innovationsmetoden beskriver de funktioner som ofta krävs för att leverera en mogen innovation eller skalklar MVP-lösning. Använd de här disciplinerna som en långsiktig guide för inkludering av funktioner. På samma sätt kan du använda dem som en varningsguide vid tidig testning av kundvärde och empati i din lösning.

Funktionslängd och de olika disciplinerna för uppfinningar kan inte skapas i en enda iteration. Det kan ta flera versioner för en MVP-lösning att inkludera komplexiteten i flera områden. Beroende på investeringen i utveckling kan det finnas flera parallella team som arbetar inom olika områden för att testa flera hypoteser. Även om det är smart att upprätthålla arkitekturjusteringen mellan dessa team, är det inte klokt att försöka skapa komplexa, integrerade lösningar tills värdehypesser kan valideras.

Komplexitet identifieras bäst i frekvensen eller volymen av tekniska toppar. Tekniska toppar är arbete med att skapa tekniska lösningar som inte enkelt kan testas med kunder. När kundernas värde och empati inte testas utgör tekniska toppar en risk för innovation och bör minimeras. För de typer av mogna testade lösningar som finns i ett migreringsarbete kan tekniska toppar vara vanliga under implementeringen. De försenar dock testningen av hypoteser i innovationsarbetet och bör skjutas upp när det är möjligt.

En obeveklig förenklad metod föreslås för alla MVP-definitioner. Den här metoden innebär att du tar bort allt som inte gör det möjligt för dig att validera hypotesen. Minska antalet integreringar och funktioner som inte krävs för att testa hypotesen för att minimera komplexiteten.

Skapa en MVP

Vid varje iteration kan en MVP-lösning ha många olika former. Det vanliga kravet är bara att utdata gör det möjligt att mäta och testa hypotesen. Det här enkla kravet initierar den vetenskapliga processen och gör att teamet kan bygga med empati. För att leverera detta kundfokus i första hand kan en inledande MVP förlita sig på endast ett av uppfinningsdisciplinerna.

I vissa fall innebär den snabbaste vägen till innovation att tillfälligt undvika dessa områden helt och hållet, tills molnanpassningsteamet är säkra på att hypotesen har verifierats korrekt. Den här vägledningen kan låta kontraintuitiv från ett teknikföretag som Microsoft. Detta betonar dock bara kundernas behov, inte ett specifikt teknikbeslut, är den högsta prioriteten i en MVP-lösning.

Vanligtvis består en MVP-lösning av ett enkelt program eller en datalösning med minimala funktioner och begränsat polska. För organisationer som har expertkunskaper inom professionell utveckling är den här utbildningsvägen ofta snabbast för inlärning och iteration. Följande lista innehåller flera andra metoder som ett team kan använda för att skapa en MVP:

  • En förutsägelsealgoritm som är fel 99 procent av tiden, men som visar specifika önskade resultat.
  • En IoT-enhet som inte kommunicerar säkert i produktionsskala, men som visar värdet av nästan realtidsdata i en process.
  • Ett program som skapats av en medborgarutvecklare för att testa en hypotes eller uppfylla behov i mindre skala.
  • En manuell process som skapar fördelarna med programmet på nytt.
  • En trådram eller video som är tillräckligt detaljerad för att kunden ska kunna interagera.

Att utveckla en MVP bör inte kräva enorma mängder utvecklingsinvesteringar. Helst bör investeringen vara så begränsad som möjligt för att minimera antalet hypoteser som testas samtidigt. I varje iteration och i varje version förbättras lösningen avsiktligt mot en skalklar lösning som representerar flera uppfinningsdiscipliner.

Påskynda MVP-utveckling

Tid till marknad är avgörande för framgången för alla innovationer. Snabbare versioner leder till snabbare inlärning. Snabbare inlärning leder till produkter som kan skalas snabbare. Ibland kan traditionella programutvecklingscykler göra den här processen långsammare. Oftare begränsas innovationen av begränsningar för tillgänglig expertis. Budgetar, personalstyrka och tillgänglighet för personal kan alla skapa gränser för antalet nya innovationer som ett team kan hantera.

Bemanningsbegränsningar och önskemål om att skapa med empati har gett upphov till en snabbt växande trend mot medborgarutvecklare. Dessa utvecklare minskar risken och ger skalning i en organisations community för professionell utveckling. Medborgarutvecklare är ämnesexperter när det gäller kundupplevelsen, men de tränas inte som tekniker. De här individerna använder prototypverktyg eller enklare utvecklingsverktyg som professionella utvecklare kanske inte vill ha. Dessa affärsriktade utvecklare skapar MVP-lösningar och testteorier. När processen är väl anpassad kan den här processen skapa produktionslösningar som ger värde men som inte klarar en tillräckligt effektiv skalningshypotes. De kan också användas för att verifiera en prototyp innan skalningsarbetet påbörjas.

I alla innovationsplan bör molnanpassningsteamen utöka sina portföljer för att inkludera arbete med medborgarutvecklare. Genom att skala utvecklingsarbetet kan mer hypoteser bildas och testas vid en minskad investering. När en hypotes valideras och en adresserbar marknad identifieras kan professionella utvecklare härda och skala lösningen med hjälp av moderna utvecklingsverktyg.

Slutlig byggport: Kundens ont

När kundens empati är stark bör ett tydligt befintligt problem vara lätt att identifiera. Kundens problem bör vara uppenbart. Under bygget skapar molnanpassningsteamet en lösning för att testa en hypotes baserat på en kunds problempunkt. Om hypotesen är väldefinierad, men inte problempunkten, är lösningen inte helt baserad på kundens empati. I det här scenariot är bygget inte rätt startpunkt. Investera i stället först i att skapa empati och lära av verkliga kunder. Den bästa metoden för att skapa empati och validera ont är enkel: lyssna på dina kunder. Investera tid i att träffa och observera dem tills du kan identifiera en problempunkt som förekommer ofta. När problempunkten är väl förstådd är du redo att testa en hypotesiserad lösning för att åtgärda problemet.

När du inte ska använda den här metoden

Det finns många juridiska krav, efterlevnadskrav och branschkrav som kan kräva en alternativ metod. Om offentliga versioner av en utvecklingslösning skapar risker för tidsinställning, skydd av immateriell egendom, kunddataläckor eller brott mot etablerade efterlevnadskrav, kanske den här metoden inte är lämplig. När det finns uppfattade risker som dessa bör du vända dig till juridiska rådgivare innan du inför någon guidad metod för versionshantering.

Referenser

Några av begreppen i den här artikeln bygger på ämnen som diskuteras The Lean Startup i av Eric Ries.

Nästa steg

När du har skapat en MVP-lösning kan du mäta empativärdet och skalningsvärdet. Lär dig hur du mäter hur kunderna påverkar.