Sestavování s empatií vůči zákazníkům

"Nutnost je matkou vynálezu." Toto rčení vystihuje nesmazatelnost lidského ducha a naši přirozenou tíhu vynalézat. Jak je vysvětleno v Oxford English Dictionary, "Když se potřeba něčeho stane imperativním, jste nuceni najít způsoby, jak toho dosáhnout nebo dosáhnout." Jen málo lidí by tyto univerzální pravdy o vynálezech popírají. Jak ale vysvětluje článek Inovace v digitální ekonomice , cloudové inovace vyžadují rovnováhu mezi vynálezem a osvojením.

Pokud budeme pokračovat v analogii, inovace pocházejí z širší rodiny. Empatie zákazníků je hrdým rodičem inovací. Vytvoření řešení pro empatii zákazníka, které je hnacím motorem inovací, vyžaduje legitimní potřebu zákazníka, která ho udržuje v návratu k řešení kritických výzev. Tato řešení jsou založená na tom, co zákazníci potřebují, a ne na potřebách nebo rozmarech. Pokud chcete najít skutečné potřeby zákazníků, začněte empatií a hlubokým porozuměním prostředí zákazníků. Empatie je nedostatečně vyvinutá dovednost pro mnoho techniků, produktových manažerů a dokonce i obchodních lídrů. Tuto dovednost naštěstí podporují různé interakce a rychlé tempo role cloudového architekta.

Jak vytvoříte empatii a proč je empatie zákazníků tak důležitá? Empatie zákazníka vám pomůže pochopit a sdílet zkušenosti zákazníka. Od prvního vydání minimálního životaschopného produktu (MVP) až po obecnou dostupnost řešení na tržní úrovni vám empatie zákazníků pomáhá vytvářet lepší řešení. Ještě důležitější je, že empatie lépe umístí tým k vymýšlení řešení, která podporují přijetí. V digitální ekonomice mohou produktové týmy, které se nejpohodlněji vcítit do potřeb zákazníků, vytvořit lepší budoucnost s lepšími nástroji, které předefinují a vedou trh.

Definování předpokladů pro vytváření s empatií zákazníka

Definování předpokladů je základní součástí plánování. Čím více plánujete, tím jasněji uvidíte, jak se vaše předpoklady vkrádají do základů skvělého nápadu. Předpoklady jsou obvykle produktem sebeempatie. Jinými slovy, co bych chtěl, kdybych byl v této pozici? Když začnete s fází sestavení, minimalizuje se doba, ve které mohou předpoklady napadnout řešení. Tento přístup také urychluje smyčku zpětné vazby u skutečných zákazníků, což aktivuje dřívější příležitosti k učení a zostření empatie.

Upozornění

Správné definování toho, co se má sestavit, může být složité a vyžaduje určitou praxi. Pokud vytváříte něco příliš rychle, nemusí to odrážet potřeby zákazníka. Pokud trávíte příliš mnoho času tím, že se snažíte porozumět počátečním potřebám zákazníků a požadavkům na řešení, může je trh splnit dřív, než budete mít možnost vůbec něco vytvořit. V obou scénářích může být možnost učit se výrazně zpožděna nebo omezena. Někdy můžou být data dokonce poškozena.

Nejinovativnější řešení v historii začala intuitivním přesvědčením. Tento pocit střev pochází z existujících odborných znalostí a pozorování z první ruky. Začněte fází sestavení, protože umožňuje rychle otestovat vaši intuici. Odtud můžete kultivovat hlubší porozumění a jasnější stupeň empatie. Při každé iteraci nebo vydání řešení vychází vyvážení z vytváření MVP, které demonstrují empatii zákazníků.

Následující dvě části popisují koncepty toho, jak vytvořit empatii a definovat MVP.

Definování hypotézy zaměřené na zákazníka

Když vytváříte s empatií, znamená to, že vytváříte řešení založené na definovaných hypotézách, které ilustrují konkrétní potřeby zákazníka. Následující kroky formulují hypotézu, která podporuje budování s empatií.

