Bouwen met empathie van de klant

'Noodzaak is de moeder van uitvinding'. Dit gezegde legt de onuitwisbaarheid van de menselijke wijs en onze natuurlijke drive om uit te vinden vast. Zoals uitgelegd in de Engelse woordenlijst van Oxford, 'Wanneer de behoefte aan iets noodzakelijk wordt, bent u gedwongen om manieren te vinden om deze te verkrijgen of te bereiken.' Weinigen zouden deze universele waarheden over uitvindingen weigeren. Zoals beschreven in Innovatie in de digitale economie,vereist cloudinnovatie echter een evenwicht tussen uitvindingen en acceptatie.

Als we verdergaan met de analogie, is innovatie afkomstig van een uitgebreidere familie. Empathie van klanten is het bovenliggende bovenliggende deel van innovatie. Voor het creëren van een empathieoplossing voor klanten die innovatie aandijt, is een legitieme klant nodig die ervoor zorgt dat de klant terugkomt om kritieke uitdagingen op te lossen. Deze oplossingen zijn gebaseerd op wat een klant nodig heeft in plaats van op hun wensen of whims. Om hun werkelijke behoeften te vinden, beginnen we met empathie, een diepgaand begrip van de ervaring van de klant. Empathie is een onderontwikkelde vaardigheid voor veel technici, productmanagers en zelfs zakelijke leiders. Gelukkig zijn de diverse interacties en het snelle tempo van de rol cloudarchitect al begonnen met het bevorderen van deze vaardigheid.

Hoe bouwen we empathie op en waarom is empathie van klanten zo belangrijk? Empathie van klanten helpt ons inzicht te krijgen in en te delen in de ervaring van de klant. Vanaf de eerste release van een MVP (Minimum Viable Product) tot de algemene beschikbaarheid van een oplossing op marktkwaliteit, helpt empathie van klanten ons bij het bouwen van een betere oplossing. Belangrijker is dat het ons beter in staat maakt oplossingen te bedenken die acceptatie stimuleren. In een digitale economie kunnen degenen die zich het gemakkelijkst kunnen inleven in de behoeften van de klant, een toekomst bouwen die de markt opnieuw moet definiëren en de leiding neemt.

Bouwen met empathie van klanten

Het definiëren van veronderstellingen is een fundamenteel onderdeel van de planning. Hoe meer we plannen, hoe meer we veronderstellingen zien die de basis vormen van een goed idee. Veronderstellingen zijn doorgaans het product van zelf-empathie. Met andere woorden, wat zou ik willen als ik deze positie zou hebben? Beginnend met de build-fase wordt de periode geminimaliseerd waarin veronderstellingen een oplossing kunnen bebouwen. Deze aanpak versnelt ook de feedbacklus met echte klanten, wat eerder mogelijkheden activeert om te leren en empathie te verbeteren.

De meest innovatieve oplossingen in de geschiedenis begonnen met een intuïtieve mening. Dat onderbuikvermogen is afkomstig van zowel bestaande expertise als waarneming uit de eerste hand. We beginnen met de buildfase, omdat deze een snelle test van die onderbouwing mogelijk maakt. Van hier uit kunnen we meer begrip en duidelijkere mate van empathie ontwikkelen. Bij elke iteratie of release van een oplossing is het evenwicht afkomstig van het bouwen van MSP's die empathie van klanten demonstreren.

Om deze taakverdeling stabiel te houden, worden in de volgende twee secties de concepten besproken van het bouwen met empathie en het definiëren van een MVP.

Een klantgerichte hypothese definiëren

Bouwen met empathie betekent het maken van een oplossing op basis van gedefinieerde hypothesen die de behoeften van een specifieke klant illustreren. De volgende stappen zijn erop gericht om een hypothese te formuleren die het bouwen met empathie zal stimuleren.

