Tworzenie z empatią wobec klientów

"Konieczność jest matką wynalazku"." To powiedzenie przechwytuje niedelegowalność ludzkiego ducha i naszego naturalnego dążenia do wymyślania. Jak wyjaśniono w Oxford English Dictionary, "Kiedy potrzeba czegoś staje się imperatywne, jesteś zmuszony do znalezienia sposobów uzyskania lub osiągnięcia go." Niewielu zaprzeczyłoby tym uniwersalnym prawdom o wynalazku. Jednak jak wyjaśniono w artykule Innowacje w gospodarce cyfrowej , innowacje w chmurze wymagają równowagi między wynalazkiem a wdrożeniem.

Jeśli będziemy kontynuować analogię, innowacje pochodzą z bardziej rozszerzonej rodziny. Empatia klienta jest dumnym rodzicem innowacji. Aby utworzyć rozwiązanie empatii klienta, które napędza innowacje, wymaga uzasadnionej potrzeby klienta, która pozwala im wrócić do rozwiązywania krytycznych wyzwań. Te rozwiązania są oparte na tym, czego potrzebują klienci, a nie chcą lub kaprysów. Aby znaleźć prawdziwe potrzeby klientów, zacznij od empatii i głębokiego zrozumienia środowiska klienta. Empatia jest niedopracowaną umiejętnością dla wielu inżynierów, menedżerów produktów, a nawet liderów biznesowych. Na szczęście zróżnicowane interakcje i szybkie tempo roli architekta chmury wspierają tę umiejętność.

Jak zbudować empatię i dlaczego empatia klienta jest tak ważna? Empatia klienta pomaga zrozumieć i podzielić się doświadczeniem klienta. Od pierwszej wersji minimalnej opłacalnej wersji produktu (MVP) po ogólną dostępność rozwiązania klasy rynkowej empatia klienta pomaga tworzyć lepsze rozwiązania. Co ważniejsze, empatia lepiej pozycje zespołu w celu wymyślania rozwiązań, które zachęcają do wdrażania. W gospodarce cyfrowej zespoły produktów, które mogą najbardziej łatwo empatyzować się z potrzebami klientów, mogą stworzyć jaśniejszą przyszłość z lepszymi narzędziami, które definiują i prowadzą rynek.

Definiowanie założeń do tworzenia za pomocą empatii klienta

Definiowanie założeń jest podstawową częścią planowania. Im więcej planujesz, tym wyraźniej można zobaczyć swoje założenia pełzające w fundament wspaniałego pomysłu. Założenia są zazwyczaj produktem samozaczętości. Innymi słowy, czego chciałbym, gdybym był w tej pozycji? Po rozpoczęciu fazy kompilacji minimalizuje okres, w którym założenia mogą zaatakować rozwiązanie. Takie podejście przyspiesza również pętlę opinii z rzeczywistymi klientami, wyzwalając wcześniejsze możliwości uczenia się i wyostrzania empatii.

Przestroga

Prawidłowe zdefiniowanie tego, co należy utworzyć, może być trudne i wymaga pewnej praktyki. Jeśli utworzysz coś zbyt szybko, może to nie odzwierciedlać potrzeb klientów. Jeśli spędzisz zbyt dużo czasu, próbując zrozumieć początkowe potrzeby klientów i wymagania dotyczące rozwiązań, rynek może je spełnić, zanim masz szansę zbudować wszystko w ogóle. W obu scenariuszach możliwość nauki może być znacznie opóźniona lub ograniczona. Czasami dane mogą być nawet uszkodzone.

Najbardziej innowacyjne rozwiązania w historii zaczęły się intuicyjnie przekonać. To uczucie jelita pochodzi zarówno z istniejącej wiedzy, jak i obserwacji pierwszej ręki. Zacznij od fazy kompilacji, ponieważ pozwala na szybki test intuicji. Stamtąd możesz pielęgnować głębsze zrozumienie i jaśniejsze stopnie empatii. W każdej iteracji lub wydaniu rozwiązania równowaga pochodzi od tworzenia dostawców aplikacji, które pokazują empatię klienta.

Aby ustabilizować ten akt równoważenia, w poniższych dwóch sekcjach opisano koncepcje tworzenia z empatią i definiowania MVP.

Definiowanie hipotezy ukierunkowanej na klienta

Podczas tworzenia z empatią oznacza to utworzenie rozwiązania opartego na zdefiniowanych hipotezach, które ilustrują konkretną potrzebę klienta. Poniższe kroki sformułują hipotezę, która zachęca do budowania empatii.

