Bouwen met empathie van de klant

"Noodzaak is de moeder van de uitvinding." Dit gezegde legt de onuitbaarheid van de menselijke geest vast en onze natuurlijke drive om uit te vinden. Zoals uitgelegd in de Oxford English Dictionary, "Wanneer de noodzaak voor iets noodzakelijk wordt, ben je gedwongen om manieren te vinden om het te krijgen of te bereiken." Weinigen zouden deze universele waarheden over uitvindingen ontkennen. Zoals echter wordt uitgelegd in het artikel Innovatie in de digitale economie , vereist cloudinnovatie een balans tussen uitvinding en acceptatie.

Als we doorgaan met de analogie, komt innovatie voort uit een uitgebreidere familie. Inlevingsvermogen van klanten is de trotse ouder van innovatie. Voor het maken van een oplossing voor empathie van klanten, die innovatie stimuleert, is een legitieme klantbehoefte vereist die ervoor zorgt dat ze terugkomen om kritieke uitdagingen op te lossen. Deze oplossingen zijn gebaseerd op wat klanten nodig hebben in plaats van wensen of grillen. Om de werkelijke behoeften van klanten te vinden, begint u met empathie en een diep begrip van de klantervaring. Empathie is een onderontwikkelde vaardigheid voor veel technici, productmanagers en zelfs bedrijfsleiders. Gelukkig bevorderen de diverse interacties en het snelle tempo van de rol van cloudarchitect deze vaardigheid.

Hoe bouw je empathie op en waarom is empathie van klanten zo belangrijk? Empathie van de klant helpt u de ervaring van de klant te begrijpen en te delen. Vanaf de eerste release van een Minimum Viable Product (MVP) tot de algemene beschikbaarheid van een oplossing op marktniveau, helpt empathie van klanten u om betere oplossingen te bouwen. Belangrijker is dat empathie een team beter in staat stelt om oplossingen te bedenken die acceptatie stimuleren. In een digitale economie kunnen productteams die zich het gemakkelijkst kunnen inleven in de behoeften van klanten, een betere toekomst opbouwen met betere tools die de markt opnieuw definiëren en leiden.

Veronderstellingen definiëren om te bouwen met empathie van de klant

Het definiëren van veronderstellingen is een fundamenteel onderdeel van de planning. Hoe meer u plant, hoe duidelijker u uw veronderstellingen in de basis van een goed idee kunt zien kruipen. Veronderstellingen zijn meestal het product van zelf-empathie. Met andere woorden, wat zou ik willen als ik in deze positie was? Wanneer u begint met de buildfase, wordt de periode geminimaliseerd waarin veronderstellingen een oplossing kunnen binnendringen. Deze aanpak versnelt ook de feedbacklus met echte klanten, waardoor eerdere kansen om te leren en empathie te verscherpen worden geactiveerd.

Waarschuwing

Het correct definiëren van wat u wilt bouwen kan lastig zijn en vereist enige oefening. Als u iets te snel bouwt, komt dit mogelijk niet overeen met de behoeften van de klant. Als u te veel tijd besteedt aan het begrijpen van de eerste behoeften van klanten en oplossingsvereisten, kan de markt hieraan voldoen voordat u de kans hebt om iets te bouwen. In beide scenario's kan de mogelijkheid om te leren aanzienlijk worden vertraagd of verminderd. Soms kunnen de gegevens zelfs beschadigd raken.

De meest innovatieve oplossingen in de geschiedenis begonnen met een intuïtief geloof. Dat gevoel komt voort uit zowel bestaande expertise als eigen observatie. Begin met de bouwfase omdat het een snelle test van je intuïtie mogelijk maakt. Van daaruit kunt u dieper begrip en duidelijkere niveaus van empathie cultiveren. Bij elke iteratie of release van een oplossing is de balans het gevolg van het bouwen van MVP's die de empathie van de klant demonstreren.

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

Een klantgerichte hypothese definiëren

Wanneer u bouwt met empathie, betekent dit dat u een oplossing maakt op basis van gedefinieerde hypothesen die een specifieke klantbehoefte illustreren. In de volgende stappen wordt een hypothese geformuleerd die het opbouwen van empathie aanmoedigt.

1. Wanneer u bouwt met empathie, is de klant altijd de focus. Deze intentie kan vele vormen aannemen. U kunt verwijzen naar een klant archetype, een specifieke persona of zelfs een afbeelding van een klant te midden van het probleem dat u wilt oplossen. En houd er rekening mee dat klanten intern (werknemers of partners) of extern (consumenten of zakelijke klanten) kunnen zijn. Deze definitie is de eerste hypothese die u moet testen: 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 hun uitdagingen begrijpt. Deze mindset geeft de volgende hypothese aan die moet worden getest: kunnen we deze specifieke klant helpen met deze beheersbare uitdaging?
3. Definieer een duidelijke oplossing voor één uitdaging. Als u vertrouwt op expertise van mensen, processen en deskundigen, kan dit leiden tot een mogelijke oplossing. De volledige hypothese die moet worden getest is dan: kunnen we deze specifieke klant helpen met deze beheersbare uitdaging via de voorgestelde oplossing?
4. Kom tot een waarde-instructie. Welke waarde hoopt u deze klanten op de lange termijn te bieden? Het antwoord op deze vraag creëert uw volledige hypothese: hoe wordt het leven van deze klanten verbeterd door de voorgestelde oplossing te gebruiken om deze beheersbare uitdaging aan te pakken?