1. Když vytváříte s empatií, zaměřuje se vždy na zákazníka. Tento záměr může mít mnoho podob. Můžete odkazovat na archetyp zákazníka, konkrétní osobu nebo dokonce na obrázek zákazníka uprostřed problému, který chcete vyřešit. A mějte na paměti, že zákazníci mohou být interní (zaměstnanci nebo partneři) nebo externí (spotřebitelé nebo firemní zákazníci). Tato definice je první hypotézou, kterou otestujete: můžeme tomuto konkrétnímu zákazníkovi pomoct?
2. Seznamte se s prostředím pro zákazníky. Budování s empatií znamená, že se můžete spojit s zkušenostmi zákazníka a porozumět jeho výzvám. Tento způsob myšlení naznačuje další hypotézu, kterou je třeba otestovat: můžeme tomuto konkrétnímu zákazníkovi pomoct s tímto zvládnutelným problémem?
3. Definujte jasné řešení jednoho úkolu. Pokud se spoléháte na odborné znalosti lidí, procesů a odborníků na danou problematiku, může to vést k potenciálnímu řešení. Kompletní hypotéza, kterou je třeba testovat, je následující: Můžeme tomuto konkrétnímu zákazníkovi pomoct s tímto zvládnutelným problémem prostřednictvím navrhovaného řešení?
4. Zadejte příkaz value. Jakou dlouhodobou hodnotu chcete těmto zákazníkům poskytnout? Odpověď na tuto otázku vytvoří úplnou hypotézu: jak se zlepší životy těchto zákazníků pomocí navrhovaného řešení, které by vyřešilo tento zvládnutelný problém?

Tento poslední krok je vyvrcholením hypotézy založené na empatii zákazníka. Definuje cílovou skupinu, problém, řešení a metriku, pomocí které se má provést zlepšení, a to vše v centru zákazníka. Během fází měření a učení byste měli otestovat každou hypotézu. Předvídejte změny zákazníka, prohlášení o problému nebo řešení, protože tým bude rozvíjet větší empatii pro adresovatelnou zákaznickou základnu.

Upozornění

Cílem je stavět s empatií zákazníka, ne s tím plánovat . Je až příliš snadné uvíznout v nekonečných cyklech plánování a vylepšování, abyste dosáhli dokonalého prohlášení o empatii zákazníka. Než se pokusíte takový příkaz vyvinout, projděte si následující části věnované definování a sestavení MVP.

Jakmile prokážete základní předpoklady, pozdější iterace se kromě testů empatie zaměří také na testy růstu. Jakmile vytvoříte, otestujete a ověříte empatii, začnete rozumět adresovatelnému trhu ve velkém. Můžete hlouběji porozumět vašemu adresovatelnému trhu rozšířením standardního vzorce hypotézy popsaného výše. Na základě dostupných dat pak odhadněte velikost celkového trhu (počet potenciálních zákazníků).

Odsud odhadněte procento celkového trhu, který čelí podobné výzvě, a proto by se o řešení mohlo zajímat. Pak máte svůj adresovatelný trh. Další hypotézou, kterou je třeba otestovat, je: jak se x % života zákazníků zlepší použitím navrhovaného řešení, aby se tento zvládnutelný problém vyřešil? Malý vzorkování zákazníků odhalí úvodní indikátory, které naznačují procentuální vliv na fond zapojených zákazníků.

Definování řešení pro testování hypotézy

Během každé iterace smyčky zpětné vazby build-measure-learn je váš pokus o sestavení s empatií definován MVP.

MVP je nejmenší jednotka úsilí (vynález, inženýring, vývoj aplikací nebo datová architektura), která je potřebná k vytvoření dostatečného množství řešení pro učení se zákazníkem. Cílem každého MVP je otestovat některé nebo všechny předchozí hypotézy a získat zpětnou vazbu přímo od zákazníka. Výstupem není krásná aplikace se všemi funkcemi potřebnými ke změně vašeho odvětví. Požadovaným výstupem každé iterace je studijní příležitost, příležitost k hlubšímu testování hypotézy.

