Jak poznat, jestli řešíte skutečný problém — a ne jen dobrý nápad?

Postavit software je dnes jednodušší než kdy dřív. Nástroje jsou dostupnější, infrastrukturu můžeme spustit během několika minut a s pomocí AI dokáže malý tým vytvořit první verzi produktu násobně rychleji než ještě před několika lety.

Jedna věc se ale příliš nezměnila: pořád můžeme velmi efektivně postavit něco, co nikdo nepotřebuje.

Produkt může být technicky dobře udělaný, rychlý a příjemný na používání. Může mít profesionální design, několik chytrých funkcí a tým, který na něm odvedl kvalitní práci. Přesto se může stát, že ho lidé otevřou jednou a už se nevrátí, případně řeknou, že vypadá zajímavě, ale nikdy za něj nezaplatí.

Problém v takové chvíli není v realizaci, ale vznikl mnohem dřív. Postavili jsme řešení ještě předtím, než jsme si dostatečně ověřili, že existuje problém, který stojí za řešení.

A právě to je podle mě jedna z nejdražších chyb při tvorbě nových produktů: ne postavit něco špatně, ale velmi dobře postavit něco zbytečného.

Dobrý nápad a skutečný problém nejsou totéž

Některé produktové nápady znějí dobře prakticky okamžitě. Aplikace, která pomocí AI automaticky zpracuje všechny poznámky ze schůzek. Nový způsob plánování osobních financí. Platforma, která propojí určitý typ dodavatelů se zákazníky. Nástroj, který firmám zjednoduší nějakou administrativu.

U každého z nich můžeme během několika minut vymyslet desítky důvodů, proč by mohl fungovat. Jenže když se nám nápad líbí, velmi snadno začneme hledat hlavně důkazy, které ho podporují. Vidíme velký trh, najdeme konkurenty, kteří už podobnou věc prodávají, vzpomeneme si na několik lidí, kteří si na daný problém stěžovali, a dokážeme si představit cílovou skupinu i způsob, jakým by produkt používala.

Ani jedno ale ještě nedokazuje, že existuje dostatečně silná potřeba.

Skutečný problém má podle mě několik dalších vlastností. Lidé se s ním setkávají opakovaně, nějakým způsobem je omezuje a už dnes kvůli němu něco dělají. Věnují mu čas, peníze, pozornost nebo používají nedokonalé náhradní řešení.

To je výrazně silnější signál než věta „Jo, takovou aplikaci bych asi používal.“ Mezi tím, co lidé považují za zajímavé, a tím, kvůli čemu jsou ochotni skutečně změnit své chování, je obrovský rozdíl.

Největší nebezpečí je začít řešením

Jakmile nás napadne konkrétní produkt, přirozeně o něm začneme přemýšlet jako o řešení. Potřebujeme mobilní aplikaci. Přidáme AI asistenta. Uděláme tržiště. Vytvoříme dashboard. Automatizujeme proces.

Tím ale velmi rychle přeskočíme jednu důležitou otázku: co přesně se dnes děje bez našeho produktu?

Řekněme, že chceme vytvořit aplikaci, která freelancerům automaticky hlídá faktury po splatnosti. Mohli bychom okamžitě začít řešit napojení na účetní software, e-mailové šablony, automatické upomínky a přehled nezaplacených faktur.

Nejdřív bych ale chtěl vědět, jak freelanceri nezaplacené faktury řeší dnes, jak často se jim vůbec stává, že klient nezaplatí, a kolik času tím ztratí. Zapomínají na upomínky, nebo je jen nechtějí posílat? Je problém administrativní, nebo jde spíš o nepříjemnou komunikaci s klientem? A je celý problém dostatečně častý a bolestivý na to, aby kvůli němu začali používat nový nástroj?

Možná zjistíme, že ano. Stejně tak ale můžeme zjistit, že většina lidí řeší dvě opožděné faktury ročně a jednoduše pošle jeden e-mail. V takovou chvíli jsme si právě ušetřili několik měsíců vývoje.

Dobré hledání problému tedy nezačíná otázkou, jak postavit řešení, ale snahou co nejlépe pochopit současnou realitu bez něj.

„Líbí se mi to“ je velmi slabá validace

Když někomu ukážeme vlastní nápad, většina lidí nechce být nepříjemná. Uslyšíme „To zní dobře“, „To bych určitě vyzkoušel“ nebo „Myslím, že by to mohlo fungovat“.