1. Gdy budować z empatią, klient jest zawsze głównym celem. Ta intencja może przyjmować wiele kształtów. Możesz odwoływać się do archetypu klienta, określonej osoby, a nawet obrazu klienta w środku problemu, który chcesz rozwiązać. Należy pamiętać, że klienci mogą być wewnętrzni (pracownicy lub partnerzy) lub zewnętrzni (konsumenci lub klienci biznesowi). Ta definicja jest pierwszą hipotezą do przetestowania: czy możemy pomóc temu konkretnemu klientowi?
2. Poznaj środowisko klienta. Budowanie z empatią oznacza, że możesz powiązać się z doświadczeniem klienta i zrozumieć swoje wyzwania. Ten sposób myślenia wskazuje kolejną hipotezę do przetestowania: czy możemy pomóc temu konkretnemu klientowi w tym zarządzanym wyzwaniu?
3. Zdefiniuj jasne rozwiązanie dla pojedynczego wyzwania. Jeśli polegasz na wiedzy ekspertów, procesów i zagadnień, może to prowadzić do potencjalnego rozwiązania. Pełną hipotezę, którą należy przetestować, jest wtedy: czy możemy pomóc temu konkretnemu klientowi w rozwiązaniu, które można zarządzać za pomocą proponowanego rozwiązania?
4. Dojeżdżaj do instrukcji value. Jaka długoterminowa wartość ma być dostarczana tym klientom? Odpowiedź na to pytanie tworzy pełną hipotezę: jak życie tych klientów zostanie ulepszone przy użyciu proponowanego rozwiązania w celu rozwiązania tego możliwego do zarządzania wyzwaniem?

Ostatnim krokiem jest kulminacja hipotezy opartej na empatii klienta. Definiuje odbiorców, problem, rozwiązanie i metryki, według których należy wprowadzić ulepszenia, wszystkie centrum klienta. W fazach miary i uczenia się należy przetestować każdą hipotezę. Przewidywanie zmian w kliencie, oświadczeniu o problemie lub rozwiązaniu, ponieważ zespół rozwija większą empatię dla możliwej do rozwiązania bazy klientów.

Przestroga

Celem jest budowanie z empatią klienta, a nie planowanie z nim. To wszystko zbyt łatwe, aby utknąć w niekończących się cyklach planowania i dostosowywania, aby trafić na idealne oświadczenie empatii klienta. Przed podjęciem próby opracowania takiej instrukcji zapoznaj się z poniższymi sekcjami na temat definiowania i tworzenia MVP.

Po udowodnieniu podstawowych założeń iteracji skupić się na testach wzrostu oprócz testów empatii. Po utworzeniu, przetestowaniu i zweryfikowaniu empatii zaczniesz rozumieć adresowalny rynek na dużą skalę. Możesz dokładniej zrozumieć swój adresowalny rynek, rozszerzając wcześniej opisaną formułę hipotezy standardowej. Następnie, na podstawie dostępnych danych, szacuj rozmiar całkowitego rynku (liczbę potencjalnych klientów).

W tym miejscu należy oszacować procent całkowitego rynku, który doświadcza podobnego wyzwania i dlatego może być zainteresowany rozwiązaniem. Następnie masz swój adresowalny rynek. Następna hipoteza do przetestowania polega na tym, jak x% życia klientów zostanie ulepszone przy użyciu proponowanego rozwiązania w celu rozwiązania tego możliwego do zarządzania wyzwaniem? Małe próbkowanie klientów ujawnia wiodące wskaźniki, które sugerują procentowy wpływ na pulę zaangażowanych klientów.

Definiowanie rozwiązania do testowania hipotezy

Podczas każdej iteracji pętli opinii build-measure-learn próba utworzenia z empatią jest definiowana przez MVP.

MVP to najmniejsza jednostka nakładu pracy (wynalazek, inżynieria, opracowywanie aplikacji lub architektura danych) wymagana do utworzenia wystarczającego rozwiązania do nauki z klientem. Celem każdego MVP jest przetestowanie niektórych lub wszystkich wcześniejszych hipotez i otrzymanie opinii bezpośrednio od klienta. Dane wyjściowe nie są piękną aplikacją z wszystkimi funkcjami wymaganymi do zmiany branży. Pożądane dane wyjściowe każdej iteracji to szansa na uczenie się, szansa na dokładniejsze przetestowanie hipotezy.

