Continuous Product Discovery – co to je a kdy ho použít

Digitální produkt není nikdy hotov. Vždy by se mohl a měl vyvíjet s tím, jak se učíme více o našem trhu, jak se mění potřeby zákazníků či jak se nové technologie stávají dostupnější.

Lucia Marcinková

UX výzkumník

Nejlepší digitální produkty jsou tvořeny, designovány a stavěny týmem, který se skládá z designéra, produktového manažera a tech leada. Designér zastupuje uživatele a přináší podněty k tomu, aby byl produkt co nejintuitivnější a co nejlépe se používal. Produktový manažer zastupuje byznys a stará se o to, aby produkt přinášel zisk. SW inženýr přináší technický pohled a stará se o to, aby byl produkt spolehlivý, stabilní a schopný vývoje. Společně se nazývají produktové trio.

Jak se práce na digitálním produktu vyvíjela

Tak tomu ale nebylo vždy. Kdysi většina týmů fungovala výhradně tak, že se soustředili jen na vývoj nových funkcionalit a produktů. Na discovery fázi nebyl kladen téměř žádný důraz. Dělala se možná jednou ročně (spolu se zveřejněním nových funkcionalit), kdy se vyspecifikovaly konkrétní plánované projekty (nejčastěji na základě zadání managementu) a ty se přidělily vývojovým týmům. Takové týmy ale narážely na to, že vývoj mnohdy nestíhal deadliny, přesáhnul rozpočet a zákazníci nebývali s výsledky spokojeni (což se však zjistí až na konci celého procesu).

Tým vývojářů nebyl spokojen s tehdejším stavem v delivery týmech. Přišel s tzv. Agile manifestem, kde požadovali kratší vývojové cykly s častější zpětnou vazbou od zákazníků. Zároveň chtěli udržitelnější pracovní tempo místo spěchu za dalším milníkem. Dále chtěli větší flexibilitu v rámci reagování na zpětnou vazbu od zákazníků. A na závěr požadovali jednoduchost – nechtěli vyvíjet produkty, které se nakonec nepoužijí, místo toho chtěli, aby se více vykreslovalo, co se bude vyvíjet ak tomu byl kladen větší důraz. Na základě toho vznikly dnes asi nejčastěji používané modely Scrum a Kanban. 

Stále se ale naráželo na problémy. Například majitelé či manažeři měli problém vzdát se svých původních nápadů, i když se neshodovaly se zpětnou vazbou od zákazníků nebo šly zcela proti ní. Zároveň se na kratší cykly adaptovaly jen vývojové týmy a ne celé organizace, což neposkytovalo dostatečný prostor pro flexibilitu. Zákazníci přicházeli do procesu až na závěr při testování použitelnosti. A týmy byly hodnoceny na základě toho, co vytvořili a ne toho, jestli to někdo reálně používal. 

V současnosti jsou ty nejvyspělejší týmy ve fázi, kdy přichází rozhodování o tom, co vyvíjet, na základě spolupráce celého produktového týmu. Zákazníci jsou zapojeni do celého procesu a nevidí produkt až na konci. Nejčastěji jsou přímo na začátku a pomáhají s vývojem produktu již svými nápady a potřebami. Tak vlastně Continuous Discovery vzniklo.

Co to vlastně je Continuous Discovery?

Oficiální definice Continuous Discovery zní: Minimálně každý týden kontakt se zákazníky a týmem, který buduje produkt. Probíhají tak malé výzkumné aktivity ve snaze dosáhnout požadovaného cíle. 


Jeho nesporné plusy při zavedení do organizace jsou tyto:

  • detailní zjištění potřeb, obav a cílů zákazníků,
  • byznysové cíle budou v souladu s požadavky zákazníků,
  • vývoj se bude věnovat skutečně tomu, co zákazníci chtějí (nebudou se vyvíjet nepotřebné věci),
  • stakeholdeři budou zainteresováni do celého procesu a budou chápat, proč se produkt vyvíjí tak, jak se vyvíjí,
  • neustálé obnovování si znalostí o klientech,
  • ušetření času a finančních zdrojů tím, že se věnujeme správným oblastem ve vývoji.

