Reálné příběhy jsou skvělou formou, jak předat zkušenosti a ponaučení v oblastech, kde je to obtížně předatelné z důvodu kombinace komplexity daného problému, důležitých detailů a také kontextu. Jeden z takových příběhů s vámi chci sdílet, abych předal zajímavá produktová ponaučení.
Tento příběh popisuje naši zkušenost z produktu Simplyit.cloud, který si za roky práce na něm prošel významnou evolucí. Projdeme si jeho životem od využívaného produktu s hezkými příjmy, ale nejasnou cílovkou a řešenými potřebami, až po jeho správné uchopení, postavení na jasných a vymezených potřebách klientů, jejich validaci (hledání Product – Market – Fit) a následný rozvoj produktu správným směrem. I přesto, že by se dal produkt považovat jako úspěšný (měl platící klienty a vydělával), rozhodli jsme se ho nakonec zavřít. Proč? To se dozvíte v následujícím textu.
Jak to všechno začalo?
S parťákem Radimem jsme se potkali jako zaměstnanci ve firmě Tieto (díky Tieto!), bavila nás vzájemná spolupráce a tak jsme se po odchodu z firmy nezávazně bavili o tom, jestli něco nerozjedeme společně. Chtěli jsme dělat zajímavou věc, které oba rozumíme, mohla by řešit problémy, které známe nebo neustále zažíváme a šla by škálovat na úrovni Evropy nebo ideálně i světa. Ano, neměli jsme malá očekávání 🙂 Hlavně jsme ale daný digitální produkt chtěli dělat společně, protože nás bavila vzájemná spolupráce.
Chtěli jsme předejít dvěma typickým situacím, které se firmám stávají. Vymyslí si nějaké řešení, zamilují se do něj a tlačí je všem možným klientům napříč segmenty pomocí silného marketingu a obchodu. To vše se děje bez jasné cílovky s tak nějak náhodně řešenými nejasnými potřebami. Důvodem, proč se tak dělo a děje, byla nedávná doba konjunkce, kdy i takové nedobré produkty našly své uživatele a vydělaly peníze. Těžko se tak dozvíte, že je produkt špatný, když jej nějací uživatelé používají, sice nadávají a nejsou spokojeni, ale platí za něj a vy s nimi nemluvíte, tak se o jejich nespokojenosti nedozvíte. Některé takové firmy byly i úspěšně prodány (jejich produkty pak byly často zavřeny nebo z nich byla použita jen technologie či uživatelé/leady) a jejich foundeři šíří svoji zkušenost dále, což vede ke vzniku dalších vymodlených produktů bez jasného cílení. Tomuto scénáři jsme se chtěli vyhnout.
Dalším modelem, který se na trhu děje, je konzultační nebo projektová firma, která si chce pomocí produktů diverzifikovat svůj byznys a zajistit větší stabilitu cashflow mimo projekty a konzultace. Nechtějí tedy pomoci vybrané cílovce řešit jejich problémy (zamilování se do problému), ale chtějí produkt “jen” jako nohu svého byznysu (zamilování se do produktu). V těchto firmách je často dobrá znalost domény a potřeb v oblasti působení firmy. Ne vždy se však povede vytvořit vhodné řešení – produkt (myšleno jako vhodné řešení pro palčivou potřebu jejich cílovky). Někdy je důvodem úkrok mimo svoji doménu (nevědomý), jindy je to ona silná touha po produktu jako diverzifikační noze a přesvědčení o hluboké znalosti klienta, které rozhodovatele zaslepí. V neposlední řadě je to neschopnost opustit mrtvého koně, když jsme do něj už investovali tolik peněz.
Tyto případy jsme znali i osobně ze svého okolí a z produktových konzultací a nechtěli jsme je následovat. Naší hlavní myšlenkou bylo řešit reálné a palčivé potřeby klientů, které sami známe a bolí nás. Samozřejmě jsme také chtěli, aby byl výsledný digitální produkt jednoduchý na použití a měl jasně měřitelný přínos.
První pokus
A tak přišel nápad na produkt na zelené louce. Pro jistou palčivou potřebu v oblasti správy a provozu IT služeb na trhu již existoval produkt, dokonce několik, ale neřešily dobře klientskou potřebu. My sami jsme byli uživatelé a znali painy používání těchto produktů. Snaha tedy byla obsloužit danou potřebu, ale udělat to mnohem lépe, protože jsme znali jak doménu, tak i “zážitek” z používání existujících řešení.
Tehdy jsme udělali jen základní ověření potřeb (přece byly jasné a my je znali ;)) a rychle jsme proletěli i validaci řešení (zde jsme byli přesvědčeni, že víme, jak to udělat lépe). Vše v podstatě jen v rámci pár desítek hodin. Ptali jsme se sami sebe a pár lidí v okolí jen následující:
- Chápeme produkt a jeho hranice dobře?
- Nepálí existující painy v řešení jen nás?
Víc času jsme zde neztráceli, i když se nám zde ukázala spousta nejasností a zajímavých vhledů (insights). Nechtěl jsem totiž brzdit nadšení a radost kamaráda a sám jsem byl rád, že něco vzniká společně a je to naše.
Naštěstí jsme oba dva přemýšleli podobně rychle a šli cestou Minimal Viable Product (MVP) – tedy testování trakce a zájmu v naší cílovce pomocí landing pages s minimem psaní kódu samotného řešení, což je mimochodem velmi časté nepochopení MVP konceptu. Stavěli jsme hlavně web s popsanou potřebou (správný jazyk cílovky, správné potřeby) a logikou řešení (vizuály) a ladili cílení pomocí marketingových nástrojů a kampaní. Produkt samotný vlastně neexistoval, měli jsme jen Low Fidelity prototypy pospojované dohromady, aby bylo vidět flow a použití a dalo se tím proklikat.
Výsledek naší snahy? Žádná trakce na našem webu a žádní pilotní zákazníci 🙂 Tak jsme snahu po pár měsících pokusů o prodej a adopci zastavili a bavili se, co s tímto produktem dál.
Obsluhujeme potřebu reálného zákazníka (pivot)
Jednou nohou, kterou jsme chtěli oba získat peníze na vývoj našeho produktu byly odborné konzultace v oblasti našeho hledaného řešení. Tím jsme se také snažili dále validovat zanedbané první kroky výzkumu potřeb a cílovky pro náš zamýšlený produkt, zvláště po prvotním neúspěchu MVP.
V rámci našich společných konzultací u klienta a díky denní práci Radima jsme odhalili několik specifičtějších reálných a palčivých potřeb, na které jsme nenašli odpovídající jednoduché ale zároveň přínosné řešení. Nástroje existovaly, ale byla to velká řešení stylu krabice, které musel člověk buď ohýbat nebo doprogramovat a navíc byla tato řešení drahá.
A když se u klienta, kde jsme konzultovali, ukázala daná potřeba také jako palčivá a aktuální, tak jsme kývli na to, řešení jim postavit. Měli jsme tedy jednoho(!) velkého reálného zákazníka, který tyto potřeby měl a chtěl je řešit. Díky tomu, že to byl reálný zákazník a celkem velký, tak jsem tolik netlačil na další výzkum a řekl si, že stále nebudu brzdit nadšení kamaráda a naše společné dílo (fakt mě to štvalo :)). Moje domněnka byla, že jakmile budeme mít přesněji popsanou potřebu a prototypy řešení, uděláme validaci potřeb i řešení také s dalšími potenciálními zákazníky v našem cílovém segmentu (první “chyba” :)). Takže jsme místo produktu dělali spíš specifické řešení pro daného klienta (projekt). Návrh řešení jsme s tímto jedním zákazníkem měli celkem rychle ověřené a skočili jsme hned do tvorby první verze produktu (verze 1). Cílem totiž nebylo validovat zájem a trakci na trhu (což je smysl a účel MVP, které jsme dělali dříve), ale mít nasazenou verzi, která již vykonává základní scénáře. Další chyba. Čas a prostor navíc jsme tedy využili na ladění první verze řešení u klienta a hledání a validaci Business modelu místo hledání správného místa na trhu (Product – Market – Fit).
Chybně cílený obchod a škálování
Jakmile jsme měli první verzi produktu, vrhnul se parťák do “prodeje” spřáteleným lidem, kde vnímal, že by se dal produkt použít. Ano, dal se tam použít, ale na jinou potřebu a v jiné cílovce, takže se ohýbal. Neměli jsme s parťákem mezi sebou validované a na papíře napsané, kdo je naše cílovka, komu a co přesně náš produkt řeší a neměl tedy jasné noty. Já to měl v hlavě, řídil se tím, ale na papír jsem to tehdy nedal a nevysvětlil. Něco jako validovaná produktová vize a strategie neexistovala, takže je logické, že produkt a jeho Market-Fit chápal každý z nás jinak.
Začali jsme tedy produkt ohýbat ještě víc a rozšiřovat jiným směrem, protože další zákazníci byli z jiných oblastí, z byznys konzultací a stavebnictví, navíc z jiných evropských zemí (lokalizace navíc). Jejich potřeby byly řídit provoz a úkoly týmu (každý jinak) než řídit IT služby, kde byl částečně ověřený a cílený Product – Market – Fit (PMF) našeho produktu. Já skřípal zuby, naznačoval, vysvětloval, snažil se stále udržet PMF, ale už bylo pozdě. Nechtěl jsem brzdit náš byznys, a tak nám začalo vznikat monstrum, které nedělalo nic nikomu dobře 🙂
Výsledkem bylo, že nás používalo již několik firem, většina z nich platila, další s námi ladily úpravy a rozšíření, ale produkt bobtnal nevhodným směrem. Stával se z něj neforemný blob řešící různé potřeby pro silně nesourodé klienty z jiných cílovek.
Ano, dostali jsme se do stavu mnoha firem, které jsem popsal v úvodu: nejasná cílovka, nevhodné řešení, ale platící klienti. Vypadá to jako úspěch (máte trakci a příjmy), ale produktově je to fail jako hrom → z produktu se stává neforemný rostoucí blob, který se nedá udržet pohromadě a není rozhodně dobře použitelný pro svou cílovku, žádná totiž není (“všichni” není cílovka). My si to naštěstí uvědomovali a byl to zlomový moment, kdy to vše začal jasně vidět i můj parťák. Naštěstí v tu dobu krachly námluvy s další velkou firmou, která měla potřeby zase ještě kousek jinde a provozně by vyžadovala minimální výpadky a rychlou obnovu, protože funguje 24×7 a je závislá na agentech v terénu.
To vše konečně rozjelo správné diskuze o tom, jaké potřeby tedy řešíme, komu vlastně, a co za data a vhledy k tomu máme. Udělali jsme výzkumy potřeb s cílovkou i existujícími firmami a dali si s tím načas. Na základě zjištění jsme pak hledali, jaký je tedy PMF našeho produktu. Chtělo by se říct, konečně 🙂
Změna řešení a k tomu jasné cílení (další pivoty)
Nyní udělám menší skok v čase. Prvotní velký klient, který naše řešení využíval (verze 1, pamatujete?), fungovalo mu a platil za ně, brzy zjistil, že by je potřeboval v jeho krabicovém řešení (Jira nebo Service Now). Nejen že v něm měl klíčová data, ale také tam byly uživatelé, kteří potřebovali naše informace. Naše řešení však stálo mimo tuto krabici a bylo o samostatném SaaS produktu a integrační sadě APIs do této “krabice” (druhý produkt, kam se museli uživatelé přihlásit).
Kdybychom tehdy ověřili potřeby víc do šířky a validovali také myšlenku řešení (testování s klientem nad prototypy), přišli bychom na to, že řešení musí mít jinou formu a být přímo v krabici. My však spěchali hned s verzí 1, tak jsem na tyto kroky netlačil a vrhli jsme se na doručování.
Jelikož původní verze 1 nestála zase tolik peněz ani času (nižší stovky tisíc) a nebyla tolik technicky náročná, rozhodli jsme se ji přepsat do Jiry nebo Service Now. No jo, ale náš SaaS produkt (tady už neforemný blob) používali i další uživatelé z jiných firem s jinou potřebou … Co teď s tím?
- Nechat a rozvíjet 2 produkty nebo ten původní zavřít?
- Co bude s našim vývojovým týmem, když produkt zavřeme (jiná technologie a nutná znalost krabice)?
Rozhodli jsme se rozseknout oba problémy jedním rozhodnutím. Uděláme pivot a rozhodujeme se pro jasnou cílovku a řešení v rámci Jira ekosystému, kde integrujeme náš očesanější produkt jako Jira aplikaci a díky Atlassian Marketplace můžeme i cílit na širší segment se stejnými potřebami v rámci celého světa. Ostatní klienty původního produktu, kteří ale měli jiné potřeby a neseděli našemu cílení, ukončíme. Tým jsme rozpustili, pomohli jim najít práci jinde a na vývoj si najali externí agenturu s hlubokou Jira znalostí.
Konečně jsme se tedy dostali k jasně vymezenému segmentu se stejnými potřebami a měli jsme pro něj vhodný produkt tam, kde jej klienti potřebují (rozuměj přímo “v krabici”). Hurá, vznikl tak konečně dobrý produkt, za který jsou klienti ochotni platit. Platit byli ochotni i předtím, ale produkt nebyl dobrý 🙂
Váš produkt musí být lepší než současné řešení
Ani to ale ještě na úspěch produktu nestačí, protože váš produkt musí danou potřebu řešit o hodně lépe než stávající řešení (i než Excel nebo tužka a papír). Kromě “snadnosti použití” musí mít i něco navíc. “Máme to hezčí, na jednom místě a v digitální formě” není tou přidanou hodnotou 🙂 Aspekt násobně větší hodnoty než stávající řešení byl posledním bodem, o kterém jsme věděli a potřebovali zde zabrat.
Sice jsme měli následující:
- jasně cílenou potřebu k řešení a znalost cílovky,
- přímou cestu k cílovce (Jira Marketplace),
- jednoduchý produkt integrovaný v krabici (Jira),
- snadno použitelné řešení (dobré CX a logika použití),
- automatické nastavení a onboarding (občas haprovalo, ale na tom jsme makali),
Naše řešení ale bylo víc na úrovni evidence a základních funkcí, chyběla vrstva nad tím, která by vytvořená data více utilizovala a přidala klíčovou hodnotu, např. anonymizovaný benchmarking, analytika a predikce nad IT službami, výpadky a používáním služeb, například:
- Trend incidentů s IT službou X roste a je spojený s komponentou / dodavatelem Y, zaměřte se na ni / na něj.
- Klienti vaší velikosti a vašeho typu mají výpadky o X% nižší/vyšší (anonymizovaný benchmarking).
- Brzy vám končí smlouva s dodavatelem X, měli byste ji obnovit nebo změnit.
- Objemy smluv per dodavatel X dosahují hodnoty XX EUR a bylo by vhodné zamyslet se nad diverzifikací.
Chyb v onboardingu a chybějícího vytěžování dat jsme si byli vědomi a makali na nich… Právě tato analytická a prediktivní vrstva navíc vycházela jako hlavní přidaná hodnota. Tak jsme ji řešili, pracovali na možných rozšířeních a mezitím přišly externí AI nástroje a schopnosti krabic s AI schopností uvnitř. Proto jsme se nakonec rozhodli produkt zavřít, protože jsme to sami uměli udělat jen o trochu lépe a jednodušeji.
Zanikl tedy důvod, aby nás uživatelé používali (umět řešit danou potřebu výrazně lépe než stávající řešení), respektive naše výhoda už nebyla tak významná. To je výhoda i nevýhoda platforem a Marketplaces. Dostanete se tam jednoduše, dobře se škáluje, ale platforma může vaše úspěšné funkce integrovat do svého řešení a vám rázem odpadne velký (nebo celý) revenue stream.
Kontinuální rozvoj produktu, průběžné validování potřeb cílovky (mohou se měnit) i formy vašeho řešení (nemusí už vyhovovat) jsou klíčem k dlouhodobě trvajícímu úspěchu produktu na trhu. To jej bude odlišovat od jednorázového projektu pro jednoho klienta (třeba velkého) i neforemného blobu, jehož rozvoj se vám vymkl z rukou a nikdo z něj není nadšený (kromě vás :)).
Neúspěch produktu znamená úspěch jinde
Náš produkt nás stál za ty roky vyšší stovky tisíc korun, zisk jsme měli a celkově jsme skončili v černých číslech, produkt generoval poptávku po dalších službách, takže pomohl i jinak. O peníze jsme nepřišli, ale i přesto šlo mou optikou o neúspěšný produkt. Kdybych prudil a nehledě na kolegovo (i moje) nadšení to chtěl dělat hned správně (jak sám učím firmy a chtěl tak dělat), tak jsme ušetřili rok a půl času, balík peněz a mohli už dávno vydělávat Jira appkou.
Kdybych v tom však byl důsledný, tak už nyní firmu nemáme a skončilo by i naše přátelství. Nám ale popsaný kostrbatý průběh tvorby produktu přinesl úspěch jinde. Přátelství zůstalo, stejně jako společná firma. Sice ne produktová, ale konzultantská a bodyshopová v oboru, kde jsme měli PMF našeho produktu. V neposlední řadě má Radim díky těmto “nesprávným produktovým krokům” skvělou práci u jednoho z našich původních zákazníků. Nabídka totiž přišla na základě úspěšných konzultací a bodyshopu.
Za sebe beru celý příběh velmi poučně a v širším kontextu jako úspěch. Někdy je pro vás důležitější uchovat přátelství než dělat věci správně (např. metodicky) a i při “nesprávné” cestě se mohou otevřít jiné možnosti a přínosy, jako se to stalo nám. Náš produkt byl sice neúspěšný, ale cesta a příležitosti kostrbaté cesty vše převážily a zanechaly za sebou úspěšnou firmu s jiným “produktem”.
Produktová ponaučení z našeho příběhu
- jeden klient (ani veliký) není definovaná cílovka 🙂 je to stále jen projekt pro jednoho klienta
- zaplacená první verze vás může svést na scestí (specifický projekt místo produktu)
- validace a vymezení potřeb a cílovky dělá divy (“děláme produkt pro všechny”, “všichni jsou naši zákazníci” je cesta do pekel)
- MVP pomáhá dobře validovat trakci, cílovku i zárodky byznys modelu bez jediného řádku kódu vašeho řešení (bacha na typické nepochopení MVP vs. verze 1)
- nezapomeňte validovat vhodnost a formu řešení (má to být součást něčeho, má to fungovat samostatně, integrovat se někam? konzumuje data ten, kdo je vytváří? apod.)
- tvořte a nasazujte řešení postupně v postupných přírůstcích (verzích) a validujte si, zda a jak funguje, určitě nečekejte s vydáním až na finální obrovskou verzi! (nás tento inkrementální přístup opakovaně zachránil)
- váš produkt musí být násobně lepší než existující řešení (my to nestihli dotáhnout, protože AI)
- obchod potřebuje dobře vydefinovanou cílovku, jinak vám přinese nevhodné zákazníky a z toho už se těžko utíká, zvlášť tlak na počáteční příjmy vás bude nutit brát všechny (to ukazuje na chybějící Product – Market – Fit)
- udržet přátelství nebo dělat produkt správně je velké a náročné dilema – pozor na něj a pozor na to, s kým do podnikání jdete (já dal přednost přátelství a dodnes jsem za to rád)
No a pokud jste konzultačka nebo projektová firma, která chce produktizovat, tak kromě výše uvedeného určitě vsaďte na více karet (validujte a rozvíjejte ideálně 3 nápady/produkty), tím minimalizujete riziko neúspěchu.
Se začátky v produktové roli vám může pomoci i tento rozvojový návod pro produktové role nebo naše produktová akademie.
Máte k tomu co říct?