1. Wanneer u met empathie bouwt, is de klant altijd de focus. Deze intentie kan veel vormen aannemen. U kunt verwijzen naar een klant-archetype, een specifieke persona of zelfs een afbeelding van een klant in het midden van het probleem dat u wilt oplossen. En houd er rekening mee dat klanten interne klanten (werknemers of partners) of externe klanten (consumenten of zakelijke klanten) kunnen zijn. Deze definitie is de eerste hypothese die moet worden getest: kunnen we deze specifieke klant helpen?
2. Inzicht in de klantervaring. Bouwen met empathie betekent dat u zich kunt verhouden tot de ervaring van de klant en inzicht kunt krijgen in hun uitdagingen. Deze instelling geeft de volgende hypothese aan die moet worden getest: kunnen we deze specifieke klant helpen met deze beheerbare uitdaging?
3. Definieer een eenvoudige oplossing voor één uitdaging. Vertrouwen op expertise tussen mensen, processen en deskundigen leidt tot een mogelijke oplossing. Dit is de volledige hypothese die moet worden getest: kunnen we deze specifieke klant helpen met deze beheersbare uitdaging via de voorgestelde oplossing?
4. Kom aan bij een waarde-instructie. Welke langetermijnwaarde wilt u deze klanten bieden? Het antwoord op deze vraag creëert uw volledige hypothese: hoe worden de levens van deze klanten verbeterd door de voorgestelde oplossing te gebruiken om deze beheerbare uitdaging aan te pakken?

Deze laatste stap is de uiting van een door empathie gestuurde hypothese van klanten. Het definieert de doelgroep, het probleem, de oplossing en de metrische gegevens waarmee verbetering moet worden aangebracht, die allemaal gericht zijn op de klant. Tijdens de fasen meten en leren moet elke hypothese worden getest. Wijzigingen in de klant, probleemverklaring of oplossing worden verwacht wanneer het team meer empathie ontwikkelt voor het adresseerbare klantenbestand.

Nadat de kernveronderstellingen zijn bewezen, richten latere iteraties zich op groeitests naast empathietests. Nadat empathie is gebouwd, getest en gevalideerd, kunt u inzicht krijgen in de adresseerbare markt op schaal. Dit kan worden gedaan door een uitbreiding van de standaardhypotheseformule die eerder is beschreven. Op basis van beschikbare gegevens kunt u een schatting maken van de grootte van de totale markt (het aantal potentiële klanten).

Van hier uit kunt u een schatting maken van het percentage van die totale markt dat een vergelijkbare uitdaging ervaart en die daarom mogelijk geïnteresseerd is in deze oplossing. Dit is uw adresseerbare markt. De volgende hypothese die moet worden getest, is: hoe wordt x% van de levens van klanten verbeterd door de voorgestelde oplossing te gebruiken om deze beheerbare uitdaging aan te pakken? Een kleine steekproef van klanten toont toonaangevende indicatoren die een percentage impact op de betrokken groep klanten voorstellen.

Een oplossing definiëren om de hypothese te testen

Tijdens elke herhaling van een feedbacklus bouwen-meten-leren wordt uw poging om met empathie te bouwen gedefinieerd door een MVP.

Een MVP is de kleinste inspanningseenheid (uitvinding, engineering, toepassingsontwikkeling of gegevensarchitectuur) die nodig is om voldoende van een oplossing te maken om met de klant te leren. Het doel van elke MVP is om enkele of alle eerdere hypothesen te testen en rechtstreeks feedback van de klant te ontvangen. De uitvoer is geen prachtige toepassing met alle functies die nodig zijn om uw branche te wijzigen. De gewenste uitvoer van elke iteratie is een leerkans, een kans om een hypothese dieper te testen.

Timeboxing is een standaard manier om ervoor te zorgen dat een product mager blijft. Zorg er bijvoorbeeld voor dat uw ontwikkelteam denkt dat de oplossing kan worden gemaakt in één iteratie om snelle tests mogelijk te maken. Zie Planningssnelheid, iteraties, release- en iteratiepadenvoor een beter begrip van het gebruik van snelheid, iteraties en releases om te definiëren wat minimaal betekent.

De complexiteit verminderen en technische pieken vertragen