Jako každý model i Continuous Discovery má však některé nevýhody:

  • náročnější proces adaptace ve firmách orientovaných na delivery proces,
  • náročné dostat na svou stranu vedení firmy, pokud není dostatečně vysvětlena přidaná hodnota,
  • nutnost do procesu zaškolit celý tým a detailně mu vysvětlit, jak proces funguje a jaké výhody v něm spočívají.

Jak s ním v organizaci začít?

Je důležité definovat cíl tak, aby vyhovoval byznysu, ale aby se zároveň soustředil na zákazníka a na základě řešení jeho potřeb, pain pointů či tužeb byl splněn i byznysový cíl.

Ideálně tedy mají začít tím, že definují produktový cíl. Následně definují problém pomocí příležitostí. Na závěr k vybraným příležitostem vymýšlejí řešení. K tomuto zobrazení je nejvhodnější používat tzv. Opportunity Solution Tree, viz. vizualizace. Tento strom by ale tým neměl vytvořit jen jednou na začátku celého procesu, měl by jej kontinuálně upravovat, doplňovat a měnit.

 

 

Strom pomáhá dělat průnik mezi byznysovými a zákaznickými požadavky a to tak, že příležitosti se nahlížejí z pohledu zákazníka, ale produktové trio by mělo následovat jen ty příležitosti, které podporují byznysový cíl.

Na problém by se produktové trio mělo dívat přes potřeby uživatelů, které je nutné primárně vyřešit. Také je nutné, aby se nezastavili u prvního řešení, protože nemusí být to nejlepší. Namísto toho se musí snažit vygenerovat těch řešení více a teprve potom vybrat to nejvhodnější.

Zároveň je nutné činit malá rozhodnutí často a podporovat je experimenty – díky tomu bude možné tato rozhodnutí vzít zpět a nespálit se natolik, jako bychom udělali jedno obrovské rozhodnutí, ve kterém už musíme pokračovat, i když později zjistíme, že je nesprávné (například kvůli vynaloženým nákladům).

Po zjištění toho, že nějaký nápad nefungoval, je vždy nutné se zastavit a reflektovat z jakého důvodu. Co jsme špatně pochopili ohledně uživatelů nebo jaké naše předpoklady byly nesprávné, že jsme na základě toho vytvořili toto řešení. Jinak budeme vždy jen hádat, co by fungovat mohlo a co ne.

Není nutné při tvorbě stromu postupovat jen od cílů k řešením, může to být i naopak. Na základě experimentů při řešeních si můžeme upravovat příležitosti a těmi pak ovlivňovat cíle.

Tímto článkem jsme ukončili minisérii o Product Discovery. Pokud vás toto téma zajímá, můžete mrknout na naše další články nebo si poslechnout náš podcast s Michalem Vojákem. Případně si rovnou vyzkoušet nástroj UserUP, který vám s Product Discovery pomůže.

Zdroje

Teresa Torres – Continuous Discovery Habits

 

 

O autorovi

Lucia Marcinková

UX výzkumník

V UX se specializuji na výzkumnou část. Navrhuji a realizuji výzkumy, testuji s uživateli, hledám insighty, které projekty našich klientů posunou kupředu.

Podobné

Jak sestavit Opportunity Solution Tree

Co to je Opportunity Solution Tree? Tato metoda pomáhá vizualizovat průnik mezi byznysovými a produktovými cíli a zákaznickými požadavky pomocí sepsání a…
číst více

userUP jediný nástroj pro Continuous Product…

Je to již delší dobu, co vytváříme nástroj, který by naplnil potřeby Product ownerů a UX / Produktových designérů v oblasti Continuous Product Discovery. Nyní…
číst více

O Product Discovery v Mladém podnikateli

Michal byl hostem u Jirky Rosteckého v Mladém podnikateli, kde vysvětloval co je to Product discovery a jak pomáhá při tvorbě webů, e‑shopů, aplikací a dalších…
číst více