Taková zpětná vazba příjemně zní, ale pro rozhodování o produktu má velmi malou hodnotu. Člověk v tu chvíli nic neriskuje. Nemusí měnit svůj současný způsob práce, platit, učit se nový nástroj ani přesvědčit kolegy, aby ho používali. Pouze hodnotí hypotetickou situaci.

Mnohem užitečnější jsou podle mě otázky na skutečné minulé chování. Kdy jste tento problém řešil naposledy? Co jste tehdy udělal? Kolik času vám to zabralo? Používáte na to dnes nějaký nástroj a kolik za něj platíte? Co vám na současném řešení vadí? Stalo se někdy, že jste problém nevyřešil vůbec, a pokud ano, co vás to stálo?

Minulé chování samozřejmě také není dokonalou předpovědí budoucnosti, ale je výrazně spolehlivější než spekulace o tom, co by člověk možná dělal.

Rob Fitzpatrick tenhle princip dobře popisuje v The Mom Test: pokud se ptáme způsobem, který respondentovi umožňuje hlavně pochválit náš nápad, pravděpodobně získáváme spíš zdvořilost než použitelná data.

Sleduji hlavně to, co už lidé dělají bez našeho produktu

Jeden z nejsilnějších signálů skutečného problému je podle mě existence náhradního řešení. Pokud lidé něco řeší přes Excel, přestože je tabulka nepohodlná, je to informace. Pokud si firma vytvořila vlastní interní proces složený ze tří nástrojů, ručního kopírování dat a pravidelného reportu, je to informace. A pokud zákazník platí za produkt, který nesnáší, protože lepší možnost nemá, je to velmi zajímavá informace.

Stejně důležité ale je, když lidé problém popisují jako zásadní a ve skutečnosti s ním nedělají vůbec nic. Nemusí to automaticky znamenat, že problém neexistuje — možná jen zatím není dostupné rozumné řešení — často to ale ukazuje, že jeho skutečná priorita je nižší, než respondent říká.

Chování totiž odhaluje cenu, kterou je člověk ochotný nést. Když věnuje každý týden tři hodiny ručnímu procesu, těch tří hodin se skutečně vzdal. Když platí 5 000 Kč měsíčně za nedokonalý nástroj, už prokázal určitou ochotu platit. A když si kvůli problému vytvořil vlastní komplikované řešení, pravděpodobně mu na výsledku opravdu záleží.

Takové signály beru podstatně vážněji než nadšení při prezentaci nápadu.

Ani existence konkurence ještě nedokazuje, že máme produkt

Konkurence je zajímavý signál. Pokud už několik firem podobný problém úspěšně řeší a zákazníci jim platí, je to určitá forma potvrzení, že trh existuje. Zároveň ale nic neříká o tom, proč by měl někdo přejít právě k nám.

Úplná absence konkurence naopak nemusí být automaticky výhoda. Může znamenat, že jsme objevili neobsazenou příležitost, ale stejně tak může znamenat, že o dané řešení není dostatečný zájem.

Proto bych konkurenci používal spíš jako další zdroj otázek než jako důkaz. Za co zákazníci současným řešením platí? Na co si stěžují? Kterou část produktu reálně používají? Kdo je jejich hlavní zákazník? A jaké alternativy existují mimo přímé konkurenty?

Poslední otázka je podle mě obzvlášť důležitá, protože konkurentem nového softwaru často není jiný software. Může jím být Excel, e-mail, WhatsApp, externí pracovník nebo jednoduše rozhodnutí problém vůbec neřešit.

Právě současný způsob chování zákazníka je standard, který nový produkt musí překonat. Nestačí tedy být lepší než další startup — musíme být dostatečně lepší než to, co člověk dělá dnes, aby pro něj změna vůbec stála za to.

Problém může být skutečný a přesto nestát za stavění produktu

Ověřit existenci problému ještě automaticky neznamená, že kolem něj vznikne dobrý byznys.

Lidé mohou problém skutečně mít, ale příliš zřídka. Mohou ho nesnášet, ale ne natolik, aby za řešení zaplatili. Může být velmi bolestivý pro stovku lidí, ale mimo tuto skupinu už prakticky neexistovat. Nebo může mít jednoduché řešení, které velký samostatný produkt vůbec nepotřebuje.