De disciplines van uitvindingen die zijn gevonden in de Innoverende methodologie beschrijven de functionaliteit die vaak nodig is om een goed ontwikkelde innovatie of schaalgeschaalde MVP-oplossing te leveren. Gebruik deze disciplines als een langetermijnhandleiding voor het opnemen van functies. Gebruik ze ook als een waarschuwingsgids tijdens het vroeg testen van de waarde van de klant en empathie in uw oplossing.

De breedte van functies en de verschillende disciplines van uitvindingen kunnen niet allemaal in één iteratie worden gemaakt. Het kan enkele releases duren voor een MVP-oplossing de complexiteit van meerdere disciplines omvat. Afhankelijk van de investering in ontwikkeling, zijn er mogelijk meerdere parallelle teams die binnen verschillende disciplines werken om meerdere hypothesen te testen. Hoewel het slim is om de architectuur uit te lijnen tussen deze teams, is het niet verstandig om complexe, geïntegreerde oplossingen te bouwen totdat de waardehythesen kunnen worden gevalideerd.

Complexiteit wordt het best gedetecteerd in de frequentie of het volume van technische pieken. Technische pieken zijn pogingen om technische oplossingen te maken die niet eenvoudig kunnen worden getest met klanten. Wanneer klantwaarde en empathie van klanten niet worden getest, vormen technische pieken een risico voor innovatie en moeten ze worden geminimaliseerd. Voor de typen volwassen geteste oplossingen die tijdens een migratie zijn gevonden, kunnen tijdens de migratie algemene technische pieken voorkomen. Ze vertragen echter het testen van hypothesen in innovatie-inspanningen en moeten waar mogelijk worden uitgesteld.

Voor elke MVP-definitie wordt een vereenvoudigingsbenadering voorgesteld. Deze aanpak betekent dat u alles verwijdert dat niet bijvoegt in uw mogelijkheid om de hypothese te valideren. Om de complexiteit te minimaliseren, vermindert u het aantal integraties en functies dat niet nodig is om de hypothese te testen.

Een MVP bouwen

Bij elke iteratie kan een MVP-oplossing veel verschillende vormen hebben. De algemene vereiste is alleen dat de uitvoer het meten en testen van de hypothese toestaat. Deze eenvoudige vereiste initieert het wetenschappelijke proces en stelt het team in staat om met empathie te bouwen. Om deze klantgerichte focus te bieden, is een initiële MVP mogelijk afhankelijk van slechts een van de disciplines van uitvindingen.

In sommige gevallen betekent het snelste pad naar innovatie dat deze disciplines tijdelijk volledig worden vermeden, totdat het cloud adoption-team er zeker van is dat de hypothese nauwkeurig is gevalideerd. Deze richtlijnen zijn afkomstig van een technologiebedrijf als Microsoft en zijn misschien niet zo intuïtief. Dit benadrukt echter gewoon dat de behoeften van de klant, niet een specifieke technologische beslissing, de hoogste prioriteit hebben in een MVP-oplossing.

Normaal gesproken bestaat een MVP-oplossing uit een eenvoudige toepassing of gegevensoplossing met minimale functies en beperkte pools. Voor organisaties die professionele ontwikkelingsexpertise hebben, is dit traject vaak de snelste om te leren en te itereren. De volgende lijst bevat verschillende andere methoden die een team kan volgen om een MVP te bouwen:

• Een voorspellend algoritme dat 99 procent van de tijd verkeerd is, maar dat specifieke gewenste resultaten demonstreert.
• Een IoT-apparaat dat niet veilig communiceert op productieschaal, maar dat de waarde van bijna realtime gegevens binnen een proces laat zien.
• Een toepassing die is gebouwd door citizen developer om een hypothese te testen of te voldoen aan behoeften op kleinere schaal.
• Een handmatig proces dat de voordelen van de toepassing opnieuw maakt.
• Een wireframe of video die gedetailleerd genoeg is om de klant in staat te stellen te communiceren.

Voor het ontwikkelen van een MVP hoeven geen grote hoeveelheden ontwikkelingsinvesteringen te worden geïnvesteerd. Bij voorkeur moet de investering zo beperkt mogelijk zijn om het aantal hypothesen dat tegelijk wordt getest te minimaliseren. Vervolgens wordt bij elke iteratie en bij elke release de oplossing opzettelijk verbeterd naar een oplossing die gereed is voor schaal die meerdere disciplines van uitvindingen vertegenwoordigt.

