Ügyfélempátián alapuló fejlesztés

"A szükségesség a találmány anyja." Ez a mondás rögzíti az emberi szellem letöríthetetlenségét és a természetes késztetésünket a feltalálásra. Ahogy az Oxford English Dictionaryben is olvasható, "Amikor valamire szükség van, kénytelen lesz megtalálni a módját annak elérésére vagy elérésére." Kevesen tagadnák ezeket az egyetemes igazságokat a találmányról. Ahogy azonban a digitális gazdaság innovációja című cikk ismerteti, a felhőinnovációnak egyensúlyra van szüksége a találmány és a bevezetés között.

Ha folytatjuk az analógiát, az innováció egy szélesebb körű családból származik. Az ügyfél-empátia az innováció büszke szülője. Az innovációt hajtó ügyfél-empátia-megoldás létrehozásához olyan jogos ügyféligényre van szükség, amely a kritikus kihívások megoldásához tartja őket vissza. Ezek a megoldások az ügyfelek igényein alapulnak ahelyett, hogy szeretnének vagy szeszélyesek. Az ügyfelek valódi igényeinek megtalálásához kezdje az empátiával és az ügyfélélmény alapos megértésével. Az empátia sok mérnök, termékmenedzser, sőt üzleti vezető fejletlen készsége. Szerencsére a felhőtervezői szerepkör változatos interakciói és gyors üteme elősegíti ezt a képességet.

Hogyan építhet empátiát, és miért olyan fontos az ügyfél-empátia? Az ügyfél-empátia segít megérteni és megosztani az ügyfél tapasztalatait. A minimálisan működőképes termék (MVP) első kiadásától a piaci szintű megoldások általános elérhetőségén át az ügyfél-empátiával jobb megoldásokat hozhat létre. Ennél is fontosabb, hogy az empátia jobb pozíciót ad a csapatnak, hogy olyan megoldásokat találjon ki, amelyek ösztönzik a bevezetést. A digitális gazdaságban azok a termékcsapatok, amelyek a legszerethetőbben tudnak együttérződni az ügyfelek igényeivel, egy szebb jövőt építhetnek ki jobb eszközökkel, amelyek újradefiniálja és vezetik a piacot.

Az ügyfelek empátiával építendő előfeltételeinek meghatározása

A feltételezések meghatározása a tervezés alapvető része. Minél többet tervezel, annál egyértelműbben láthatod, hogy a feltételezések egy nagyszerű ötlet alapjaiba csúsznak. A feltételezések általában az önempátia terméke. Más szóval , mit szeretnék, ha ebben a helyzetben lennék? Amikor a buildelési fázissal kezd, az minimalizálja azt az időszakot, amelyben a feltételezések behatolhatnak egy megoldásba. Ez a megközelítés a valós ügyfelekkel való visszajelzési ciklust is felgyorsítja, ami korábbi lehetőségeket teremt az empátia elsajátítására és élesítésére.

Figyelemfelhívás

A buildelés megfelelő meghatározása bonyolult lehet, és némi gyakorlást igényel. Ha túl gyorsan készít valamit, az nem feltétlenül tükrözi az ügyfél igényeit. Ha túl sok időt tölt azzal, hogy megpróbálja megérteni az ügyfelek kezdeti igényeit és a megoldási követelményeket, a piac megfelelhet nekik, mielőtt bármilyen elemet létrehozhatna. Mindkét esetben a tanulás lehetősége jelentősen késleltethető vagy csökkenthető. Előfordulhat, hogy az adatok megsérülhetnek.

A történelem leginnovatívabb megoldásai intuitív hittel kezdődtek. Ez a zsigeri érzés a meglévő szakértelemből és az első kézből származó megfigyelésből származik. Kezdje a buildelési fázissal, mert lehetővé teszi az intuíció gyors tesztelését. Innen mélyebb megértést és egyértelműbb empátiát fejleszthet. A megoldás minden iterációja vagy kiadása esetén az egyensúly az ügyfelek empátiát bemutató MVP-k készítéséből származik.

Ennek a kiegyensúlyozási műveletnek a kiegyensúlyozása érdekében az alábbi két szakasz ismerteti az empátia és az MVP meghatározásának fogalmait.

Ügyfélközpontú hipotézis definiálása

Ha empátiával épít, az azt jelenti, hogy meghatározott hipotézisek alapján hoz létre egy megoldást, amely egy adott ügyféligényt szemléltet. Az alábbi lépések olyan hipotézist fogalmaznak meg, amely empátiával ösztönzi az építést.