Timeboxing je standardní způsob, jak zajistit, aby produkt zůstal štíhlý. Ověřte například, že si váš vývojový tým myslí, že řešení je možné vytvořit v jediné iteraci, aby bylo možné rychle testovat. Pokud chcete lépe porozumět tomu, jak pomocí rychlosti, iterací a verzí definovat, co znamená minimum, přečtěte si téma Plánování rychlosti, iterací, vydání a iteračních cest.

Snížení složitosti a zpoždění technických špiček

Disciplíny vynálezu popsané v části Metodologie inovací zkoumají funkce, které se často vyžadují k poskytování vyspělých inovací nebo řešení MVP připraveného na škálování. Tyto disciplíny použijte jako dlouhodobého průvodce pro zahrnutí funkcí. Stejně tak je používejte jako opatrné vodítko při včasném testování hodnoty a empatie pro zákazníky ve vašem řešení.

Rozsah funkcí a různé disciplíny vynálezu nelze vytvořit v jediné iteraci. Řešení MVP může trvat několik verzí, aby zahrnovalo složitost více disciplín. V závislosti na investici do vývoje může existovat několik paralelních týmů pracujících v různých disciplínách, které testují více hypotéz. I když je inteligentní udržovat architekturu mezi těmito týmy, není moudré se pokoušet vytvářet komplexní integrovaná řešení, dokud nebudete moct ověřit hypotézy hodnoty.

Složitost zjistíte nejlépe v četnosti nebo objemu technických špiček. Technické špičky představují snahu o vytvoření technických řešení, která se nedají snadno testovat se zákazníky. Pokud hodnota a empatie zákazníka nejsou otestované, představují technické špičky riziko pro inovace a měly by se minimalizovat. U typů vyspělých testovaných řešení, která se vyskytují v rámci migrace, můžou být technické špičky běžné během celého přechodu. Ale oddalují testování hypotéz v inovačním úsilí a měli byste je odložit, kdykoli je to možné.

Všem definicím MVP pomáhá nelítostný přístup ke zjednodušení. Tento přístup znamená, že odeberete všechno, co vám nepomůže ověřit hypotézu. Pokud chcete minimalizovat složitost, snižte počet integrací a funkcí, které nejsou potřeba k testování hypotézy.

Sestavení MVP

Při každé iteraci může mít řešení MVP mnoho různých tvarů. Běžným požadavkem je pouze to, aby výstup umožňoval měření a testování hypotézy. Tento jednoduchý požadavek zahájí vědecký proces a umožní týmu vytvářet empatii. K zajištění tohoto zaměření na zákazníka může počáteční MVP spoléhat pouze na jednu z disciplín vynálezů.

V některých případech nejrychlejší cesta k inovacím znamená, že se těmto disciplínám dočasně zcela vyhnete, dokud tým přechodu na cloud nebude mít jistotu, že hypotéza bude přesně ověřena. Od technologické společnosti, jako je Microsoft, mohou tyto pokyny znít neintuitivně. Zdůrazňuje ale, že v řešení MVP jsou nejvyšší prioritou potřeby zákazníka, nikoli konkrétní rozhodnutí o technologii.

Řešení MVP se obvykle skládá z řešení aplikace nebo datového řešení s minimálními funkcemi a omezenými vylepšeními. Pro organizace, které mají odborné znalosti v oblasti profesního rozvoje, je tato cesta často nejrychlejší cestou k učení a iteraci. Následující seznam obsahuje několik dalších přístupů, které může tým použít k vytvoření MVP:

• Prediktivní algoritmus, který je v 99 % času chybný, ale ukazuje konkrétní požadované výsledky.
• Zařízení IoT, které nekomunikuje bezpečně v produkčním měřítku, ale demonstruje hodnotu dat téměř v reálném čase v rámci procesu.
• Aplikace vytvořená vývojářem pro občany, která testuje hypotézu nebo splňuje potřeby menšího rozsahu.
• Ruční proces, který znovu vytvoří výhody aplikace, kterou má následovat.
• Drátový model nebo video, které jsou dostatečně podrobné, aby umožnily interakci zákazníka.