MVP-ontwikkeling versnellen

Time-to-market is van cruciaal belang voor het succes van elke innovatie. Snellere releases leiden tot sneller leren. Sneller leren leidt tot producten die sneller kunnen worden geschaald. Soms kunnen traditionele cycli voor toepassingsontwikkeling dit proces vertragen. Innovatie wordt vaker beperkt door beperkingen van de beschikbare expertise. Budgetten, personeelsaantal en beschikbaarheid van personeel kunnen allemaal limieten instellen voor het aantal nieuwe innovaties dat een team kan verwerken.

Personeelsbeperkingen en de wens om mee te bouwen met empathie hebben geleid tot een snel groeiende trend naar burgerontwikkelaars. Deze ontwikkelaars verminderen risico's en bieden schaal binnen de professionele ontwikkelingswereld van een organisatie. Burgerontwikkelaars zijn deskundigen op het gebied van de klantervaring, maar ze zijn niet getraind als engineers. Deze personen gebruiken prototypehulpprogramma's of lichtere ontwikkelhulpprogramma's die mogelijk worden bejegend door professionele ontwikkelaars. Deze bedrijfsontwikkelaars maken MVP-oplossingen en testen theorieën. Wanneer dit proces goed is uitgelijnd, kan dit productieoplossingen maken die waarde bieden, maar geen voldoende efficiënte schaalhypothese doorgeven. Ze kunnen ook worden gebruikt om een prototype te valideren voordat de schaal wordt ingezet.

Binnen elk innoverend plan moeten cloud adoption-teams hun portfolio's aan elkaar toe te voegen citizen developer inspanningen. Door de ontwikkelingsinspanningen te schalen, kunnen er meer hypothesen worden gevormd en getest tegen een gereduceerde investering. Wanneer een hypothese wordt gevalideerd en er een adresseerbare markt wordt geïdentificeerd, kunnen professionele ontwikkelaars de oplossing schalen en schalen met moderne ontwikkelhulpprogramma's.

Laatste build-gate: klantervaring

Wanneer de empathie van klanten sterk is, moet een duidelijk bestaand probleem gemakkelijk te identificeren zijn. De pijn van de klant moet duidelijk zijn. Tijdens het bouwen bouwt het cloud adoption-team een oplossing om een hypothese te testen op basis van een klantklant. Als de hypothese goed is gedefinieerd, maar het pijnpunt niet, is de oplossing niet echt gebaseerd op empathie van de klant. In dit scenario is bouwen niet het juiste beginpunt. In plaats daarvan investeert u eerst in het opbouwen van empathie en het leren van echte klanten. De beste aanpak voor het opbouwen van empathie en validatie van pijn is eenvoudig: luister naar uw klanten. Investeer tijd in het vergaderen met en het observeren ervan totdat u een probleempunt kunt identificeren dat regelmatig optreedt. Nadat het pijnpunt goed is begrepen, bent u klaar om een veronderstelde oplossing te testen voor het aanpakken van die pijn.

Wanneer u deze methode niet wilt toepassen

Er zijn veel wettelijke, nalevings- en branchevereisten die mogelijk een alternatieve benadering vereisen. Als openbare releases van een ontwikkeloplossing risico's met zich mee brengen voor timing van patenten, bescherming van intellectueel eigendom, lekken van klantgegevens of schending van vastgestelde nalevingsvereisten, is deze aanpak mogelijk niet geschikt. Als dergelijke risico's zich voordeden, raadpleegt u juridische adviseurs voordat u een begeleide benadering voor releasebeheer in gebruik neemt.

Referenties

Enkele van de concepten in dit artikel zijn gebaseerd op onderwerpen die worden besproken door The Lean Startup Eric Ries.

Volgende stappen

Nadat u een MVP-oplossing hebt gebouwd, kunt u de empathiewaarde en schaalwaarde meten. Meer informatie over het meten van de impact van de klant.