Deze laatste stap is het hoogtepunt van een klanthypothese die is gebaseerd op empathie. Het definieert de doelgroep, het probleem, de oplossing en de metrische waarde waarmee de verbetering moet worden aangebracht, die allemaal gericht zijn op de klant. Tijdens de meting- en leerfasen moet u elke hypothese testen. Anticipeer op wijzigingen in de klant, de probleemstelling of de oplossing naarmate het team meer empathie ontwikkelt voor het adresseerbare klantenbestand.

Waarschuwing

Het doel is om te bouwen met empathie van de klant, niet om ermee te plannen . Het is maar al te gemakkelijk om vast te lopen in eindeloze cycli van planning en aanpassingen om de perfecte empathieverklaring van de klant te bereiken. Voordat u een dergelijke instructie probeert te ontwikkelen, raadpleegt u de volgende secties over het definiëren en bouwen van een MVP.

Nadat u de kernveronderstellingen hebt bewezen, richten latere iteraties zich op groeitests naast empathietests. Nadat u empathie hebt gebouwd, getest en gevalideerd, begint u de adresseerbare markt op schaal te begrijpen. U kunt uw adresseerbare markt beter begrijpen door de eerder beschreven standaardhypotheseformule uit te breiden. Maak vervolgens een schatting van de totale markt (het aantal potentiële klanten) op basis van beschikbare gegevens.

Maak van daaruit een schatting van het percentage van de totale markt dat een vergelijkbare uitdaging ondervindt en daarom mogelijk geïnteresseerd is in de oplossing. U hebt dan uw adresseerbare markt. De volgende hypothese die moet worden getest, is: hoe wordt x% van het leven van klanten verbeterd door de voorgestelde oplossing te gebruiken om deze beheersbare uitdaging aan te pakken? Een kleine steekproef van klanten toont toonaangevende indicatoren die wijzen op een percentageeffect op de betrokken groep klanten.

Een oplossing definiëren om de hypothese te testen

Tijdens elke iteratie van een feedbacklus voor 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 genoeg 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 mooie toepassing met alle functies die nodig zijn om uw branche te veranderen. De gewenste uitvoer van elke iteratie is een leermogelijkheid, een kans om een hypothese dieper te testen.

Timeboxing is een standaardmethode om ervoor te zorgen dat een product mager blijft. Controleer bijvoorbeeld of uw ontwikkelteam denkt dat de oplossing in één iteratie kan worden gemaakt om snel testen mogelijk te maken. Zie Snelheid, iteraties, release- en iteratiepaden plannen voor meer inzicht in het gebruik van snelheid, iteraties en releases om te definiëren wat minimaal betekent.

Complexiteit verminderen en technische pieken vertragen

De disciplines van uitvindingen die worden beschreven in Innovatiemethodologie verkennen de functionaliteit die vaak nodig is om een volwassen innovatie- of schaalklare MVP-oplossing te leveren. Gebruik deze disciplines als een lange termijn richtlijn voor het opnemen van functies. Gebruik ze ook als waarschuwingsgids tijdens het vroege testen van klantwaarde 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 meerdere releases duren voordat een MVP-oplossing de complexiteit van meerdere disciplines bevat. Afhankelijk van de investering in ontwikkeling, kunnen er meerdere parallelle teams binnen verschillende disciplines werken om meerdere hypothesen te testen. Hoewel het slim is om architectuurafstemming tussen deze teams te behouden, is het onverstandig om te proberen complexe, geïntegreerde oplossingen te bouwen totdat u de waardehypotheses kunt valideren.

U detecteert complexiteit het beste in de frequentie of het volume van technische pieken. Technische pieken zijn inspanningen om technische oplossingen te maken die niet eenvoudig met klanten kunnen worden getest. Wanneer klantwaarde en empathie van de klant niet zijn getest, vormen technische pieken een risico voor innovatie en moeten ze worden geminimaliseerd. Voor de typen volwassen geteste oplossingen die in een migratie-inspanning worden gevonden, kunnen technische pieken vaak voorkomen tijdens de acceptatie. Maar ze vertragen het testen van hypothesen in innovatie-inspanningen en u moet deze waar mogelijk uitstellen.

Een meedozeloze vereenvoudigingsbenadering helpt elke MVP-definitie. Deze benadering betekent dat u alles verwijdert dat uw vermogen om de hypothese te valideren niet helpt. 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 aannemen. De algemene vereiste is alleen dat de uitvoer het mogelijk maakt om de hypothese te meten en te testen. Deze eenvoudige vereiste initieert het wetenschappelijke proces en laat het team bouwen met empathie. Om deze klantgerichte focus te leveren, kan een initiële MVP afhankelijk zijn van slechts één van de disciplines van uitvindingen.