Vývoj MVP by neměl vyžadovat obrovské investice do vývoje. Pokud možno co nejvíce omezíte investice, abyste minimalizovali počet hypotéz testovaných najednou. Pak v každé iteraci a s každou verzí záměrně vylepšíte řešení směrem k řešení připravenému na škálování, které představuje více disciplín vynálezů.

Zrychlení vývoje MVP

Doba uvedení na trh je pro úspěch všech inovací zásadní. Rychlejší verze vedou k rychlejšímu učení. Rychlejší učení vede k produktům, které se dají rychleji škálovat. Někdy můžou tento proces zpomalit tradiční vývojové cykly aplikací. Častěji jsou inovace omezeny omezeními dostupných odborných znalostí. Rozpočty, počet zaměstnanců a dostupnost zaměstnanců můžou vytvářet omezení počtu nových inovací, které tým dokáže zpracovat.

Personální omezení a touha stavět s empatií vytvořily rychle rostoucí trend směrem k občanským vývojářům. Tito vývojáři snižují riziko a poskytují měřítko v rámci komunity profesionálního rozvoje organizace. Vývojáři z občanů jsou odborníky na danou problematiku v prostředí zákazníků, ale nejsou vyškoleni jako inženýři. Tito jednotlivci používají nástroje pro vytváření prototypů nebo lehčí vývojové nástroje, na které by se profesionální vývojáři mohli zamračit. Tito podnikoví vývojáři vytvářejí řešení MVP a testují teorie. Pokud je tento proces správně sladěný, vytvoří produkční řešení, která poskytují hodnotu, ale neprojdou dostatečně efektivní hypotézou škálování. Týmy můžou také použít řešení k ověření prototypu před zahájením škálování.

V rámci jakéhokoli plánu inovací by týmy přechodu na cloud měly diverzifikovat svá portfolia tak, aby zahrnovaly úsilí vývojářů pro občany. Škálováním vývojového úsilí můžete vytvářet a testovat další hypotézy s nižšími investicemi. Když ověříte hypotézu a identifikujete adresovatelný trh, profesionální vývojáři pak můžou řešení posílit a škálovat pomocí moderních vývojových nástrojů.

Poslední brána sestavení: Bolest zákazníka

Pokud je empatie zákazníka silná, jasně existující problém by se měl snadno identifikovat. Bolest zákazníka by měla být zřejmá. Během sestavování tým přechodu na cloud pracuje na řešení, které otestuje hypotézu na základě bodu bolesti zákazníka. Pokud je hypotéza dobře definovaná, ale bolestný bod ne, řešení není ve skutečnosti založené na empatii zákazníka. V tomto scénáři není sestavení správným výchozím bodem. Místo toho nejprve investujte do budování empatie a učení od skutečných zákazníků. Nejlepší přístup k budování empatie a ověřování bolesti je jednoduchý: naslouchejte svým zákazníkům. Investujte čas do setkání s nimi a jejich pozorování, dokud nebudete moci identifikovat bod bolesti, který se vyskytuje často. Jakmile dobře porozumíte bodu bolesti zákazníka, jste připraveni otestovat hypotetické řešení pro řešení této bolesti.

Kdy tento přístup nepoužádáte

Existuje mnoho právních požadavků, požadavků na dodržování předpisů a odvětví, které mohou vyžadovat alternativní přístup. Tento přístup nemusí být vhodný, pokud veřejné verze vyvíjejícího se řešení:

• Vytvoření rizika pro načasování patentů, ochranu duševního vlastnictví nebo úniky zákaznických dat
• Porušení stanovených požadavků na dodržování předpisů

Pokud tato vnímaná rizika existují, obraťte se na právního poradce před přijetím jakéhokoli řízeného přístupu ke správě verzí.

Reference

Některé koncepty v tomto článku vycházejí z nápadů, které probíral The Lean Startup Eric Ries.

Další kroky

Po vytvoření řešení MVP můžete změřit hodnotu empatie a hodnotu škálování. Zjistěte, jak měřit dopad na zákazníky.

Měření dopadu na zákazníky