Timeboxing to standardowy sposób, aby upewnić się, że produkt pozostaje chudy. Na przykład upewnij się, że zespół deweloperów uważa, że rozwiązanie można utworzyć w jednej iteracji, aby umożliwić szybkie testowanie. Aby lepiej zrozumieć, jak używać szybkości, iteracji i wydań w celu zdefiniowania minimalnych środków, zobacz Planowanie szybkości, iteracji, wydań i ścieżek iteracji.

Zmniejszanie złożoności i opóźnianie skoków technicznych

Dyscypliny wynalazków opisane w metodologii innowacji badają funkcjonalność, która jest często wymagana do dostarczania dojrzałych innowacji lub rozwiązania MVP gotowego do skalowania. Użyj tych dyscyplin jako długoterminowego przewodnika po włączeniu funkcji. Podobnie należy użyć ich jako przewodnika ostrzegawczego podczas wczesnego testowania wartości klienta i empatii w rozwiązaniu.

Zakres funkcji i różne dyscypliny wynalazków nie mogą być tworzone w jednej iteracji. Może to potrwać kilka wersji rozwiązania MVP, aby uwzględnić złożoność wielu dyscyplin. W zależności od inwestycji w rozwój może istnieć wiele równoległych zespołów pracujących w różnych dyscyplinach, aby przetestować wiele hipotez. Chociaż jest to inteligentne, aby zachować wyrównanie architektury między tymi zespołami, nie jest w stanie spróbować zbudować złożone, zintegrowane rozwiązania, dopóki nie będzie można zweryfikować hipotez wartości.

Wykrywasz złożoność najlepiej w częstotliwości lub wielkości skoków technicznych. Skoki techniczne to wysiłki na rzecz tworzenia rozwiązań technicznych, których nie można łatwo przetestować u klientów. Gdy wartość klienta i empatia klienta są niesprawdzone, skoki techniczne stanowią ryzyko dla innowacji i powinny być zminimalizowane. W przypadku typów dojrzałych przetestowanych rozwiązań znalezionych w procesie migracji skoki techniczne mogą być powszechne w całym wdrożeniu. Ale opóźniają testowanie hipotez w wysiłkach na rzecz innowacji i należy je odłożyć zawsze, gdy jest to możliwe.

Nieustępliwe podejście upraszczające pomaga w każdej definicji MVP. Takie podejście oznacza usunięcie wszystkich elementów, które nie pomagają w weryfikacji hipotezy. Aby zminimalizować złożoność, zmniejsz liczbę integracji i funkcji, które nie są wymagane do przetestowania hipotezy.

Tworzenie MVP

W każdej iteracji rozwiązanie MVP może przyjmować wiele różnych kształtów. Typowym wymaganiem jest tylko to, że dane wyjściowe umożliwiają pomiar i testowanie hipotezy. To proste wymaganie inicjuje proces naukowy i umożliwia zespołowi budowanie z empatią. Aby zapewnić ten pierwszy klient, początkowy MVP może polegać tylko na jednej z dziedzin wynalazków.

W niektórych przypadkach najszybsza ścieżka do innowacji oznacza tymczasowe uniknięcie tych dyscyplin, dopóki zespół wdrożeniowy ds. chmury nie będzie przekonany, że hipoteza jest dokładnie zweryfikowana. Od firmy technologicznej, takiej jak Firma Microsoft, te wskazówki mogą brzmieć nieintuiktywnie. Podkreśla jednak, że potrzeby klientów, a nie konkretna decyzja technologiczna, są najwyższym priorytetem w rozwiązaniu MVP.

Zazwyczaj rozwiązanie MVP składa się z rozwiązania aplikacji lub danych z minimalnymi funkcjami i ograniczoną ilością polerowania. W przypadku organizacji, które mają wiedzę dotyczącą rozwoju zawodowego, ta ścieżka jest często najszybsza do nauki i iteracji. Poniższa lista zawiera kilka innych podejść, które zespół może wykonać w celu utworzenia MVP:

• Algorytm predykcyjny, który jest niewłaściwy w 99 procentach czasu, ale pokazuje konkretne żądane wyniki.
• Urządzenie IoT, które nie komunikuje się bezpiecznie na dużą skalę produkcyjną, ale pokazuje wartość niemal danych w czasie rzeczywistym w procesie.
• Aplikacja utworzona przez dewelopera obywatela w celu przetestowania hipotezy lub spełnienia potrzeb na mniejszą skalę.
• Proces ręczny, który ponownie tworzy korzyści wynikające z działania aplikacji.
• Szkielet lub wideo, które są wystarczająco szczegółowe, aby umożliwić klientowi interakcję.

