MVP není nedodělaný produkt, který firma pošle na trh a doufá, že se nikdo nebude zlobit. Minimum viable product je nejmenší smysluplný způsob, jak ověřit důležitý předpoklad o zákazníkovi. Někdy jde o jednoduchou funkční verzi. Jindy stačí ručně poskytnutá služba, prototyp nebo možnost objednat ještě neautomatizovaný proces. Rozhodující je, jakou otázku test zodpoví a jaký důkaz po něm zůstane.
Začněte nejrizikovějším předpokladem
Eric Ries popisuje MVP jako verzi, která umožní získat co nejvíce ověřeného poznání s co nejmenším úsilím. Neznamená to vždy nejmenší počet funkcí. Když testujete důvěru ve službu, potřebujete dostatečně věrohodné předání. Když testujete ochotu platit, samotné lajky na návrhu nestačí. První krok je sepsat, co musí být pravda, aby podnikání fungovalo: existuje problém, zákazník ho řeší často, vybere vaši cestu a zaplatí cenu, která pokryje náklady.
Modelový příklad: malá firma chce vytvořit aplikaci pro objednávání lokálních oprav. Nejdražší nejistotou může být dostupnost řemeslníků v konkrétních časech, nikoli podoba kalendáře. Před vývojem lze přijmout omezený počet objednávek formulářem a přiřazovat je ručně. Výsledkem testu nebude „aplikace funguje“, ale údaj, kolik požadavků šlo splnit ve slíbené lhůtě a za jakých nákladů. Zkušenost zákazníka nesmí být záměrně matoucí; pokud službu obsluhují lidé, interně o tom vězte a neslibujte automatizaci, která neexistuje.
Čtyři podoby MVP podle otázky
| Test | Co ověřuje | Na co nestačí |
|---|---|---|
| Rozhovor s ukázkou | Porozumění problému a postupu | Ochotu skutečně zaplatit |
| Ruční služba | Využití a provozní kroky | Náklad automatizace ve velkém |
| Jednoduchá funkční verze | Opakované použití klíčového úkolu | Zájem jiných segmentů |
| Placený pilot | Hodnotu pro konkrétního kupce | Škálování bez podpory týmu |
Pro jeden projekt lze testy řadit od levnějších k náročnějším. Rozhovor odhalí nepochopený problém, ale jeho účastník může být zdvořilý. Ruční pilot ukáže skutečné překážky, ale ještě nemusí prokázat marži při větším objemu. Není nutné bránit se výrobě produktu za každou cenu. Jestliže hlavní nejistota leží v technické proveditelnosti, potřebujete funkční technický pokus.
Napište předem pravidlo rozhodnutí
Test je užitečnější, když před jeho spuštěním určíte cíl, období, počet oslovených a hranici, při které budete pokračovat, upravovat nabídku nebo skončíte. Například „během čtyř týdnů získáme deset placených pilotů a nejméně osm jich dokončí klíčový úkol“ je modelová podmínka, nikoli univerzální benchmark. Bez předem zapsaného pravidla si tým snadno vybere jen příznivá data. Vedle výsledku měřte také čas a náklady ruční obsluhy.
- Jednou větou pojmenujte předpoklad, který může projekt zničit.
- Vyberte chování zákazníka, které ho potvrdí lépe než názor.
- Určete malou, ale skutečnou skupinu vhodných lidí a způsob jejich získání.
- Stanovte délku testu, hranici úspěchu a důvod případného ukončení.
- Po testu oddělte pozorování od vysvětlení, proč podle vás nastalo.
Negativní výsledek je použitelný výsledek. Jestliže zákazníci nechtějí změnit svůj postup, další funkce nemusí problém vyřešit. Zeptejte se, zda šlo o špatně zvolený segment, příliš slabý problém, nevhodné načasování nebo nesrozumitelnou nabídku. Následný pokus by měl změnit jednu důležitou proměnnou, jinak se z něj nic nového nedozvíte.
Co MVP potřebuje i v malé verzi
Minimum nesmí odstranit podmínky, které rozhodují o bezpečném a poctivém využití. Platební údaje, osobní data a právní závazky nemůžete „otestovat později“ bez odpovídající ochrany. U provozní služby musíte umět splnit slíbený výsledek nebo jasně říci hranice. U fyzického výrobku nesmí být zkouška zaměněna za prodej připraveného produktu, pokud nejsou splněny relevantní požadavky.
Jasný Business Model Canvas vám pomůže pojmenovat, které části modelu testujete, a rozhovory s cílovou skupinou zpřesní otázky před pilotem. Po úspěšném MVP není hotovo: přichází ověření, zda uživatelé přicházejí opakovaně, zda by produkt postrádali a jestli ekonomika obstojí mimo ručně obsluhovanou skupinu.
Jak vyhodnotit malý vzorek bez přehnaných závěrů
U každého účastníka zaznamenejte, jak se o testu dozvěděl, co zkusil, kde skončil a zda se vrátil bez připomenutí. Vlastní známí často pomohou ochotněji než neznámí zákazníci, proto je v souhrnu odlišujte. Stejně důležitý je důvod odmítnutí: nevhodná cena, nedůvěra, chybějící funkce a nízká naléhavost problému vyžadují různé další kroky. Neschovávejte je do jedné kategorie „nezájem“.
Po deseti rozhovorech nehlaste, že uspěje přesně určité procento celého trhu. Napište, co se stalo právě v tomto testu a které otázky zůstaly otevřené. Když čtyři lidé zaplatili, zjistěte, proč zaplatili a zda jsou podobní dalším dosažitelným zákazníkům. Když se všichni po prvním použití ztratili, prozkoumejte první zkušenost dřív než koupíte další reklamu. MVP měří učení, ne počet dokončených obrazovek.
Výstupem testu má být krátký rozhodovací zápis: hypotéza, použitý postup, pozorovaná data, omezení vzorku a další krok. Uložte i neúspěšné varianty. Za půl roku mohou vysvětlit, proč tým určitou funkci vědomě nepostavil, a zabránit opakování stejného experimentu pod jiným názvem.
Jednostránková karta prvního testu
Před vývojem si vyplňte šest řádků: předpoklad, cílový zákazník, nejmenší test, pozorované chování, hranice pro rozhodnutí a datum vyhodnocení. Model pro objednávání oprav: „Majitelé bytů si rezervují termín online, pokud hned uvidí dostupnost.“ Testem může být ručně obsloužený formulář pro jednu čtvrť. Důkazem není počet návštěv stránky, ale počet dokončených a uskutečněných rezervací. Hranici zvolte před spuštěním, aby ji tým nepřizpůsobil výsledku.
Po testu u každé rezervace poznamenejte, zda se uskutečnila, kolik ruční práce stála a proč některé pokusy skončily. Když lidé formulář otevřeli, ale nedokončili ho, může být problém v důvěře, ceně nebo termínu. Jeden neúspěch neprokazuje, že celý nápad nemá trh. Ukazuje, který předpoklad je potřeba opravit. Další krok má být konkrétní: změnit nabídku termínů, ověřit cenu rozhovorem, nebo test zastavit.
Časté otázky
Musí být MVP veřejně dostupné všem?
Nemusí. Omezený pilot s vhodnými zákazníky může dát přesnější zpětnou vazbu a menší provozní riziko. Důležité je vědět, koho jste vybrali a jak to omezuje závěr.
Je prototyp na papíře také MVP?
Může jím být pro otázku srozumitelnosti nebo použitelnosti. Nestačí však jako důkaz, že lidé budou službu opakovaně používat a platit za ni.
Kdy přejít k plnému vývoji?
Tehdy, když hlavní rizika nelze smysluplně ověřovat levnějším postupem a dosavadní důkazy ospravedlňují další investici. Rozhodnutí má vycházet z konkrétního poznání, nikoli z únavy z testování.
Zdroje
Lean Startup Co.: What Is an MVP?; Silicon Valley Product Group: Minimum Viable Product. Modelový příklad opravných služeb je redakční ilustrace.