Proto bych po otázce „Existuje problém?“ pokračoval dál: Jak často nastává? Jak silný je? Kdo ho má? Jaká je ekonomická hodnota jeho odstranění? Kdo za řešení platí? Jak složité bude zákazníka získat? A existuje důvod, proč by naše řešení mohlo být výrazně lepší než současná alternativa?

Představme si problém, který firmě jednou ročně zabere dvě hodiny práce. Je skutečný, ale pravděpodobně kolem něj nechceme stavět samostatný SaaS za tisíc korun měsíčně. Proces, který deset lidí každý den ručně zpracovává několik hodin, naopak vytváří úplně jinou ekonomickou příležitost.

Dobrá produktová příležitost tedy nevzniká jen existencí problému. Potřebujeme i dostatečnou intenzitu, četnost a ekonomickou hodnotu.

Nejdřív bych chtěl důkaz závazku, až potom další pochvalu

Čím více se blížíme rozhodnutí produkt skutečně stavět, tím víc mě zajímají signály, které zákazníka něco stojí.

Pochvala nestojí nic. Vyplnit dlouhý dotazník už vyžaduje trochu času, přijít na další schůzku ještě víc. Poskytnout přístup k reálným datům nebo současnému procesu znamená větší závazek, souhlasit s pilotním provozem ještě silnější a zaplatit je samozřejmě jeden z nejpřesvědčivějších signálů vůbec.

Ne vždy můžeme před první verzí rovnou vybírat peníze. U některých produktů to není praktické a v B2B může nákupní proces trvat měsíce. Princip ale zůstává stejný: snažím se postupně získávat důkazy zájmu, které pro zákazníka něco skutečně stojí.

Pokud deset firem tvrdí, že náš produkt nutně potřebuje, ale žádná není ochotná strávit ani hodinu pilotním testem, začal bych být opatrný. Jeden zákazník, který nám aktivně poskytuje data, propojí nás s kolegy a chce vědět, kdy může začít produkt používat, může být hodnotnější než stovka pozitivních odpovědí v dotazníku.

První validace často vůbec nepotřebuje software

Tohle je podle mě důležité hlavně pro technické lidi. Když umíme stavět software, máme tendenci každý problém řešit softwarem.

Pokud ale chceme ověřit, jestli je problém skutečný, první experiment často nemusí obsahovat téměř žádný kód.

Představme si, že chceme vytvořit systém, který automaticky analyzuje marketingová data malých e-shopů a každý týden doporučí změny kampaní. Nemusíme nejdřív strávit dva měsíce tvorbou celé platformy. Můžeme získat několik e-shopů, jejich data analyzovat částečně ručně a doručit jim výsledek jako jednoduchý report. Zjistíme, jestli jej vůbec čtou, jestli podle něj něco mění a jestli v něm vidí dostatečnou hodnotu na to, aby za službu platili.

Teprve když se ukáže, že samotný výsledek hodnotu má, začíná dávat mnohem větší smysl automatizovat jeho výrobu. Podobně můžeme před vývojem použít prototyp, jednoduchou webovou stránku, ručně poskytovanou službu nebo část procesu pouze simulovat.

Cílem prvního experimentu totiž není dokazovat, že dokážeme software postavit, ale co nejlevněji získat odpověď na nejrizikovější předpoklad.

Každý nový produkt je na začátku soubor předpokladů

Když si nový produkt rozebereme, velmi rychle zjistíme, kolik věcí považujeme za pravdivé, aniž bychom je ve skutečnosti věděli.

Předpokládáme, že určitá skupina lidí má problém, že je dostatečně důležitý, současná řešení jsou špatná a lidé budou ochotni změnit svůj způsob práce. Zároveň věříme, že za nové řešení zaplatí, dokážeme se k nim ekonomicky dostat a jsme schopni produkt dodat za cenu, při které celý model funguje.

Některé z těchto předpokladů jsou téměř jisté, zatímco jiné mohou celý projekt zabít.

Proto mi přijde rozumné přestat validaci vnímat jako jeden krok typu „udělali jsme deset rozhovorů se zákazníky“ a brát ji spíš jako postupné snižování nejistoty.

Nejdřív zjistíme, jestli problém skutečně existuje, potom jak často a jak silně. Ověříme, jestli je současné řešení dostatečně špatné, a zkusíme zjistit, zda lidé skutečně chtějí výsledek, který nabízíme. Teprve potom má smysl investovat větší prostředky do technologie, distribuce a růstu.