1. Amikor empátiával épít, mindig az ügyfél áll a középpontban. Ez a szándék számos alakzatot tartalmazhat. Hivatkozhat egy ügyfél archetípusára, egy adott személyre, vagy akár egy ügyfél képére a megoldani kívánt probléma közepén. És ne feledje, hogy az ügyfelek lehetnek belső (alkalmazottak vagy partnerek) vagy külső (fogyasztók vagy üzleti ügyfelek). Ez a definíció az első hipotézis, amelyet tesztelni kell: segíthetünk ennek az adott ügyfélnek?
2. Az ügyfélélmény megismerése. Az empátiával való építés azt jelenti, hogy kapcsolódhat az ügyfél tapasztalataihoz, és megértheti a kihívásokat. Ez a gondolkodásmód a következő tesztelendő hipotézist jelzi: segíthetünk ennek az ügyfélnek ebben a kezelhető kihívásban?
3. Egyértelmű megoldás definiálása egyetlen feladatra. Ha emberek, folyamatok és szakterületi szakértők szakértelmére támaszkodik, az potenciális megoldáshoz vezethet. A teljes tesztelni kívánt hipotézis a következő: segíthetünk ennek az adott ügyfélnek a javasolt megoldáson keresztül ezzel a kezelhető kihívással kapcsolatban?
4. Érkezzen meg egy értékutasításhoz. Milyen hosszú távú értéket szeretne biztosítani ezeknek az ügyfeleknek? A kérdésre adott válasz teljes hipotézist hoz létre: hogyan javítható ezeknek az ügyfeleknek az élete a javasolt megoldással ennek a kezelhető kihívásnak a megoldására?

Ez az utolsó lépés egy ügyfélempátia-vezérelt hipotézis csúcsa. Meghatározza a célközönséget, a problémát, a megoldást és azt a metrikát, amellyel a fejlesztést el kell végezni, és amely az ügyfél középpontja. A mérés és a tanulás fázisai során minden hipotézist tesztelnie kell. Előrejelezheti az ügyfél, a problémautasítás vagy a megoldás változásait, miközben a csapat nagyobb empátiát alakít ki a címezhető ügyfélkör számára.

Figyelemfelhívás

A cél az, hogy az ügyfél empátiával építsen , ne tervezze meg. Túl könnyű a végtelen tervezési és finomhangolási ciklusokban ragadni, hogy a tökéletes ügyfél-empátia-utasításra jusson. Mielőtt megpróbál egy ilyen utasítást fejleszteni, tekintse át az MVP definiálására és létrehozására vonatkozó alábbi szakaszokat.

Az alapvető feltételezések bizonyítása után a későbbi iterációk az empátiatesztek mellett a növekedési tesztekre összpontosítanak. Az empátia létrehozása, tesztelése és ellenőrzése után nagy léptékben kezdi megérteni a kezelhető piacot. A korábban ismertetett standard hipotézisképlet kibővítésével mélyebben megértheti a megcímezhető piacát. Ezután a rendelkezésre álló adatok alapján becsülje meg a teljes piac méretét (a potenciális ügyfelek számát).

Ebből becsülje meg a teljes piac azon százalékos arányát, amely hasonló kihívást jelent, és ezért érdekelheti a megoldást. Akkor a címezhető piaca van. A következő tesztelési hipotézis a következő: hogyan javítható az ügyfelek életének x%-a a javasolt megoldással ennek a kezelhető kihívásnak a megoldására? Az ügyfelek kis mintavételezése olyan vezető mutatókat mutat, amelyek százalékos hatást mutatnak a bevont ügyfelek készletére.

Megoldás definiálása a hipotézis teszteléséhez

A build-measure-learn visszajelzési ciklus minden iterációja során az empátia használatával történő létrehozási kísérletet egy MVP határozza meg.

Az MVP a legkisebb erőfeszítési egység (találmány, tervezés, alkalmazásfejlesztés vagy adatarchitektúra) ahhoz, hogy elegendő megoldást hozzon létre az ügyféllel való tanuláshoz. Minden MVP célja, hogy tesztelje a korábbi hipotézisek egy részét vagy mindegyikét, és közvetlenül az ügyféltől kapjon visszajelzést. A kimenet nem egy gyönyörű alkalmazás az iparág módosításához szükséges összes funkcióval. Az egyes iterációk kívánt kimenete egy tanulási lehetőség, a hipotézis mélyebb tesztelésének lehetősége.

A timeboxing egy szabványos módszer annak biztosítására, hogy a termék sovány maradjon. Győződjön meg például arról, hogy a fejlesztői csapat úgy gondolja, hogy a megoldás egyetlen iterációban hozható létre, hogy lehetővé tegye a gyors tesztelést. A sebesség, az iterációk és a kiadások használatának jobb megértéséhez tekintse meg a sebesség, az iterációk, a kiadási és az iterációs útvonalak tervezését ismertető cikket.

