Skapa med empati för kunderna

"Nödvändighet är uppfinningens moder." Det här talesättet fångar den mänskliga andens odelbarhet och vår naturliga strävan att uppfinna. Som förklaras i Oxford English Dictionary, "När behovet av något blir absolut nödvändigt, tvingas du hitta sätt att få eller uppnå det." Få skulle förneka dessa universella sanningar om uppfinningar. Men som artikeln Innovation i den digitala ekonomin förklarar kräver molninnovation en balans mellan uppfinningar och implementering.

Om vi fortsätter med analogin kommer innovationen från en mer utökad familj. Kundens empati är den stolta föräldern till innovation. För att skapa en lösning för kund empati, som främjar innovation, krävs ett legitimt kundbehov som gör att de kommer tillbaka för att lösa kritiska utmaningar. Dessa lösningar baseras på vad kunderna behöver snarare än önskemål eller nycker. Börja med empati och en djup förståelse för kundupplevelsen för att hitta kundernas verkliga behov. Empati är en underutvecklad färdighet för många ingenjörer, produktchefer och till och med företagsledare. Lyckligtvis främjar de olika interaktionerna och den snabba takten i molnarkitektrollen den här färdigheten.

Hur bygger man empati och varför är kund empati så viktigt? Kund empati hjälper dig att förstå och dela med dig av kundens upplevelse. Från den första versionen av en lägsta livskraftig produkt (MVP) till den allmänna tillgängligheten för en lösning i marknadsklass hjälper kund empati dig att skapa bättre lösningar. Ännu viktigare är att empati bättre positionerar ett team för att hitta lösningar som uppmuntrar till implementering. I en digital ekonomi kan produktteam som lätt kan känna empati med kundernas behov skapa en ljusare framtid med bättre verktyg som omdefinierar och leder marknaden.

Definiera antaganden för att bygga med kund empati

Att definiera antaganden är en grundläggande del av planeringen. Ju mer du planerar, desto tydligare kan du se dina antaganden krypa in i grunden för en bra idé. Antaganden är vanligtvis resultatet av själv empati. Med andra ord, vad skulle jag vilja om jag var i den här positionen? När du börjar med byggfasen minimeras den period då antaganden kan invadera en lösning. Den här metoden påskyndar också feedbackloopen med riktiga kunder, vilket utlöser tidigare möjligheter att lära sig och vässa empati.

De mest innovativa lösningarna i historien började med en intuitiv tro. Den magkänslan kommer från både befintlig expertis och förstahandsobservation. Börja med byggfasen eftersom det möjliggör ett snabbt test av din intuition. Därifrån kan du odla 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 visar kundernas empati.

För att stabilisera den här balansakten beskriver följande två avsnitt begreppen om hur du skapar med empati och definierar en MVP.

Definiera en kundfokuserad hypotes

När du bygger med empati innebär det att du skapar en lösning baserat på definierade hypoteser som illustrerar ett specifikt kundbehov. Följande steg formulerar en hypotes som uppmuntrar till att bygga med empati.

1. När du bygger med empati är kunden alltid i fokus. Den här avsikten kan ta många former. Du kan referera till en kunds arketyp, en specifik persona eller till och med en bild av en kund mitt i det problem som du vill lösa. Tänk på att kunderna kan vara interna (anställda eller partner) eller externa (konsumenter eller företagskunder). Den här definitionen är den första hypotesen som du kan testa: kan vi hjälpa den här specifika kunden?
2. Förstå kundupplevelsen. Att bygga 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 tydlig lösning på en enda utmaning. Om du förlitar dig på expertis mellan personer, processer och ämnesexperter kan det leda till en potentiell lösning. Den fullständiga hypotesen som ska testas är då: kan vi hjälpa den här specifika kunden med den här hanterbara utmaningen genom den föreslagna lösningen?
4. Anländer till en värdesats. Vilket långsiktigt värde hoppas du kunna 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 denna hanterbara utmaning?

