Člověk od počítačů typicky sedne a začne bouchat kód — a nezřídka vyrobí něco, co nikdo nechce. Jak přemýšlet o novém projektu dřív, než padne první řádek kódu.
Jak člověk od počítačů přemýšlí o novém projektu? Typicky sedne k počítači a začne bouchat kód. Není vyloučené, že to někdy může fungovat a slavit úspěch. Nezřídka se takto ale vyrobí něco, co nikdo nechce. Nebo ještě hůř, vyrobí se řešení problému, který ani za námahu nestojí.
Jsem člověk od počítačů a často jsem takové tendence u sebe pozoroval (a zdaleka nejen u sebe). Na podzim jsme s Jirka Halousek přemýšleli, jaký by mohl a měl být náš další projekt. Já od té doby přemýšlím, jak to celé pojmout. Letošní zimu jsem po večerech a na cestách toto téma dost studoval. Zůstala mi v hlavě spousta myšlenek a desítky stran poznámek, tady je krátký výcuc z nich.
Spousta projektů se ubírá tím ajťáckým způsobem – něco se honem nabouchá a pak se to horko těžko předělává, neví se co dřív, mění se půda pod nohama a celkově to tak nějak vázne. Ve výsledku to pak stojí mnohem víc (času, peněz a lidí). Zatímco peníze a lidé přicházejí a odcházejí, čas plyne jen jedním směrem.
Proč to tak bývá?
Ne, ani iPod se nezrodil tak, že ho jednoho dne Steve Jobs vytáhnul z kapsy, kde se přes noc objevil (i když média to často vykreslují právě takto). Je za ním spousta let práce, mnoho postupných vylepšování (a taky selhání).
Často se vyrobí až moc, nebo se vyrobí to, co nikdo nepotřebuje. To se obvykle stane, když jsou potenciální zákazníci zapojení do plánů až v momentě, kdy jde produkt na trh.
Četl jsem dva hezké citáty, které se tady hodí zmínit.
Když se zeptáte lidí, co by chtěli, odpoví vám, že rychlejší koně. — Henry Ford
Ale co se tím říká? Lidé by chtěli nějakou rychlejší metodu cestování, než je jejich současná alternativa, což jsou (shodou okolností) koně.
Není prací zákazníka vědět, co chce. — Steve Jobs
Zákazník může (v lepším případě) jasně popsat svůj problém, ale není jeho práce nalézat řešení.
Dá se na to jít jinak?
Celé je to o efektivitě, o redukci plýtvání zdroji, o eliminaci odpadu.
Odpad je jakákoliv lidská aktivita, která spotřebovává zdroje a nevytváří žádnou hodnotu. — James P. Womak, Daniel T. Jones
Při startu nového projektu je situace často chaotická, je mnoho akcí, které připadají do úvahy — ale většinou existuje pouze pár klíčových akcí, na kterých v daném okamžiku opravdu záleží. Na tyto akce je potřeba se zaměřit a zbytek ignorovat. Zkrátka udělat správnou akci ve správný okamžik.
Často se pak úspěšný projekt od toho neúspěšného v zásadě neliší tím, že ten úspěšný měl lepší vizi, ale v tom, že ten úspěšný se dostal od vize k fungujícímu plánu dříve, než mu došly zdroje (finance, čas,…).
Žádná metodologie nezaručí úspěch. Ale dobrá metodologie může poskytnout zpětnou vazbu, díky které se můžete kontinuálně zlepšovat a učit. — Ash Maurya
Ne, neexistuje recept na úspěch. Neexistuje nic, co by zaručilo, že míra věnovaného úsilí a spotřebovaných zdrojů dovedou projekt ke zdárnému cíli. Dá se ale udělat spousta dobrých rozhodnutí, které pravděpodobnost úspěchu pravděpodobně zvýší.
Celá věda na toto téma se v podstatě točí okolo třech fází — dokumentace vize, identifikace nejriskantnějších částí, systematické testování.
Dokumentace vize (plán A)
Každý má spoustu vizí, nápadů, myšlenek. Obvykle nás napadají, když je nejméně čekáme (proč to tak asi je?) — mě třeba ve sprše, v autě, nebo na kole. Zdá se ale, že až nebezpečně často tyto myšlenky ignorujeme — zapomene je, pustíme z hlavy, zastíníme důležitějšími potřebami. Ale někteří s nimi pracují.
Na druhou stranu, většina vizí prostě nefunguje (nebo alespoň ne podle představ). Vize jako taková je často založena na nějakých předpokladech (hypotézách), které nejsou vůbec nijak ověřeny. Vize si často necháváme jen v hlavě (s tím, že tak je můžeme nejrychleji upravovat)—ale to jen vede k tomu, že čím dál víc ignorujeme realitu.
Zatímco vize jsou levné, práce na nich je docela drahá. — Ash Maurya
Cílem je vize (plány A) zdokumentovat—bez toho s nimi můžeme systematicky pracovat jen těžko, natož je nějak testovat (validovat) a adekvátně upravovat. Prvním krokem je počáteční vizi popsat (a sdílet ji alespoň s jednou další osobou).
Dokumentace vize tradičně probíhá formou business plánů. Ty mají často formu několika (desítek) stran a trvá mnoho (tý)dnů, než jsou sepsány.
Ne, vážně nikdo netvrdí, že business plán je odpad. Jen nemusí být dogmatem, že ve fázi vize v hlavě je dobré zabít pár týdnů vytvářením něčeho poměrně statického, co pak někomu ukážeme. Zdá se jako vhodnější v této fázi použít něco rychlejšího (netrvá to týdny, ale hodiny), stručnějšího (nemá to desítky stran, ale jednu, která obsahuje opravdu pouze to zásadní) a přenositelnějšího (jednu stránku lze snadno rozdat, sdílet, vylepit, poslat).
Cílem celé této anabáze je uvědomit si, že vize (plán A) obvykle ještě není ten plán, který funguje. K plánu, který funguje, musíme teprve dojít.
Proč vize není plán, který funguje?
Vize je obvykle o řešení. Máme vizi, jak vyřešit něco. Často hodně mluvíme o našem řešení (léku na problém), ale mnohem méně toho víme o problému samotném (problém je něco, co trápí cílovou skupinu).
Řešení jsou pomíjivá, velké problémy ne. – Ash Maurya
Nejde zdaleka jen o řešení jako takové. Dalšími složkami plánu jsou:
Problém — jaké jsou nejčastější problémy našich zákazníků, co je nejvíce trápí, co potřebují řešit? Jak tyto problémy řeší nyní, co k tomu používají a jak s tím pracují? Pokud nějaký problém zatím neřeší nijak nebo neexistuje žádná konkurence, nemusí to znamenat, že existuje díra na trhu, ale že takový problém fakt nikoho netrápí.
Zákazníci — kdo jsou naši zákazníci a kdo uživatelé (ano, je v tom velký rozdíl — zákazník je ten, kdo za produkt platí, uživatel neplatí)? S kterými z nich můžeme počítat jako s prvními? Kteří nám můžou být užiteční? Není dobré přemýšlet tak, že hledáme zákazníky, kteří mají námi definovaný problém. Zákazníkem rozhodně nejsou všichni, to není reálné (aspoň ne v této počáteční fázi).
Unikátní nabídka hodnoty (UVP) — jak zákazníky upoutáme, v čem jsme jiní, co jim naše řešení přinese a proč je důležité to, v čem jsme jiní? Toto je obvykle ten slogan, co máme na landing page a na každém marketingovém materiálu.
Řešení — čím konkrétně naše řešení pomáhá zákazníkům řešit jejich největší problémy? Toto je obvykle to, co nás napadne jako vize — řešení něčeho.
Cesty k zákazníkům — jak se ke svým zákazníkům dostaneme? Je důležité nejen přemýšlet o těchto cestách a o tom, jak je budeme využívat, ale tyto předpoklady také testovat.
Konkurenční výhoda — proč bychom to, co chceme dělat, měli dělat zrovna my? Máme něco, co je těžké zkopírovat nebo koupit jinde? Cokoliv, co stojí za zkopírování, bude zkopírováno (nejspíš záhy po tom, co předvedete, že je to životaschopné).
Cena — kolik bude stát naše řešení a jak k tomuto číslu dojdeme? Za co (a od kdy) budou zákazníci platit? Cena je součástí produktu a definuje zákazníky, navíc je to jedna z prvních forem validace.
Náklady — kolik a za co budeme muset platit, kolik nás to bude stát? Kolik bude stát setkání se dostatečným množstvím potenciálních zákazníků? Kolik bude stát vytvoření MVP? Jak dlouho můžeme fungovat, než začneme vydělávat? Jaké budou fixní (třeba pronájem kanceláře) a variabilní náklady (třeba cena materiálu)?
Indikátory — co znamená, že je projekt úspěšný, jak to budeme měřit? Jaká další čísla jsou důležitá? Zajímají nás zejména akvizice (jak nás našli?), aktivace (co jim přinášíme?), retence/loajalita (vrací se k nám uživatelé?), tržby (za co utrácejí?), doporučení (doporučují nás dále?).
Zákazníky netrápí vaše řešení. Trápí je jejich problémy. — Dave McClure
Nehledáme jen řešení, ale celý model plánu. Nemá smysl hledat řešení problémů, které nikoho netrápí. Úkolem není přijít s nejlepším řešením, ale mít promyšlený celý model. Řešení sice může být invenční, ale inovaci představuje až celý tento model…produktem je tento model, ne jen to řešení.
Najít nejriskantnější části plánu
Vybudování úspěšného produktu je v zásadě o zmírňování rizik. — Ash Maurya
Proč si zákazník koupí zrovna naše řešení? Protože věří, že mu pomůže s řešením jeho problémů. Nikoliv proto, že je barevné, komplexní, levné, takové nebo makové. Proto je každý nový projekt z podstaty riskantní a cílem je tyto rizika eliminovat — s nejriskantnějšími částmi se vypořádat jako první.
Na druhou stranu, pokud skutečně nehledáme řešení zásadního globálního problému (lék na rakovinu třeba), tak za předpokladu, že máme dostatek zdrojů (času, peněz, úsilí), existuje jakási šance, že dokážeme postavit produkt. Ne, ještě pořád tady nemluvíme o výrobě, programování, kódování, buildění,…
Největším riskem je, že vybudujeme něco, co nikdo nechce. — Ash Maurya
Toto je brutální realita, všechno ostatní jsou podružné důvody. Druhým zasádním častým důvodem selhání je fakt, že často skončíme dřív, než pořádně začneme. Tou velkou otázkou dnes není Můžeme to udělat?, ale Měli bysme to dělat?.
Co je to riziko?
Nejistota je nedostatek jistoty — fakt, že existuje více, než jedna možnost. Risk je takový stav nejistoty, kde některé z možností znamenají ztrátu, neúspěch, katastrofu. — Douglas Hubbard
S novým zamýšleným projektem riskujeme hned na několika frontách — risk produktu (uděláme to správně?), risk zákazníka (dostaneme se k zákazníkům?), risk trhu (bude to životaschopné?).
Jediný způsob, jak zvítězit, je učit se rychleji, než kdokoliv jiný. — Eric Ries
Životní cyklus projektu se z toho nejvyššího nadhledu dá rozdělit na tři fáze.
Problem/Solution Fit
Kdy mám problém, který je hodný řešení? Když je to něco, co zákazníci chtějí (bez toho to nepůjde). Když to zákazníci zaplatí (když ne oni, tak kdo?). Když je to pro mě dosažitelné (když to dokážu vyřešit). Odpovědi na tyto otázky nejsou o výrobě (programování), ale o (systematickém) učení se — pozorování, rozhovory, kvalitativní výzkum. Tady riskujeme, že špatně pochopíme problém (risk produktu), že to nikoho netrápí (risk zákazníka), že už existují další alternativy (risk trhu).
Cílem je najít minimální životaschopný produkt (MVP) — produkt s nejmenší možnou funkcionalitou, aby ho použila podstatná část cílové skupiny.
S MVP se musí zacházet opatrně — MVP neznamená, že s tím má být co nejmíň práce, ani že má jít o provizorní řešení, ani že to může být plné chyb, ani že to je konečná fáze, kterou už nikdo nikdy nebude rozvíjet. MVP slouží k vyřešení nejzákladnějších potřeba zákazníka za účelem validace (nekompromisní ověřování, zda jsou předpoklady správné). MVP není jen o samotném řešení problému, ale navíc musí obsahovat nástroje (indikátory), kterými dokážeme sledovat co se děje — údaje jako kolik návštěvníků odešlo hned z úvodní stránky; kolik začalo a nedokončilo registraci, a spousta dalších. Neptejme se zákazníků, co si myslí, raději měřme, co (ne)dělají.
Výroba MVP by neměla trvat dlouho — pokud je na MVP potřeba měsíc a víc práce, pravděpodobně to není MVP.
Product/Market Fit
Máme problém hodný řešení a máme MVP. Musíme ověřit, že jsme vytvořili něco, co lidé chtějí — musíme otestovat, jak dobře naše řešení, řeší jejich problém. Jak by se zákazníci cítili, kdyby náš produkt už nemohli nadále používat, co by jim to způsobilo za problémy? Není pravda, že jakmile toto ověření jednou máme, je platné navždy. Tady riskujeme, že špatně vyřešíme problém (risk produktu), že to nikoho netrápí (risk zákazníka), že špatně stanovíme cenu (risk trhu).
Toto je první velký milník v životě projektu, první velká věc, na které skutečně záleží.
Škálování/Růst
Pokud projekt přežil fázi Product/Market Fit, je aspoň nějaká míra úspěchu skoro zaručena. A tady je správný okamžik, kdy na to pořádně šlápnout a urychlit růst (škálovat) — vrátit se k vlastnostem, které se do MVP nevešly a rozjet celé kolečko znova. Možná se na tyto vlastnosti teď budeme dívat jinak, možná nám přijdou důležitější než dřív, možná je zahodíme jako nepotřebné.
V prvních dvou fázích je zásadní učení a MVP, teprve v poslední fázi je důraz na optimalizace a růst. První dvě fáze jsou o hledání plánu, který funguje, třetí fáze je o akceleraci plánu. První dvě fáze jsou o korekci kurzu (úpravách a testování plánu), třetí fáze je o efektivitě (škálování).
Kdo to všechno zaplatí?
V prvních dvou fázích je cílem učit se (poznávat zákazníky, zjišťovat jejich potřeby, upravovat plány), ve třetí fázi je cílem růst. Investor to ale typicky vnímá jinak, jeho cílem je růst produktu bez ohledu na to, v jaké fázi projekt je. Takže i když možná bude potřeba nějaká menší investice dříve, než ve třetí fázi, ideální okamžik na velkou investici je před fází růstu, protože vy i investor máte stejný cíl. Taky není vyloučené, že po druhé fázi najdeme pár fakt dobrých zákazníků a (velkého) investora ani nebude potřeba.
Systematické testování plánu
Plán A (vizi) máme zdokumentovánu, rizika prioritizované. Jsme tedy připraveni na systematické testování plánu. Jak to uděláme? Pomocí experimentů. Experiment je validační smyčka Build = Product = Measure = Data = Learn = Ideas = Build…
Začínáme v build fázi se sadou myšlenek a hypotéz, na základě kterých vytvoříme nějaký artefakt (kód, landing page, wireframe, vizualizaci) pro účely testování hypotéz. Artefakt předhodíme zákazníkům a měříme jejich reakce, jak kvalitativně, tak kvantitativně. Tato data použijeme pro účely ověření hypotézy — cílem je hypotézu buď zvalidovat, nebo odmítnout, což nás přivede k novým myšlenkám.
Jeden experiment pomůže s validací nebo odmítnutím specifické hypotézy o byznys modelu. Cílem je iterací experimentů dohromady dojít k Product/Market Fit. Vlastně iterativně opakujeme smyčku Pochopit problém — Definovat řešení — Validovat kvalitativně — Validovat kvantitativně. První dvě části jsou o nalezení problému hodného řešení (Problem/Solution fit). Druhé dvě jsou o zjištění, jestli jsme vytvořili něco, co lidé chtějí (Product/Market fit).
Ne, toto opravdu není o tvrzeních typu Všichni moji známí říkali, ani Já jsem X a všichni ostatní X to mají určitě taky tak, ani Oni nevědí, co chtějí, ani Jsem svým zákazníkem, tak to vím, ani Nepotřebuji to testovat, je to přece jasné. Validace se dělá s lidmi, které (téměř) neznáme, jinak nikdy nedostaneme objektivní zpětnou vazbu. Takové kontakty jen těžko najdeme ve vedlejší kanceláří nebo u sousedů, v anglické literatuře říkají hezky get out of the building — je prostě potřeba jít tam, kde se s cílovou skupinou můžeme potkat. Od takových kontaktů pak posbíráme zpětnou vazbu a pro potvrzení hypotézy bychom měli dostat nějakou předem stanovenou míru kladných odpovědí (což určitě není 1 ze 100, spíše někde kolem 50%). Mimochodem, když takto narazíme na zajímavý kontakt (třeba když naše řešení perfektně sedí na jeho problém; když se o projekt už teď aktivně zajímá), může to být jedna z prvních vlaštovek (early adopters) a takový kontakt má cenu zlata.
Tak…po validaci plánu, úpravách vize, další validaci a dalších úpravách, až začne všechno do sebe krásně zapadat a poslední validace hypotézy potvrdí, teprve teď se pustíme do výroby (kódování, programování…). A když validace nedopadnou, nic nesedí, všechno je špatně? Aspoň jsme ušetřili třeba (půl)roky vývoje. Ale pořád to není k zahození, možná je potřeba změnit nějaký předpoklad, který se nepotvrdil. Nebo možná bude cílovka jiná, než jsme se domnívali. Nebo cílovka je dobrá, ale problém, který ji pálí, je trochu jiný. A třeba se to na sebe dá napasovat!
A v čem je největší změna pro ajťáka? V tom, že se musí sžít s faktem, že validace se zkrátka vyplatí…a že dobré řešení není 90% úspěchu, ale jen 10% plánu.
Ne, není to z mé hlavy. Jen jsem toho dost přečetl, dal si dohromady, sem tam přidal nějaký svůj pohled. Vzniklo z toho mnoho stran poznámek a tento článek je jejich shrnutí.
Na toto téma najdete dostatek zdrojů (českých moc ne), které se zabývají každou fází velmi obsáhle a podrobně. Některé jsou velmi teoretické, jiné až překvapivě praktické. Tento článek berte jen jako malý náhled pod pokličku, koho by to zaujalo více, rozhodně doporučuji studovat dále.
Pokud chcete něco hodně z (webové) praxe, začněte třeba knihou od Honzy Řezáče. Chcete-li něco obecnějšího, ale pořád hodně praktického, mrkněte na knihy od Ashe Mauryi. Kdo chce jít víc do základů a do teorie, určitě by měl sáhnout po knihách Ericka Riese.
Co mají všechny tyto zdroje společné? Nezaměřují se pouze na řešení a systematicky testují. Pro ty, kteří dočetli až sem, hledejte téma lean canvas.
Co si o tom myslíte? Dává vám to smysl? Zkusili byste to, kdybyste měli příležitost?