Az összetettség csökkentése és a műszaki csúcsok késleltetése

Az innováció módszertanában leírt találmányi szemléletek feltárják azokat a funkciókat, amelyek gyakran szükségesek egy érett innováció vagy méretre kész MVP-megoldás biztosításához. Ezeket a szemléleteket hosszú távú útmutatóként használhatja a funkcióbefoglaláshoz. Hasonlóképpen használja őket figyelmeztető útmutatóként az ügyfélérték és az empátia korai tesztelése során a megoldásban.

A jellemzők szélessége és a találmányok különböző tudományágai nem hozhatók létre egyetlen iterációban. Több kiadásra is szükség lehet egy MVP-megoldás esetében, hogy több tudományág összetettségét is magában foglalja. A fejlesztésbe való befektetéstől függően előfordulhat, hogy több párhuzamos csapat dolgozik különböző szakterületeken több hipotézis tesztelése érdekében. Bár intelligens fenntartani az architektúra-igazítást a csapatok között, nem célszerű összetett, integrált megoldásokat létrehozni, amíg nem tudja érvényesíteni az értékhipotéziseket.

A műszaki csúcsok gyakorisága vagy mennyisége alapján a legkomplexébb az összetettség. A technikai csúcsok olyan technikai megoldások létrehozására irányulnak, amelyek nem tesztelhetők könnyen az ügyfelekkel. Ha az ügyfélérték és az ügyfél-empátia nem tesztelt, a technikai kiugrások kockázatot jelentenek az innovációra, és minimalizálni kell őket. A migrálási erőfeszítésekben talált kiforrott, tesztelt megoldások típusai esetében a bevezetés során gyakoriak lehetnek a technikai kiugrások. De késleltetik a hipotézisek tesztelését az innovációs erőfeszítésekben, és ha lehetséges, el kell halasztani őket.

A könyörtelen egyszerűsítési megközelítés segít az MVP-definíciókban. Ez a megközelítés azt jelenti, hogy eltávolít mindent, ami nem segíti a hipotézis érvényesítését. Az összetettség minimalizálása érdekében csökkentse azoknak az integrációknak és szolgáltatásoknak a számát, amelyek nem szükségesek a hipotézis teszteléséhez.

MVP létrehozása

Az egyes iterációkban az MVP-megoldások számos különböző alakzatot tartalmazhatnak. A gyakori követelmény csak az, hogy a kimenet lehetővé teszi a hipotézis mérését és tesztelését. Ez az egyszerű követelmény elindítja a tudományos folyamatot, és lehetővé teszi, hogy a csapat empátiával építsen. Az ügyfélközpontúság biztosításához egy kezdeti MVP csak a találmányok egyik szemléletére támaszkodhat.

Bizonyos esetekben az innováció leggyorsabb útja azt jelenti, hogy ideiglenesen elkerüljük ezeket a tudományágakat, amíg a felhőbevezetési csapat nem biztos abban, hogy a hipotézis helyesen van érvényesítve. Egy olyan technológiai vállalattól, mint a Microsoft, ez az útmutató ellentétesnek tűnhet. Hangsúlyozza azonban, hogy az MVP-megoldásokban az ügyféligények, nem pedig egy adott technológiai döntés a legmagasabb prioritás.

Az MVP-megoldások jellemzően olyan alkalmazásból vagy adatmegoldásból áll, amely minimális funkciókkal rendelkezik, és korlátozott mértékben polírozható. A szakmai fejlesztési szakértelemmel rendelkező szervezetek számára gyakran ez az út a leggyorsabb a tanuláshoz és az iterációhoz. Az alábbi lista számos más módszert is tartalmaz, a csapat az MVP-k létrehozásához:

• Egy prediktív algoritmus, amely az idő 99%-ában hibás, de konkrét célokat mutat be.
• Olyan IoT-eszköz, amely nem kommunikál biztonságosan éles környezetben, de közel valós idejű adatok értékét mutatja be egy folyamaton belül.
• Egy civil fejlesztő által létrehozott alkalmazás, amely egy hipotézis tesztelésére vagy kisebb léptékű igények kielégítésére készült.
• Manuális folyamat, amely újra létrehozza az alkalmazás által követendő előnyöket.
• Olyan drótváz vagy videó, amely elég részletes ahhoz, hogy az ügyfél kommunikáljon.

