Customer development: Rozhovory so zákazníkmi krok za krokom
Skôr než navrhneme nový produkt, potrebujeme rozumieť situácii, ktorú má vyriešiť. V rozhovore hľadáme konkrétnu skúsenosť, dnešné riešenie a jeho dôsledky. Pochvala nápadu sama osebe nie je zadaním pre vývoj.
Customer development je širší postup overovania predpokladov o zákazníkoch a podnikaní. Steve Blank v ňom rozlišuje objavovanie zákazníckych potrieb, overovanie obchodného modelu a ďalšie fázy rozvoja firmy. Tento návod sa sústredí na problémové rozhovory v prvej fáze, často označovanej ako customer discovery.
Prípravu, vedenie a vyhodnotenie ukážeme na modelovej servisnej firme, ktorá zvažuje klientsky portál so stavom zákaziek. Príklady otázok a odpovedí sú vymyslené na vysvetlenie postupu, nie citácie našich klientov.
01Určite rozhodnutie, ktoré majú rozhovory ovplyvniť
Začneme vetou: „Po tejto sérii chceme rozhodnúť, či má zmysel ďalej overovať samoobslužné sledovanie servisnej zákazky.“ Je konkrétnejšia než „zistiť, čo zákazníci chcú“. Vedľa zapíšeme predpoklady: komu informácia chýba, kedy ju potrebuje, ako ju získava dnes a čo sa stane, keď ju nemá.
Pri našom modeli nevieme, či ľuďom prekáža hľadanie stavu, neistý termín alebo chýbajúci doklad o oprave. Každý problém môže viesť k inému riešeniu. Pred objednaním portálu potrebujeme zistiť, ktorý z nich ovplyvňuje ich prácu.
- Predpoklad: zákazník opakovane kontaktuje servis, pretože nepozná ďalší krok zákazky.
- Čo by ho oslabilo: stav dostáva včas a volá pre odbornú radu, ktorú portál nevyrieši.
- Čo chceme doložiť: poslednú konkrétnu situáciu, priebeh komunikácie a dopad.
- Rozhodnutie po výskume: pokračovať, zúžiť skupinu, zmeniť otázku alebo prácu zastaviť.
Ak sa tím nezhodne na skupine a zmysle produktu, najprv si ujasnite produktovú víziu a stratégiu. Rozhovory potom preverujú spoločné predpoklady, namiesto hľadania potvrdenia predstáv jednotlivcov.
02Vyberajte ľudí podľa skutočnej skúsenosti
Podmienky náboru majú byť overiteľné. Pre servisný portál by sme hľadali ľudí, ktorí nedávno osobne vybavovali opravu firemného zariadenia. Obdobie prispôsobíme bežnej frekvencii takej udalosti. Kategória „majiteľ malej firmy“ sama neznamená, že človek danú situáciu pozná.
Pri B2B oddelíme používateľa, človeka schvaľujúceho nákup a správcu procesu. Technik môže potrebovať podrobnosti opravy, vedúci termín a účtovník doklad. Ich odpovede nezlúčime do jednej persony. Zahrnieme aj ľudí, ktorým dnešný postup vyhovuje alebo službu prestali používať.
Pozvánka stručne vysvetlí tému, dĺžku, priebeh a prípadnú odmenu. Modelový text: „Zisťujeme, ako firmy sledujú priebeh servisných opráv. Zaujíma nás skúsenosť z poslednej konkrétnej zákazky. Rozhovor potrvá približne pol hodiny.“ Nenaznačujeme, že očakávanou odpoveďou je nespokojnosť.
Vlastní zákazníci sú dobrý začiatok, no iba spokojní známi môžu vytvoriť jednostranný obraz. Pri každom účastníkovi si poznačíme zdroj náboru a splnenie podmienok. Opakujúce sa odpovede od stále rovnakého typu ľudí môžu odrážať najmä spôsob výberu.
03Pripravte scenár a dohodnite prácu so záznamom
Spíšeme hlavnú otázku, doplňujúce okruhy a čas na vyhodnotenie. GOV.UK odporúča plánovať výskum podľa otázok a potrebného rozhodnutia. Scenár si vyskúšame nanečisto, aby sme odhalili nejasné formulácie.
| Časť rozhovoru | Modelový čas | Účel |
|---|---|---|
| Úvod a dohoda | 3 minúty | Vysvetliť tému, prítomné osoby a prácu so záznamom. |
| Posledná konkrétna zákazka | 12 minút | Prejsť udalosti v poradí a zistiť skutočné konanie. |
| Dôsledky a dnešné riešenie | 10 minút | Pochopiť dopad, alternatívy a zapojené roly. |
| Zhrnutie a ďalší kontakt | 5 minút | Opraviť naše porozumenie a dohodnúť prípadný ďalší krok. |
Pred poznámkami či nahrávaním vysvetlíme účel, prístup k materiálom a dobu ich potrebného uchovania. Získame primeraný súhlas s účasťou a zvoleným záznamom; človek môže nahrávanie odmietnuť. Praktický rámec ponúka GOV.UK pre poznámky a nahrávky. Do pracovného prehľadu nedávame nepotrebné osobné údaje ani dôverné servisné dokumenty.
Zapisovateľa predstavíme účastníkovi. Jeden človek vedie rozhovor, druhý zachytáva podstatné výroky a nejasnosti. Môžeme sa tak sústrediť na počúvanie namiesto doslovného prepisovania každej vety.
04Pýtajte sa na minulé správanie a konkrétne situácie
Verejná prednáška Y Combinatoru s Ericom Migicovskym zdôrazňuje reálne skúsenosti namiesto hypotetických reakcií na nápad. Pre náš portál z nich vychádzajú otázky k poslednej zákazke. Scenár nie je zoznam, ktorý treba mechanicky celý odrecitovať.
| Sugestívna alebo slabá otázka | Vhodnejšia otázka pre náš model | Čo potrebujeme zistiť |
|---|---|---|
| Používali by ste náš klientsky portál? | Ako ste naposledy zistili stav servisnej zákazky? | Skutočný postup namiesto budúceho sľubu. |
| Čakanie na informácie vás určite zdržuje, však? | Čo nasledovalo, keď ste vtedy informáciu nemali? | Dopad bez ponúknutej odpovede. |
| Chceli by ste notifikácie? | Ako ste sa dozvedeli, že môžete zariadenie prevziať? | Dnešný kanál a potrebný okamih. |
| Zaplatili by ste za rýchlejší prehľad? | Ako dnes riešenie zabezpečujete a kto schválil poslednú zmenu postupu? | Existujúce náklady a rozhodovanie, nie odhad budúcej ceny. |
| Čo máme do portálu pridať? | Ktorá časť poslednej zákazky bola najťažšia a čo ste vtedy urobili? | Problém a vlastný pokus o riešenie. |
Dopĺňame krátke otázky: „Čo sa stalo potom?“, „Kto ďalší pri tom bol?“ či „Ako ste vedeli, že je hotovo?“ Pri všeobecnom hodnotení požiadame o príklad. Keď niečomu nerozumieme, zhrnieme svoje porozumenie a necháme ho opraviť. Každú prestávku nemusíme vyplniť vlastným vysvetlením.
05Neobhajujte nápad, rozoberte skúsenosť
Modelový účastník povie: „Museli sme im stále volať.“ To ešte nedokladá potrebu portálu. Pýtame sa na poslednú zákazku: kedy volal, komu, čo potreboval a akú odpoveď dostal. Môže sa ukázať, že riešil schválenie drahšej opravy. Samotný prehľad stavu by nepomohol.
Ďalší modelový výrok znie: „Stav som mal v e-maile, ale kolega potreboval potvrdenie pre zákazníka.“ Otvára otázku odovzdávania informácií medzi rolami. Zapíšeme hypotézu na overenie, nie hotovú požiadavku na tímové účty.
Ak účastník navrhne funkciu, poďakujeme a vrátime sa k situácii, pre ktorú ju chce. Rovnako vážne zaznamenáme prípady, keď dnešné riešenie funguje. Nesnažíme sa z každého rozhovoru za každú cenu získať problém.
Neutrálne vedenie a konkrétne príbehy opisuje aj metodika hĺbkových rozhovorov GOV.UK. Ak neskôr ukážeme návrh, oddelíme ho ako časť s iným cieľom. Následné reakcie už nepovažujeme za nezávislý opis pôvodného problému.
06Premeňte poznámky na dohľadateľné dôkazy
Po rozhovore vyplníme kartu: rola a kontext, konkrétna udalosť, dnešný postup, dopad, doterajšie pokusy, rozpory a otvorené otázky. Odhad označíme ako odhad. Citáciu oddelíme od parafrázy a domnienku tímu od toho, čo sme počuli.
| Vrstva zápisu | Modelový príklad | Čo z neho zatiaľ nevyplýva |
|---|---|---|
| Výpoveď účastníka | Pri poslednej oprave volal dvakrát pre potvrdenie termínu. | Nevieme, ako často sa to deje ostatným. |
| Naša interpretácia | V danom okamihu chýbala dôveryhodná informácia o termíne. | Nevieme, ako ju najlepšie doručiť. |
| Ďalšie overenie | Zistiť, kto termín aktualizuje a kedy ho zákazník potrebuje. | Vývoj portálu ešte nie je schválený. |
GOV.UK pri analýze oddeľuje pozorovania od interpretácií. Porovnávame zistenia v podobných skupinách a hľadáme aj rozpory. Dvaja ľudia z jednej firmy nepredstavujú to isté ako nezávislé skúsenosti z dvoch prevádzok.
Rozhovory neposkytujú reprezentatívny podiel trhu. Opakovaný problém je smer pre ďalšie overenie, nie automaticky percento budúcich zákazníkov. Ak potrebujeme problém prepojiť naprieč kontaktnými miestami, nadviažeme customer journey mapou.
07Dohodnite ďalšie overenie
Záver zapíšeme ako rozhodnutie s dôvodom. Napríklad: „Najprv preveríme, či servis dokáže poskytovať aktuálny termín. Až potom otestujeme jeho zobrazenie zákazníkom.“ Portál bez spoľahlivej informácie by len premiestnil problém na inú obrazovku.
- Opakovaný problém s doloženým dopadom: pripravíme najmenší ďalší experiment a očakávaný výsledok.
- Rozpor medzi rolami: rozdelíme skupinu a doplníme chýbajúci pohľad.
- Pochvala bez konkrétnej skúsenosti: nesľubujeme vývoj, upravíme nábor alebo otázky.
- Vyhovujúce dnešné riešenie: preveríme iný problém alebo investíciu odložíme.
Rozhovor sám nedokazuje ochotu zaplatiť za konkrétny produkt. Ďalšie overenie záujmu opisuje návod od nápadu k MVP. Ak je neisté ovládanie návrhu, využijeme test interaktívneho prototypu. Až s jasným cieľom určíme rozsah prvej verzie.
V Listify s vami premeníme nejasný nápad na overiteľné otázky, podklady pre návrh a rozhodnutie o ďalšom kroku. Výsledkom má byť zrozumiteľné zadanie aj prehľad toho, čo ešte nevieme. Prototypovanie a vývoj naň môžu nadviazať, ak na ne máme dostatočný dôvod.
Nadväzujúci vývoj webovej aplikácie pripravíme okolo overenej úlohy, potrebných dát a merateľného výsledku prvej verzie. Nemusíte prísť s hotovým zoznamom funkcií.
08Časté otázky k rozhovorom so zákazníkmi
Koľko rozhovorov potrebujeme?
Univerzálny počet neexistuje. Záleží na rozmanitosti skupín, riziku rozhodnutia a kvalite zistení. Sledujte, či pribúdajú dôležité nové informácie a či nechýba podstatná rola. Rovnaké názory z jednej siete kontaktov nemusia znamenať dostatok dôkazov.
Máme nápad ukázať hneď?
Pri problémovom rozhovore najprv potrebujeme neovplyvnený opis skúsenosti. Ukážku možno zaradiť ako oddelenú časť alebo ďalšie stretnutie a vyhodnotiť samostatne.
Môže rozhovor nahradiť dotazník?
Dotazník pomáha zbierať známe typy odpovedí vo väčšom rozsahu. Rozhovor umožňuje dopytovať sa na neznáme okolnosti a rozpory. Metódu vyberte podľa otázky, ktorú potrebujete zodpovedať.
Ako sa pýtať na cenu?
Skúmajte dnešné výdavky, čas, alternatívy, schvaľovanie a rozpočet na problém. Hypotetická suma nie je záväzok nakúpiť. Konkrétnu ponuku overujte ďalším transparentným krokom.
Čo poslať Listify bez hotového produktu?
Opíšte zamýšľanú skupinu, problém a rozhodnutie, s ktorým potrebujete pomôcť. Pridajte doterajšie poznatky a možnosti oslovenia účastníkov. Hotové zadanie aplikácie zatiaľ nepotrebujete.