Det här sista steget är kulmen på en kunds empatidrivna hypotes. Den definierar målgruppen, problemet, lösningen och måttet med vilket förbättring ska göras, som alla fokuserar på kunden. Under mått- och inlärningsfaserna bör du testa varje hypotes. Förutse förändringar i kunden, problembeskrivningen eller lösningen när teamet utvecklar större empati för den adresserbara kundbasen.

När du har bevisat de grundläggande antagandena fokuserar senare iterationer på tillväxttester utöver empatitester. När du har skapat, testat och validerat empati börjar du förstå den adresserbara marknaden i stor skala. Du kan djupare förstå din adresserbara marknad genom att utöka standardhypotesformeln som beskrevs tidigare. Baserat på tillgängliga data beräknar du sedan storleken på den totala marknaden (antalet potentiella kunder).

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

Definiera en lösning för att testa hypotesen

Under varje iteration av en build-measure-learn-feedbackloop definieras ditt försök att skapa med empati av en MVP.

En MVP är den minsta insatsenheten (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. Utdata är inte ett vackert program med alla funktioner som krävs för att förändra din bransch. Önskade utdata för varje iteration är en inlärningsmöjlighet, en chans att djupare testa en hypotes.

Tidsboxning är ett standardsätt för att se till att en produkt förblir mager. Kontrollera till exempel att utvecklingsteamet tror att lösningen kan skapas i en enda iteration för att möjliggöra snabb testning. Information om hur du använder hastighet, iterationer och versioner för att definiera vad som är minimalt finns i Planera hastighet, iterationer, versions- och iterationssökvägar.

Minska komplexiteten och fördröja tekniska toppar

De uppfinningsområden som beskrivs i innovationsmetoden utforskar de funktioner som ofta krävs för att leverera en mogen innovation eller skalklar MVP-lösning. Använd dessa områden som en långsiktig guide för funktionsinkludering. På samma sätt kan du använda dem som en varningsguide vid tidig testning av kundvärde och empati i din lösning.

Funktionsbredd och olika uppfinningsområden kan inte skapas i en enda iteration. Det kan krävas flera versioner för en MVP-lösning för att inkludera komplexiteten i flera discipliner. Beroende på investeringen i utveckling kan det finnas flera parallella team som arbetar inom olika discipliner för att testa flera hypoteser. Även om det är smart att upprätthålla arkitekturanpassningen mellan dessa team är det oklokning att försöka skapa komplexa, integrerade lösningar tills du kan verifiera värdehypoteserna.

Du identifierar komplexiteten bäst i frekvensen eller volymen av tekniska toppar. Tekniska toppar är arbete för att skapa tekniska lösningar som inte enkelt kan testas med kunder. När kundens värde och kundens empati är oprövade 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 hela implementeringen. Men de fördröjer testningen av hypoteser i innovationsinsatser och du bör skjuta upp dem när det är möjligt.

En obeveklig förenklingsmetod hjälper alla MVP-definitioner. Den här metoden innebär att du tar bort allt som inte hjälper 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 ta många olika former. Det gemensamma kravet är bara att utdata tillåter mätning och testning av hypotesen. Detta enkla krav initierar den vetenskapliga processen och låter teamet bygga med empati. För att leverera det här kundfokuset kan en första MVP bara förlita sig på ett av uppfinningsdisciplinerna.

I vissa fall innebär den snabbaste vägen till innovation att tillfälligt undvika dessa discipliner helt och hållet, tills teamet för molnimplementering är övertygade om att hypotesen är korrekt validerad. Från ett teknikföretag som Microsoft kan den här vägledningen låta kontraintuitiv. Men den betonar att kundernas behov, inte ett specifikt teknikbeslut, har högsta prioritet i en MVP-lösning.

Vanligtvis består en MVP-lösning av ett program eller en datalösning med minimala funktioner och begränsad polering. För organisationer som har expertkunskaper inom professionell utveckling är den här vägen ofta den snabbaste inom utbildning 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 mindre skalningsbehov.
• En manuell process som återskapar fördelarna med programmet som ska följas.
• En trådram eller video som är tillräckligt detaljerad för att kunden ska kunna interagera.

Utveckling av en MVP bör inte kräva enorma mängder utvecklingsinvesteringar. Helst begränsar du investeringar så mycket som möjligt för att minimera antalet hypoteser som testas samtidigt. Sedan, i varje iteration och med varje version, förbättrar du avsiktligt lösningen mot din skalklara lösning som representerar flera uppfinningsområden.

Påskynda MVP-utveckling

Tid till marknad är avgörande för att alla innovationer ska lyckas. Snabbare versioner leder till snabbare inlärning. Snabbare inlärning leder till produkter som kan skalas snabbare. Ibland kan traditionella programutvecklingscykler fördröja den här processen. Mer ofta begränsas innovationen av gränser för tillgänglig expertis. Budgetar, personalresurser och personaltillgänglighet kan alla skapa gränser för antalet nya innovationer som ett team kan hantera.

Personalbegränsningar och önskan att bygga med empati gav upphov till en snabbt växande trend mot medborgarutvecklare. Dessa utvecklare minskar risken och ger skalning inom en organisations community för professionell utveckling. Medborgarutvecklare är ämnesexperter i kundupplevelsen, men de är inte utbildade som ingenjörer. Dessa personer använder prototypverktyg eller utvecklingsverktyg med lägre vikt som kan rynka pannan hos professionella utvecklare. Dessa affärsjusterade utvecklare skapar MVP-lösningar och testteorier. När den här processen justeras väl skapar den produktionslösningar som ger värde men inte klarar en tillräckligt effektiv skalningshypotes. Teams kan också använda lösningarna för att verifiera en prototyp innan skalningsarbetet påbörjas.

I alla innovationsabonnemang bör molnimplementeringsteamen diversifiera sina portföljer så att de omfattar medborgarutvecklarinsatser. Genom att skala utvecklingsarbetet kan du skapa och testa fler hypoteser vid en minskad investering. När du validerar en hypotes och identifierar en adresserbar marknad kan professionella utvecklare sedan härda och skala lösningen med hjälp av moderna utvecklingsverktyg.

Slutlig bygggrind: Kundsmärta

När kundernas empati är stark bör ett tydligt befintligt problem vara lätt att identifiera. Kundens smärta bör vara uppenbar. Under bygget arbetar molnimplementeringsteamet med en lösning för att testa en hypotes baserat på en kunds smärtpunkt. Om hypotesen är väldefinierad men smärtpunkten inte är det, baseras lösningen inte riktigt på kundens empati. I det här scenariot är bygget inte rätt startpunkt. Investera istället först i att bygga empati och lära av verkliga kunder. Det bästa sättet att skapa empati och verifiera smärta är enkelt: lyssna på dina kunder. Investera tid i att träffa och observera dem tills du kan identifiera en smärtpunkt som inträffar ofta. När du väl förstår kundens smärtpunkt är du redo att testa en hypoteslösning för att åtgärda den smärtan.

När du inte ska tillämpa den här metoden

Det finns många juridiska krav, efterlevnadskrav och branschkrav som kan kräva en alternativ metod. Den här metoden kanske inte är lämplig om offentliga versioner av en utvecklingslösning:

• Skapa risk för patenttidsinställningar, immaterialrättsskydd eller läckage av kunddata
• Bryter mot etablerade efterlevnadskrav

När dessa upplevda risker finns bör du kontakta juridiska ombud innan du antar någon guidad metod för versionshantering.

Referenser

Några av begreppen i den här artikeln bygger på idéer som beskrivs i The Lean Startup 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 kundpåverkan.