Nemusíme samozřejmě ověřit všechno dokonale — to ani nejde. Potřebujeme hlavně zabránit situaci, kdy několik měsíců optimalizujeme technické detaily produktu, zatímco jeho nejdůležitější obchodní předpoklad nebyl nikdy pořádně otestovaný.

Nejhorší zpětná vazba je ta, kterou si sami vybereme

Jakmile začneme produkt stavět, vzniká další problém: emocionální investice.

Strávili jsme na něm několik měsíců. Máme kód, design, doménu, prezentaci a představu o tom, kam může vyrůst. Každý další důkaz, že něco nefunguje, je proto psychologicky dražší přijmout.

V takové situaci je velmi snadné vysvětlovat špatné signály způsobem, který produkt zachrání. Zákazníci se nevracejí, protože ještě nemáme dost funkcí. Neplatí, protože potřebujeme lepší cenový model. Registruje se málo lidí, protože marketing zatím není dostatečně silný.

To všechno může být pravda, ale někdy je odpověď jednodušší: produkt neřeší dostatečně důležitý problém.

Proto považuji za zdravé před experimentem definovat, co bychom považovali za úspěch a co naopak za signál, že se musíme vrátit k původní hypotéze. Jinak velmi snadno posuneme cílovou čáru pokaždé, když data neodpovídají tomu, co jsme chtěli vidět.

Validace není hledání argumentů, proč pokračovat, ale snaha zjistit pravdu dřív, než bude příliš drahá.

Jak bych problém ověřoval před větší investicí do vývoje

Neexistuje jeden proces, který funguje pro všechny produkty, ale základní logika mi přijde podobná.

Nejdřív bych se pokusil problém popsat bez jakéhokoliv řešení: kdo ho má, při jaké situaci vzniká, co člověku brání udělat a jaké následky má. Potom bych hledal důkazy v současném chování — jak lidé problém řeší dnes, kolik je to stojí a co už kvůli němu vyzkoušeli.

Dalším krokem je ověřit jeho intenzitu. Je problém jen nepříjemný, nebo dostatečně důležitý na to, aby člověk skutečně něco změnil? Teprve potom bych testoval samotný návrh řešení, ideálně co nejlevnějším způsobem: prototypem, pilotem, ručně poskytovanou službou nebo malou funkční verzí.

Pokud je to možné, snažil bych se co nejdřív dostat i k nějaké formě reálného závazku — času, datům, pilotní spolupráci, objednávce nebo platbě. Každý další krok stojí trochu víc, ale zároveň nám dává kvalitnější důkaz.

Nejde o odstranění veškerého rizika, protože to u nového produktu není možné. Smyslem je utrácet nejvíc času a peněz až ve chvíli, kdy jsme odstranili největší důvody, proč by produkt vůbec nemusel fungovat.

Jak tedy poznat, že řešíme skutečný problém?

Stoprocentní jistotu před spuštěním produktu mít nebudeme a ani ji nepotřebujeme.

Hledal bych ale kombinaci několika věcí: lidé problém skutečně zažívají, dokážou popsat konkrétní situace, ve kterých nastal, a už dnes kvůli němu nějakým způsobem platí — časem, penězi, nepohodlím nebo používáním nedokonalé alternativy. Problém se opakuje dostatečně často, jeho řešení má pro zákazníka jasnou hodnotu a při testování postupně vidíme nejen slovní zájem, ale i skutečný závazek.

Teprve potom mě začne opravdu zajímat, jak bude produkt vypadat.

Technologie je totiž až druhá otázka. Ta první zní, jestli existuje něco dostatečně důležitého, co má smysl technologicky řešit.

A čím jednodušší je dnes software vytvořit, tím důležitější podle mě tahle disciplína bude. Bariéra mezi nápadem a produktem se zmenšuje, takže vznikne ještě více technicky funkčních věcí, což ale automaticky neznamená více užitečných věcí.

Proto bych před další velkou investicí do vývoje nezačínal otázkou „Jak rychle to dokážeme postavit?“, ale mnohem méně technicky:

„Jaké důkazy máme, že někoho opravdu trápí problém, který se chystáme řešit?“

Pokud je odpověď hlavně „myslíme si“, pravděpodobně ještě není čas začít stavět.

Zdroje

• Steve Blank & Bob Dorf — The Startup Owner's Manual
• Eric Ries — The Lean Startup
• Rob Fitzpatrick — The Mom Test
• Don Norman — The Design of Everyday Things