Az MVP fejlesztése nem igényel nagy mennyiségű fejlesztési befektetést. Lehetőleg a lehető legnagyobb mértékben korlátozza a befektetést, hogy minimalizálja az egyszerre tesztelt hipotézisek számát. Ezután minden iterációban és minden kiadásban szándékosan fejleszti a megoldást a méretezésre kész megoldás felé, amely a találmányok több szemléletét képviseli.

MVP-fejlesztés felgyorsítása

A piacra jutás ideje elengedhetetlen az innováció sikeréhez. A gyorsabb kiadások gyorsabb tanuláshoz vezetnek. A gyorsabb tanulás olyan termékekhez vezet, amelyek gyorsabban méretezhetők. A hagyományos alkalmazásfejlesztési ciklusok időnként lelassíthatják ezt a folyamatot. Az innovációt gyakrabban korlátozzák a rendelkezésre álló szakértelem korlátai. A költségvetések, a létszám és a személyzet rendelkezésre állása korlátozhatja a csapat által kezelhető új innovációk számát.

A személyzetre vonatkozó korlátozások és az empátia kialakításának vágya gyorsan növekvő tendenciát mutatott a civil fejlesztők felé. Ezek a fejlesztők csökkentik a kockázatokat, és méretet biztosítanak a szervezet szakmai fejlesztői közösségén belül. A civil fejlesztők szakterületi szakértők az ügyfélélményben, de nem mérnökként képzettek. Ezek az egyének olyan prototípus-készítő eszközöket vagy kisebb súlyú fejlesztési eszközöket használnak, amelyeket a profi fejlesztők esetleg elkesenek. Ezek az üzleti szempontból igazított fejlesztők MVP-megoldásokat és tesztelméleteket hoznak létre. Ha jól van igazítva, ez a folyamat olyan éles megoldásokat hoz létre, amelyek értéket biztosítanak, de nem hatnak megfelelően hatékony skálázási hipotézisre. A csapatok a megoldásokkal is ellenőrizhetik a prototípust a skálázási erőfeszítések megkezdése előtt.

Minden újítási tervben a felhőbevezetési csapatoknak diverzifikálniuk kell portfólióikat, hogy magukban foglalják a polgárok fejlesztői erőfeszítéseit. A fejlesztési erőfeszítések skálázásával több hipotézist alakíthat ki és tesztelhet csökkentett befektetéssel. A hipotézis érvényesítésekor és a kezelhető piac azonosításakor a professzionális fejlesztők modern fejlesztői eszközökkel megerősíthetik és skálázhatják a megoldást.

Végső build kapu: Ügyfél fájdalom

Ha az ügyfél-empátia erős, egy egyértelműen meglévő probléma könnyen azonosítható. Az ügyfél fájdalmának nyilvánvalónak kell lennie. A buildelés során a felhőbevezetési csapat egy olyan megoldáson dolgozik, amely egy ügyfél fájdalompontja alapján tesztel egy hipotézist. Ha a hipotézis jól definiált, de a fájdalompont nem, a megoldás nem igazán az ügyfelek empátiáján alapul. Ebben a forgatókönyvben a buildelés nem a megfelelő kiindulási pont. Ehelyett inkább az empátia kiépítésébe és a valódi ügyfelektől való tanulásba fektet be. Az empátia kiépítéséhez és a fájdalom érvényesítéséhez a legjobb módszer az egyszerűség: hallgassa meg ügyfeleit. Szánjon időt az értekezletre, és megfigyelje őket, amíg meg nem találja a gyakran előforduló fájdalompontot. Miután megismerte az ügyfél fájdalom pontját, készen áll arra, hogy teszteljen egy hipotezizált megoldást a fájdalom kezelésére.

Mikor ne alkalmazza ezt a megközelítést?

Számos olyan jogi, megfelelőségi és iparági követelmény létezik, amely szükségessé teheti egy másik megközelítés kialakítását. Ez a megközelítés nem feltétlenül megfelelő, ha egy fejlődő megoldás nyilvános kiadása:

• A szabadalmak időzítésére, a szellemi tulajdon védelmére vagy az ügyfelek adatszivárgására vonatkozó kockázat létrehozása
• A megállapított megfelelőségi követelmények megsértése

Ha ezek a vélt kockázatok fennállnak, konzultáljon a jogi tanácsadóval, mielőtt bármilyen irányított megközelítést alkalmaz a kiadáskezeléshez.

Hivatkozások

A cikkben szereplő fogalmak némelyike Eric Ries által tárgyalt The Lean Startup ötletekre épül.

Következő lépések

Az MVP-megoldás létrehozása után mérheti az empátia értékét és a skálázási értéket. Megtudhatja, hogyan mérheti meg az ügyfelek hatását.

Ügyfélhatás mérése