Opracowywanie MVP nie powinno wymagać ogromnych kwot inwestycji programistycznych. Najlepiej ograniczyć inwestycje tak bardzo, jak to możliwe, aby zminimalizować liczbę hipotez testowanych jednocześnie. Następnie w każdej iteracji i w każdej wersji celowo ulepszysz rozwiązanie w kierunku rozwiązania gotowego do skalowania, które reprezentuje wiele dyscyplin wynalazków.

Przyspieszanie opracowywania MVP

Czas na rynek ma kluczowe znaczenie dla sukcesu każdej innowacji. Szybsze wersje prowadzą do szybszego uczenia się. Szybsze uczenie prowadzi do produktów, które mogą być skalowane szybciej. Czasami tradycyjne cykle tworzenia aplikacji mogą spowolnić ten proces. Częściej innowacje są ograniczane przez limity dostępnej wiedzy. Budżety, zatrudnienie i dostępność pracowników mogą tworzyć limity liczby nowych innowacji, które może obsłużyć zespół.

Ograniczenia kadrowe i chęć budowania z empatią wywołały szybko rosnący trend wobec deweloperów obywateli. Ci deweloperzy zmniejszają ryzyko i zapewniają skalę w społeczności rozwoju zawodowego organizacji. Deweloperzy obywateli są ekspertami w zakresie środowiska klienta, ale nie są przeszkoleni jako inżynierowie. Osoby te korzystają z narzędzi do tworzenia prototypów lub narzędzi programistycznych o mniejszej wadze, które mogą być pomarszczone przez profesjonalnych deweloperów. Ci deweloperzy dostosowani do firmy tworzą rozwiązania MVP i testowe teorie. Po wyrównaniu ten proces tworzy rozwiązania produkcyjne, które zapewniają wartość, ale nie przechodzą wystarczająco efektywnej hipotezy skalowania. Zespoły mogą również używać rozwiązań do weryfikacji prototypu przed rozpoczęciem wysiłków związanych z skalowaniem.

W ramach dowolnego planu innowacji zespoły ds. wdrażania chmury powinny zdywersyfikować swoje portfolio, aby uwzględnić wysiłki deweloperów obywateli. Skalowanie wysiłków programistycznych pozwala tworzyć i testować więcej hipotez w ramach zmniejszonych inwestycji. Po zweryfikowaniu hipotezy i zidentyfikowaniu rynku, profesjonalni deweloperzy mogą następnie wzmacniać i skalować rozwiązanie przy użyciu nowoczesnych narzędzi programistycznych.

Ostateczna brama kompilacji: ból klienta

Gdy empatia klienta jest silna, wyraźnie istniejący problem powinien być łatwy do zidentyfikowania. Ból klienta powinien być oczywisty. Podczas kompilacji zespół wdrożeniowy ds. chmury pracuje nad rozwiązaniem do testowania hipotezy opartej na punkcie bólu klienta. Jeśli hipoteza jest dobrze zdefiniowana, ale punkt bólu nie jest, rozwiązanie nie jest naprawdę oparte na empatii klienta. W tym scenariuszu kompilacja nie jest właściwym punktem wyjścia. Zamiast tego zainwestuj najpierw w budowanie empatii i uczenia się od prawdziwych klientów. Najlepsze podejście do budowania empatii i weryfikowania bólu jest proste: słuchaj swoich klientów. Zainwestuj czas na spotkanie z nimi i obserwuj je, dopóki nie będzie można zidentyfikować punktu bólu, który występuje często. Po zapoznaniu się z punktem bólu klienta możesz przetestować hipotezę rozwiązania w celu rozwiązania tego bólu.

Kiedy nie należy stosować tego podejścia

Istnieje wiele wymagań prawnych, zgodności i branżowych, które mogą wymagać alternatywnego podejścia. Takie podejście może nie być odpowiednie, jeśli publiczne wersje rozwiązania programowego:

• Tworzenie ryzyka związanego z czasem patentu, ochroną własności intelektualnej lub wyciekami danych klientów
• Naruszenie ustalonych wymagań dotyczących zgodności

Jeśli te postrzegane zagrożenia istnieją, należy skonsultować się z doradcą prawnym przed przyjęciem dowolnego podejścia z przewodnikiem do zarządzania wydaniami.

Odwołania

Niektóre pojęcia opisane w tym artykule opierają się na pomysłach omówionych przez The Lean Startup Erica Riesa.

Następne kroki

Po utworzeniu rozwiązania MVP można zmierzyć wartość empatii i wartość skalowania. Dowiedz się, jak zmierzyć wpływ klienta.

Mierzenie wpływu na klientów