Jak navrhnout MVP produkt, který obstojí

První verze produktu často selže ještě před prvním řádkem kódu. Ne proto, že by tým neuměl vyvíjet, ale protože se snaží postavit příliš mnoho věcí najednou. Otázka, jak navrhnout MVP produktu, proto není otázkou, jak co nejvíc osekat zadání. Jde o to vybrat nejmenší funkční celek, který zákazník skutečně použije a který firmě přinese ověřitelnou odpověď.

MVP není prezentační web, klikací obrazovka ani formulář, který končí v e-mailu. U B2B produktu obvykle znamená přihlášení uživatelů, vlastní data, administraci a jeden dokončený pracovní proces od začátku do konce. Teprve taková verze ukáže, zda zákazník řešený problém opravdu má, zda za řešení zaplatí a kde produkt v praxi naráží.

Začněte problémem, ne seznamem funkcí

Zakladatelé a produktoví vlastníci často přicházejí se seznamem obrazovek: dashboard, notifikace, exporty, role, integrace, mobilní aplikace. To všechno může být později správně. Na začátku ale potřebujeme vědět, jakou konkrétní práci má produkt uživateli ulehčit.

Dobrá definice problému je konkrétní. Například personální agentura dnes eviduje kandidáty v tabulkách, komunikaci vede v e-mailu a neumí rychle zjistit, kteří lidé odpovídají nové poptávce. Nejde tedy primárně o potřebu „vytvořit CRM“. Jádrem je rychle přiřadit vhodné kandidáty ke konkrétní zakázce a udržet u toho aktuální informace.

Takové vymezení hned odfiltruje funkce, které mohou počkat. První verze potřebuje umožnit založit kandidáta, založit poptávku, vyhledat shodu, zaznamenat stav a pracovat s přístupem jednotlivých uživatelů. Pokročilé reporty, automatické kampaně nebo rozsáhlé napojení na další systémy mohou být hodnotné, ale nejsou nutné k ověření hlavního procesu.

Pomáhá položit si tři nepříjemné otázky. Kdo produkt použije jako první? Jakou činnost v něm dokončí? A co se musí stát, aby bylo zřejmé, že výsledek má pro jeho firmu hodnotu? Pokud na ně nelze odpovědět bez obecných formulací, rozsah zatím není připravený pro vývoj.

Jak navrhnout MVP produktu kolem jednoho pracovního toku

Nejsilnější MVP má jeden hlavní pracovní tok. U fakturačního systému to může být cesta od přijetí podkladu přes kontrolu údajů až po vytvoření a schválení faktury. U SaaS pro obsluhu klientů může jít o založení požadavku, jeho přiřazení a uzavření.

Tento tok si nejprve popište běžným jazykem, bez technologie. Kdo akci zahajuje, jaká data zadává, kdo na ni navazuje, co se uloží a jak poznáme dokončení? Teprve potom má smysl rozhodovat o obrazovkách, databázi nebo integracích.

Důležitý rozdíl je mezi jednoduchostí pro uživatele a zjednodušením, které znehodnotí produkt. Pokud například systém automatizuje schvalování dokumentů, nelze vynechat historii změn jen proto, že ji uživatel nevidí na úvodní obrazovce. Bez ní může vzniknout provozní nebo odpovědnostní problém. MVP nemusí umět vše, ale musí zvládnout svůj slíbený proces spolehlivě.

U každé funkce si ověřte, do které ze tří skupin patří. Buď umožňuje dokončit hlavní pracovní tok, chrání jeho správnost a bezpečnost, nebo jen zvyšuje komfort. První dvě skupiny do MVP obvykle patří. Třetí je nutné posuzovat přísně. Někdy je komfort podmínkou přijetí produktu, například když uživatel musí každý den rychle dohledávat velké množství záznamů. Jindy jde jen o známý zvyk ze zavedených nástrojů.

Minimum neznamená provizorium

Příliš často se MVP chápe jako jednorázový experiment, který se později zahodí. To bývá drahé rozhodnutí. Pokud první uživatelé produkt přijmou, potřebujete na jejich zpětnou vazbu navázat, ne přepisovat celé řešení ve chvíli, kdy se ukáže první obchodní příležitost.

