V předchozím příspěvku jsem se snažil poskytnout náhled do lean metodiky. Validací problému a řešení však lean postup ve startupech zdaleka nekončí. I když jsme zpočátku provedli validaci dobře, nikdy si nemůžeme být zcela jisti, jak přesné naše poznatky byly a zda skutečně každá vlastnost a schopnost tvořeného produktu je zákazníkem oceňována. Proto je dobré začít s něčím malým, co implementuje řešení jen pro nejzákladnější scénáře a co možná ještě ani není plně automatizováno. Je dobré nejdříve vytvořit minimum viable product (MVP). MVP je pro vývoj v lean starupech stěžejní výchozí bod. Pojem MVP však dává smysl i nezávisle na lean metodice.
MVP = produkt s nejmenší možnou funkcionalitou, aby ho použila podstatná část cílové skupiny
(pro potřeby lean startupu: aby ho použila většina early adopters).
Měřit, měřit, měřit…
MVP pro potřeby lean startupu navíc musí obsahovat měřící nástroje, kterými dokážete sledovat charakter úspěchů či selhání. Např. byste měli být schopni zachytit, kolik lidí odešlo ihned po zobrazení úvodní stránky, či kolik lidí, kteří klikli na registraci, bylo odrazeno registračním formulářem. Díky tomu získáte základní data, díky kterým můžete produkt ladit a vylepšovat. Zároveň je stále potřeba přijít do osobního styku s prvními uživateli. Lze předpokládat, že právě tito uživatelé, kteří jsou ochotní používat první zabugovanou a funkčně ořezanou verzi vašeho produktu, budou ochotní vám dát užitečnou zpětnou vazbu.
Pokud jste se vydali na slepou kolej vývoje, je lepší na to přijít dříve než vydáte kompletní produkt. Např. můžete přijít na to, že místo webové služby by byl vhodnější plugin do prohlížeče nebo naopak. Taková změna vede k zahození velké části kódu. Na to musíte prostě přijít co nejdříve a MVP je správnou cestou, jak to zjistit.
Co je MVP a co už není
V internetových startupech jsem vypozoroval dva základní typy MVP, které se opakovaně objevují a mezi kterými není ostrá hranice (tedy lze je i kombinovat):
- Concierge – Tento termín se používá pro produkty, kde automatizaci dočasně nahrazuje na pozadí aplikace člověk. Vhodný pro produkty, kde není tak důležitá okamžitá interakce a propracovaný UI. Produkt má typicky jen lepší landing page, maximálně nějaký formulář, kterým může uživatel poslat požadavek.
- Single-feature aplikace – I když ve finále má jít o komplexní systém, vyvine se jen jedna funkčnost, která má potenciál přitáhnout cílové zákazníky (i kdyby to byla spíše vábnička, ne hned váš úhelný kámen). Vhodný pro produkty více závislé na UI a okamžité odezvě.
Příklad: Jeden startup na TechPeaks chce vyvinout produkt usnadňující začínajícím skupinám výrobu on-line hudebních videí. Ve finále chce dovolit míchat klipy z on-line videí s Creative Commons licencí. Jako MVP však nabídne single-feature nástroj, který na YouTube nahraje s hudbou jen jeden statický obrázek. Jistě tím nezaujme tolik pozornosti, jako s finálním produktem, ale své early adopters si tak možná získá. Tak bude mít uživatele, na kterých se lze učit a měřit. V tomto případě je navíc možno kombinovat i s concierge, jelikož i pro jednoduché video s obrázkem může implementace a odladění takové automatizové služby zabrat klidně týden, zatímco udělat stránku s formulářem zvládnete během jednoho dne.
Jistě si dokážeme představit i komplexnější MVP, ale je potřeba se vždy svědomitě zamyslet, zda je to skutečně MVP, nebo si jen něco nalháváme. Srdcem technologové a vývojáři mají k nalhávání často blízko – např. já osobně se těžko oprošťuji od faktu, že architektura finálního produktu nemusí stavět na architektuře MVP. Tudíž místo abych něco rychle nahackoval, vyvíjím i MVP v přehledných modulech, datových schématech a bez redundance kódu. Velmi špatně se to odnaučuje.
Pokud vám vyjde, že by vývoj MVP měl zabrat člověkoměsíc nebo víc, musíte mít hodně dobře obhájené, že je to opravdu MVP. Nikde totiž není psáno, že hned první MVP uspěje. Spíš neuspěje. Pak se musíte poučit, něco změnit a jít dál. A to se může stát i vícekrát a vždy u toho zahodíte kód. Čím menší produkt bude, tím méně kódu zahodíte, tím více opakování můžete zvládnout a tím větší šanci na úspěch máte.
Pokud MVP neposkytuje zákazníkovi žádnou reálnou službu, nýbrž jen představuje budoucí produkt, není to MVP, ale může být použit jen k validaci řešení (viz přechozí článek). Zajímavé je, že někdy může být časově výhodné přeskočit validaci řešení a řešení validovou rovnou s MVP. To však jen pokud je implementace MVP srovnatelně obtížná s přípravou prezentace řešení (typicky, když MVP děláte pomocí concierge).
Závěr
Jak jsem psal na začátku článku, MVP je počátkem vývoje produktu dle lean metodiky. Dále je samozřejmě potřeba z MVP vystavět opravdový produkt. Asi příliš neprozdradím, když řeknu, že při přidání jakékoli funkcionality se opět používá kolečko nápad – extrakce předpokladů – ověření předpokladů. Produkt se pak z MVP vyvíjí v mnoha malých iteracích, spíše než ve skokových releasech. Ale to už je zase na další článek.
Na závěr si shrňme výhody a rizika MVP.
Výhody:
- MVP vás ochrání od zahazování měsíců vývoje.
- Dřívější feedback od zákazníků → větší motivace pro vývojáře a lepší marketing.
- Čím dříve jste online, tím více stoupáte v očích potenciálních investorů, protože máte historii a prezentovatelná data o té historii.
Rizika:
- Může se stát, že MVP bude mířit na jinou skupinu zákazníků než finální produkt.
- Poddimenzování minima – přeci jen občas je potřeba zákazníkovi dodat více, aby se zajímal a aby produkt bral vážně.
- Poškození kredibility firmy/vývojářů u nevyladěných zabugovaných produktů. Většinou bugy vadí míň, než si myslí vývojáři. Jsou však specifické produkty, kde si je prostě nemůžete dovolit (např. transformace zákazníkových dat).
Odkazy za relevantní čtení:
- On-line článek na TechCrunch – Darrell Etherington: How To Think About Minimum Viable Products
- On-line post na blogu Erica Riese: Minimum Viable Product: a guide
- On-line příklad MVP od Willa Dayble
- … a budu rád za další odkazy, neb najít něco výstižného a dostatečně jasně podaného bývá problém