Článek
Představte si, že by Kryštof Kolumbus při vyjednávání s různými vládami o financování svých expedic řekl něco jako: "Potřebuji peníze na první týden plavby, potom na druhý týden a pak uvidíme, kam doplujeme." Nebo, "Nyní musíme rychle stáhnout plachty (i přesto, že fouká správným směrem), protože na lodi máme spoustu námořníků a musíme jim dát něco na práci, aby se neflákali." Zní to směšně, že? Přesto se s tímto přístupem setkáváme bohužel i v rámci vývojových týmů.
Často se stává, že týmy neznají či nemají produktový cíl. Někdy dokonce neznají ani cíle firmy, které by jejich produkty měly naplnit. Nebo rychle vymýšlí úkoly pro vývojáře jen proto, aby byli "zaneprázdněni", aniž by byla dostatečně promyšlena jejich relevance. Výsledkem může být vytvoření produktu, který sice splňuje požadavky týmu, ale nemá žádný přínos pro firmu ani pro uživatele. Takový přístup může být nejen finančně nákladný, protože sice rychle vytvoří něco, co tým může představit jako výstup, ale z dlouhodobého hlediska nemá přidanou hodnotu pro nikoho.
Při tvorbě úspěšného produktu je důležité rozlišovat mezi výstupem a výsledkem. Výstup se týká konkrétních prvků, které vytváříme, jako jsou funkce nebo designové prvky. Na druhou stranu výsledek se soustředí na dopad těchto prvků na uživatele nebo zákazníky. Při tvorbě produktu je důležité nejen zaměřit se na to, co vytváříme, ale také zvážit, jak to ovlivní zážitek a chování uživatele. Tímto způsobem můžeme efektivněji identifikovat a dát prioritu věcem, které přinesou největší hodnotu uživatelům a pomohou dosáhnout produktových cílů. Zároveň dokážete upozadit činnosti, které by zaneprázdnili vývojáře na dlouhou dobu a nedodali byste opravdovou přidanou hodnotu pro uživatele.
Jednotlivé fáze Product Discovery
Proč je důležité mít stanovené správné cíle
Když máte jasně stanovený cíl, je cesta k jeho dosažení obvykle jednodušší. Častým problémem týmů je však to, že se soustředí spíše na nalezení řešení než na splnění cíle. Pokud je vaším cílem vytvořit novou funkčnost nebo dokonce celou aplikaci, tým se často zaměřuje pouze na dosažení tohoto cíle, aniž by zvažoval, zda tento výstup skutečně naplní očekávání ve firmě.
Když vytvoříte novou aplikaci, kterou však následně nepoužije mnoho uživatelů, vzniká problém. Stejně tak, pokud do aplikace přidáváte novou funkcionalitu, ale nikdo ji nepoužije, jsou tyto investice považovány za ztracené, pokud se to tedy vůbec měří. :)
Dalším častým problémem je, že produktovým týmům nastavujeme businessové cíle. Potom se může stát, že tým nechápe, jak může díky vytvoření mobilní aplikace pro správu určité služby pomoci k dosažení byznysového cíle, kterým je například zvýšení obratu firmy o 20 %. To znamená, že tým je zaměřený na vytvoření výstupu, kterým je mobilní aplikace, ale nechápe, jakým způsobem aplikace ovlivní požadovaný výsledek ve formě zvýšení obratu.
Rozdíl mezi businesovými a produktovými cíli
Produktové cíle může ovlivnit sám produktový tým a businessové cíle může ovlivnit vedení firmy.
Když se snažíme zvýšit obrat, můžeme zvolit několik strategií, jako je zvýšení ceny služby, vytvoření nového produktu nebo expanze na nové trhy. Tyto kroky obvykle nespadají do kompetence produktového týmu, který se zaměřuje spíše na interní fungování a vylepšování produktu.
To, co produktový tým může ovlivnit, jsou faktory mezi které patří například prodej uvnitř aplikace, zlepšení procesu onboardingu nových uživatelů, zvýšení uživatelské přívětivosti a další.
Pozor na feature factory
Občas se stává, že se tým dostane do situace, kdy má nekonečný seznam funkcí v backlogu a neví, co dělat jako první. Při správně stanoveném produktovém cíli by měl být tým schopen určit hlavní prioritizační cestu. Funkce, které neslouží k dosažení tohoto cíle, by měly být vytvářeny s nižší prioritou nebo vůbec. Například se může stát, že máte před sebou několik funkcí, které mají na první pohled vysokou přidanou hodnotu. Když blíže prozkoumáte jednotlivé funkce s ohledem na splnění produktového cíle, pravděpodobně zjistíte, že jedna z nich vás posune blíže k jeho splnění. Tuto funkci vyberete a ostatní odložíte na později. V situaci, kdy tým s produktovými cíli nepracuje, může snadno dojit k tomu, že prioritizuje nevhodnou funkci, protože nemůže vědět, která je ta správná.
Samozřejmě, mezi cílem a jednotlivými funkcemi by měla být zařazena ještě další vrstva a tou jsou potřeby uživatelů. Každá funkce, kterou tým plánuje vytvořit, by měla vycházet z potřeb uživatelů a v metodice product discovery používáme označení „příležitost“.
Více informací o tomto tématu můžete nalézt v článku Jak sestavit opportunity solution tree.
Dlouhé vývojové backlogy na měsíce, kvartály nebo dokonce roky jsou běžným jevem, se kterým se týmy často potýkají. Například kvůli tomu, že management firmy chce vědět, na čem bude tým v příštím kvartále nebo roce pracovat.
Přirovnání k cestě Kryštofa Kolumba může být velmi vhodné. Pokud byste se ho zeptali na přesný cíl jeho plavby, jaké kroky udělá týden po týdnu, pravděpodobně byste nedostali přesnou odpověď. A to z jednoduchého důvodu – nikdo to přesně neví. Podobně je to i s vývojem produktů. Nikdo neví přesně, jak bude aplikace vypadat za měsíc, za 3 měsíce nebo za rok. Nezapomínejte však na to, že stále pracují na stanoveném cíli, který je jejich dodávaným výsledkem. Okolnosti, za kterých se produkty vyvíjejí, jsou příliš komplexní a zahrnují mnoho faktorů. Patří mezi ně například potřeby uživatelů, požadavky firmy, vnější vlivy a omezení, včetně právních a technologických. Proto je důležité vyvíjet agilně, abychom mohli reagovat na změny v průběhu vývoje.
Avšak agilní vývoj nestačí. Je nezbytné mít jasně definovaný cíl a pravidelně ho validovat, abychom byli vždy na správné cestě. Každý týden nebo měsíc je třeba zhodnotit, jak se situace změnila, a přizpůsobit svůj postup, abychom dosáhli stanoveného cíle.
Jak dlouho by měl být nastavený jeden cíl?
To záleží :). Nejčastější období pro stanovení cílů je jedno čtvrtletí, ale může to být i půl roku nebo rok. Hodně závisí na specifických potřebách vašeho týmu a firmy.
Pokud pracujete na vývoji nového produktu, může být vhodné mít kratší období pro stanovení cílů, třeba na měsíc. Tyto krátkodobé cíle mohou sloužit k validaci prvního produktového záměru. Například: "Získat 100 potenciálních zákazníků k registraci do aplikace".
Jeden, dva či tři produktové cíle naráz?
Zde bych vám doporučil, abyste si vždy vybrali pouze jeden cíl na dané období. Produktový cíl by měl fungovat jako navigace, která ukazuje, kam by měl produkt směřovat. Tudíž by měl být prioritou pro to, co chcete a co nechcete vytvářet. Pokud určitá funkčnost nepomůže k dosažení aktuálního cíle, neměli byste se jí věnovat.
Pokud si stanovíte 2 nebo 3 cíle najednou, vaše plavidlo má náhle za úkol ve stejnou chvíli doplout do Indie, Japonska a zároveň do Austrálie. Mít více cílů v daném období může být matoucí a ztížit rozhodování o tom, na co se zaměřit.
Dalším argumentem proti stanovení více cílů může být vytvoření sekundárních cílů podporujících hlavní cíl. Například, pokud chcete zvýšit počet uživatelů, kteří projdou onboarding procesem, můžete chtít zároveň zrychlit aplikaci. Doporučuji však zvolit pouze jeden hlavní cíl a sekundární cíle považovat za příležitosti, které vám mohou pomoci k dosáhnutí tohoto hlavního cíle.
Problémem může být také to, že povedete diskuze o tom, které příležitosti patří pod který cíl. Některé příležitosti mohou spadat pod jeden cíl, jiné pod druhý, některé mohou být relevantní pro oba. Tyto diskuze jsou často zbytečné a je dobré se jim vyhnout.
Měřitelnost cíle
Vždy je nejlepší mít cíl, který je měřitelný. Dokonce i rozhodnutí o tom, o kolik chcete změnit určitou metriku, může určit strategii v tom, co by se mělo ve vašem produktu vytvářet. Například, chcete-li v příštím kvartálu zvýšit počet lidí, kteří projdou onboardingem, můžete si stanovit cíl jako zvýšení počtu lidí, kteří pojdou onboardingem o 10 % nebo 50 %.
S tímto se ale otevírá otázka, jaké číslo zvolit. Mělo by být dosažitelné a realistické, nebo naopak ambiciózní a těžko dosažitelné, aby tým měl motivaci k většímu úsilí? To je dobrá otázka, na kterou si budete muset odpovědět sami. Hodně záleží na vašem týmu a na tom, jakým způsobem k tomuto přistoupí. Pokud je pro váš tým motivující dosáhnout stanoveného cíle, je vhodné zvolit první variantu. Pokud váš tým spíše motivuje vyšší ambice a vytyčení náročnějšího cíle, pak je vhodné zvolit druhou možnost.
Doporučení na závěr
- Stanovte si správný produktový cíl, který vyjadřuje změnu uživatelského chování ve vašem produktu
- vyjděte z business cíle, ale nemějte business cíl jako to, kam produkt směřuje
- mějte jen jeden cíl na určité období
- stanovte si metriku cíle a nastavte si měření, ať můžete sledovat postup
- komunikujte váš cíl často na schůzkách, aby tým věděl kam míříte.
Ukázky cílů pro aplikace
- Zvýšit počet lidí kteří projdou onboardingem o 10 %.
- zvýšit PMF score na 40 %
- zvýšení retence uživatelů o 15 %
- zvýšení počtu uživatelů, kteří přejdou z Free verze na placenou o 20 %
- zvýšení času strávený v aplikaci o 3 minuty.
Ukázky cílů pro e‑shopy
- Zvýšit průměrnou objednávku o 10 %
- zvýšit konverzní poměr na mobilech o 10 %.
Podcast