In sommige gevallen betekent het snelste pad naar innovatie dat deze disciplines tijdelijk volledig worden vermeden, totdat het cloudacceptatieteam er zeker van is dat de hypothese correct is gevalideerd. Deze richtlijnen van een technologiebedrijf als Microsoft kunnen contra-intuïtief klinken. Maar het benadrukt dat de behoeften van de klant, niet een specifieke technologiebeslissing, de hoogste prioriteit hebben in een MVP-oplossing.

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

• Een voorspellend algoritme dat 99 procent van de tijd verkeerd is, maar dat specifieke gewenste resultaten laat zien.
• Een IoT-apparaat dat niet veilig communiceert op productieschaal, maar de waarde van bijna realtime gegevens binnen een proces laat zien.
• Een toepassing die is gebouwd door een burgerontwikkelaar om een hypothese te testen of te voldoen aan kleinere behoeften.
• Een handmatig proces waarmee de voordelen van de toepassing opnieuw worden gemaakt.
• Een draadmodel of video die gedetailleerd genoeg is om de klant te laten communiceren.

Voor het ontwikkelen van een MVP zijn geen enorme investeringen in ontwikkeling vereist. Bij voorkeur beperkt u de investering zoveel mogelijk om het aantal hypothesen dat in één keer wordt getest te minimaliseren. Vervolgens verbetert u in elke iteratie en bij elke release opzettelijk de oplossing die geschikt is voor schaalaanpassing die meerdere disciplines van uitvindingen vertegenwoordigt.

MVP-ontwikkeling versnellen

Time-to-market is cruciaal 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 ontwikkelingscycli van toepassingen dit proces vertragen. Innovatie wordt vaker beperkt door beperkingen van de beschikbare expertise. Budgetten, personeelsbestand en beschikbaarheid van personeel kunnen allemaal limieten creëren voor het aantal nieuwe innovaties dat een team kan verwerken.

Personeelsbeperkingen en de wens om met empathie te bouwen, hebben een snel groeiende trend naar citizen ontwikkelaars voortgebracht. Deze ontwikkelaars verminderen risico's en bieden schaalaanpassing binnen de professionele ontwikkelcommunity van een organisatie. Citizen-ontwikkelaars zijn experts op het gebied van de klantervaring, maar ze zijn niet opgeleid als engineers. Deze personen gebruiken prototyping-hulpprogramma's of lichtere ontwikkelhulpprogramma's die mogelijk worden afgekeurd door professionele ontwikkelaars. Deze op het bedrijf afgestemde ontwikkelaars maken MVP-oplossingen en testen theorieën. Wanneer dit proces goed is uitgelijnd, worden er productieoplossingen gemaakt die waarde bieden, maar die geen voldoende effectieve schaalhypothese doorgeven. Teams kan de oplossingen ook gebruiken om een prototype te valideren voordat de schaal wordt gestart.

Binnen elk innoverend plan moeten cloudacceptatieteams hun portfolio's diversifiëren om de inspanningen van burgerontwikkelaars op te nemen. Door ontwikkelingsinspanningen te schalen, kunt u meer hypothesen vormen en testen tegen een lagere investering. Wanneer u een hypothese valideert en een adresseerbare markt identificeert, kunnen professionele ontwikkelaars de oplossing vervolgens harden en schalen met behulp van moderne ontwikkelhulpprogramma's.

Definitieve bouwpoort: Klantpijn

Wanneer de empathie van de klant sterk is, moet een duidelijk bestaand probleem gemakkelijk te identificeren zijn. De pijn van de klant moet duidelijk zijn. Tijdens de build werkt het cloudacceptatieteam aan een oplossing om een hypothese te testen op basis van een pijnpunt van de klant. 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 build niet het juiste uitgangspunt. Investeer in plaats daarvan eerst in het opbouwen van empathie en leren van echte klanten. De beste aanpak voor het opbouwen van empathie en het valideren van pijn is eenvoudig: luister naar uw klanten. Investeer tijd in het vergaderen en observeren van hen totdat u een pijnpunt kunt identificeren dat vaak voorkomt. Nadat u het pijnpunt van de klant goed begrijpt, bent u klaar om een hypothesized oplossing te testen voor het aanpakken van die pijn.

Wanneer u deze benadering niet toepast

Er zijn veel juridische, nalevings- en branchevereisten die een alternatieve aanpak nodig kunnen hebben. Deze benadering is mogelijk niet geschikt als openbare releases van een ontwikkelende oplossing:

• Risico's creëren voor octrooitiming, bescherming van intellectueel eigendom of lekken van gegevens van klanten
• Vastgestelde nalevingsvereisten schenden

Wanneer deze waargenomen risico's bestaan, raadpleegt u de juridisch adviseur voordat u een begeleide benadering van releasebeheer aanneemt.

Referenties

Sommige concepten in dit artikel zijn gebaseerd op ideeën die door Eric Ries zijn The Lean Startup besproken.

Volgende stappen

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

Impact op de klant meten