Proto stavíme MVP jako reálný základ produktu. Má vlastní databázi, přihlášení, správu oprávnění odpovídající danému scénáři, administraci a nasazené prostředí. Neznamená to přidat vše, co by jednou mohl potřebovat podnikový systém. Znamená to nepodcenit věci, které rozhodují o důvěře uživatelů a provozuschopnosti.

Rozsah technického základu závisí na oboru. Produkt pracující s osobními údaji bude potřebovat jinou úroveň ochrany než interní nástroj pro úzký okruh uživatelů. Systém napojený na účetnictví musí od začátku řešit chybové stavy a dohledatelnost dat. A aplikace, která má obsloužit několik zákaznických organizací, musí mít jasně oddělená data a přístupy.

Nejde o přehnanou architekturu. Jde o vědomé rozhodnutí, které části nelze levně doplnit později. Datový model, oprávnění a způsob práce s citlivými informacemi patří mezi věci, které se vyplatí navrhnout správně hned. Barvu grafu na dashboardu nebo pátý typ exportu můžete přidat, až si o ně uživatelé řeknou.

Rozhodujte podle rizika, ne podle hlasitosti požadavku

Nejvíc požadavků obvykle nevzniká z dat, ale z představ. Někdo viděl funkci v jiném produktu, obchodní tým ji slíbil potenciálnímu zákazníkovi nebo se zdá, že bez ní aplikace nebude působit kompletně. To ale není důkaz, že patří do první verze.

Přednost mají rozhodnutí, která snižují největší riziko projektu. Může jít o nejistotu, zda uživatelé přijmou nový proces, zda funguje klíčová integrace, zda lze získat potřebná data nebo zda bude dávat smysl cenový model. Funkce, která žádné z těchto rizik neověřuje, nemusí být součástí MVP.

Prakticky funguje jednoduchá věta u každého požadavku: „Bez této funkce uživatel nedokončí hlavní úkol, nebo se nedozvíme něco zásadního o produktu?“ Pokud ne, patří do backlogu, ne do první dodávky.

To vyžaduje disciplínu i na straně technického partnera. Naším úkolem není bez komentáře naprogramovat každé přání ze zadání. Potřebujeme otevřeně říct, co přináší hodnotu teď, co je rozumná příprava do budoucna a co by pouze prodloužilo cestu k prvnímu reálnému uživateli.

Návrh ověřujte na reálných situacích

MVP není hotové ve chvíli, kdy projde interní ukázka. Skutečný test začíná, když jej lidé použijí na vlastních datech a ve svém běžném pracovním dni. Právě tehdy zjistíte, že chybí důležitý stav, pojmenování není srozumitelné nebo že jeden krok vyžaduje informaci, kterou uživatel ve skutečnosti nemá k dispozici.

Před spuštěním proto projděte několik konkrétních scénářů. Zkuste běžný případ, neúplná data, opravu chybného záznamu i situaci, kdy jeden uživatel předává práci druhému. U B2B aplikací bývá právě předání odpovědnosti mezi lidmi místem, kde se původně jednoduchý proces začne komplikovat.

Po spuštění nesbírejte jen obecné dojmy. Sledujte, zda uživatelé dokončí hlavní tok, kde se zastavují, co obcházejí mimo systém a jaké informace si stále vedou bokem. Jedna opakovaná ruční obezlička má větší váhu než deset neurčitých nápadů na další obrazovky.

Rozsah musí být viditelný pro všechny

Dobře navržené MVP má jasné hranice. Každý účastník projektu by měl rozumět tomu, co první verze umí, co vědomě neumí a proč. Bez toho se do projektu nenápadně vrací funkce, které byly původně odložené, a termín i rozpočet se začnou měnit bez skutečného rozhodnutí.

Pomáhá mít popsané konkrétní uživatelské role, hlavní pracovní tok, data, která systém spravuje, a pravidla pro výjimky. K tomu patří také seznam věcí mimo rozsah. Není to byrokracie. Je to ochrana soustředění, která umožní produkt skutečně dokončit.

První verze nemusí působit velkolepě. Má být dostatečně dobrá na to, aby ji konkrétní zákazník zapojil do práce a aby vám její používání dalo pravdivou zpětnou vazbu. Když MVP stavíte jako funkční obchodní nástroj, nikoli jako zmenšenou kopii budoucí platformy, každé další rozhodnutí bude vycházet z reality místo z dohadů.