Proč nestačí postavit dobrý produkt, když vývoj, design a marketing nefungují společně?

Dlouho jsem se na vývoj, design a marketing díval jako na tři různé disciplíny.

Vývoj řeší, aby produkt technicky fungoval. Design, aby se dobře používal. Marketing, aby se o něm lidé dozvěděli a chtěli ho koupit.

Na papíře to dává smysl. V praxi ale čím dál víc vidím, že právě tohle rozdělení vytváří část problémů, které potom firmy složitě řeší.

Vývoj postaví něco, co marketing neumí dobře prodat. Marketing přivede uživatele na produkt, který nekonvertuje. Design optimalizuje uživatelskou zkušenost bez dostatečného kontextu o tom, odkud lidé přicházejí a co od produktu očekávají. Marketing získává zpětnou vazbu od zákazníků, která se k lidem rozhodujícím o produktu dostane až o několik měsíců později — pokud vůbec.

Každá část přitom může svoji práci dělat dobře.

Problém je, že dobrý výsledek jednotlivých částí ještě automaticky nevytváří dobrý produkt jako celek.

Moderní digitální produkt podle mě není jen software, který někdo naprogramoval. Je to celý systém od prvního kontaktu člověka se značkou přes nákup a používání až po chvíli, kdy se rozhodne zůstat, odejít nebo produkt doporučit někomu dalšímu.

A pokud jednotlivé části tohoto systému fungují odděleně, zákazník ty hranice stejně respektovat nebude.

Zákazníka nezajímá vaše organizační struktura

Představme si jednoduchý e-shop.

Marketing vytvoří reklamu s určitou nabídkou. Člověka zaujme a klikne. Dostane se na web, kde ale produkt komunikuje jiným způsobem. Některé informace z reklamy musí znovu hledat, důležitá výhoda není na produktové stránce vidět a při checkoutu narazí na věc, kterou předtím nikdo nezmínil.

Z pohledu firmy mohly všechny týmy splnit svůj úkol.

Marketing přivedl návštěvnost.

Design vytvořil hezkou stránku.

Vývoj zajistil funkční checkout.

Jen zákazník nekupuje jednotlivé části systému.

Pro něj je to jedna zkušenost.

Pokud reklama slíbí jednu věc a produktová stránka komunikuje druhou, není to „problém mezi marketingem a designem“. Je to problém produktu.

Pokud zákazník dokončí objednávku a následná komunikace vůbec nenavazuje na zkušenost z webu, nevnímá to jako problém jiného oddělení. Vnímá to jako jednu firmu, která působí nekonzistentně.

To je podle mě důležitý posun v přemýšlení.

Hranice uvnitř firmy nejsou stejné jako hranice v zákaznické zkušenosti.

A čím více podle interní organizační struktury navrhujeme produkt, tím větší riziko vzniká, že zákaznická zkušenost bude rozdělená přesně tam, kde by být rozdělená neměla.

Lokální optimum může být špatné pro celý produkt

Jedna z věcí, která se děje velmi snadno, je optimalizace jednotlivých částí podle jejich vlastních metrik.

Marketing chce levnější leady.

Design chce jednodušší interface.

Vývoj chce stabilnější a technicky čistší systém.

Obchod chce více kvalifikovaných poptávek.

Každý z těchto cílů je sám o sobě rozumný. Problém je, že nejsou vždy automaticky kompatibilní.

Marketing například zjistí, že velmi agresivní nabídka dramaticky sníží cenu za lead. Z pohledu kampaně je to skvělý výsledek. Pokud ale přivede velké množství lidí s očekáváním, které produkt nedokáže splnit, může zároveň klesnout kvalita leadů, zvýšit se množství práce pro obchod a nakonec se ekonomika celé kampaně zhoršit.

Podobně může vývojář správně rozhodnout, že určitá funkcionalita by byla technicky složitá a dlouhodobě drahá na údržbu. Pokud ale jde o zásadní problém zákazníků, nestačí říct, že implementace je nepříjemná. Potřebujeme společně najít řešení, které dává smysl technicky i produktově.

Každá část systému může optimalizovat vlastní metriku a přitom zhoršit výsledek celku.

Proto mi přijde nebezpečné řídit jednotlivé disciplíny úplně izolovaně.

Nejdřív bych se ptal, jaký výsledek má vytvářet celý produkt. A teprve potom, jak k němu mají jednotlivé části přispět.

Handoffy jsou dražší, než vypadají

Velkou část problémů nevytváří samotná práce. Vytváří ji předávání práce mezi lidmi.

Marketing sepíše zadání.

Product manager ho zpracuje.

Designer vytvoří návrh.

Návrh dostane developer.

Developer zjistí, že některé věci nejdou implementovat tak, jak byly navrženy.

Návrh se vrátí designerovi.

Mezitím marketing zjistí, že se změnila nabídka.

Celý proces se rozjede znovu.

Čím více jsou jednotlivé disciplíny oddělené, tím více podobných handoffů vzniká. A každý handoff znamená možnost ztráty kontextu.

Člověk A ví, proč se něco rozhodlo.

Člověk B dostane jen výsledné zadání.

Člověk C dostane jen část zadání, která se týká jeho práce.

Po několika předáních může původní důvod zmizet úplně.

Výsledkem pak bývá známá situace: každý provedl přesně to, co měl, ale konečný výsledek stejně nedává příliš smysl.

Kontext je často důležitější než dokonale napsaný ticket

Samozřejmě můžeme celý problém řešit lepší dokumentací.

Psát detailnější zadání. Vytvářet přesnější acceptance criteria. Připravovat rozsáhlejší design specifikace.

To všechno pomáhá.

Jenže určité množství kontextu se dokumentuje velmi těžko.

Proč zákazník problém vůbec řeší? Co jsme zjistili při posledním testování? Kterou námitku nejčastěji slyší obchod? Proč konkrétní kampaň fungovala? Co už jsme zkoušeli a nefungovalo? Jaké technické omezení může ovlivnit budoucí směr produktu?

Když lidé pracují příliš izolovaně, každý má jen část obrazu.

Marketing ví něco o akvizici.

Design o chování uživatele.

Development o technických možnostech systému.

Support o problémech zákazníků.

Obchod o jejich námitkách.

Samotná kvalita těchto informací ale nestačí. Musí mezi jednotlivými částmi firmy proudit.

Jinak firma může mít obrovské množství znalostí a přesto dělat špatná rozhodnutí, protože správná informace není ve chvíli rozhodnutí na správném místě.

Nejlepší produktové rozhodnutí může přijít z marketingu

Tohle je jeden z důvodů, proč mi přijde zvláštní přemýšlet o marketingu jen jako o distribuci hotového produktu.

Marketing často sedí na velmi cenné vrstvě produktových dat.

Vidí, na jaké problémy lidé reagují. Jaká formulace je přiměje kliknout. Které nabídky fungují. Jaké otázky se opakují v komentářích. Které segmenty mají zájem a které ne.

To všechno jsou informace o produktu a trhu.

Pokud například reklama zaměřená na určitou vlastnost dlouhodobě výrazně překonává ostatní, nemusí to znamenat jen „máme vítěznou reklamu“.

Může to znamenat, že jsme našli hodnotu produktu, kterou zákazníci považují za výrazně důležitější než to, co aktuálně komunikujeme na webu.

Stejně tak může obchod opakovaně slyšet stejnou námitku. Support může řešit desetkrát týdně stejný problém. Analytics mohou ukázat, že uživatelé opouštějí produkt na stejném místě.

To nejsou izolované informace pro jednotlivá oddělení.

Jsou to vstupy do produktového rozhodování.

A nejlepší marketingový nápad může vzniknout při vývoji

Funguje to samozřejmě i opačně.

Při implementaci produktu často vznikne mnohem hlubší porozumění tomu, co vlastně dokáže.

Developer může zjistit, že určitá technologie umožňuje funkci, se kterou původně nikdo nepočítal. Designer může během práce narazit na způsob, jak výrazně zjednodušit onboarding. Product tým může při analýze používání zjistit behaviorální pattern, který marketing zatím vůbec nekomunikuje.

Pokud je marketing až poslední krok procesu — „produkt je hotový, teď ho běžte propagovat“ — všechny tyto informace musí zpětně složitě dohánět.

Mnohem efektivnější je podle mě stavět produkt a způsob jeho distribuce společně.

Neznamená to, že performance marketer musí rozhodovat o databázové architektuře nebo developer psát reklamní copy.

Znamená to, že jednotlivé disciplíny rozumějí společnému cíli a mají přístup k informacím, které jejich práci ovlivňují.

Design není jen to, co se děje ve Figmě

Podobně omezeně se někdy přemýšlí i o designu.

Design není jen vzhled interface.

Je to způsob, jakým uživatel projde produktem.

Začíná často ještě předtím, než produkt otevře.

Pokud reklama vytvoří určité očekávání, je to součást zkušenosti. Pokud landing page vysvětluje složitý produkt nepochopitelně, je to designový problém stejně jako marketingový. Pokud uživatel při registraci neví, proč po něm něco chceme, nestačí říct, že „formulář technicky funguje“.

Celá cesta má určitou logiku.

Co člověk ví v daném okamžiku?

Co chce udělat?

Jaké má pochybnosti?

Jaké informace mu chybí?

Jaký je nejpřirozenější další krok?

Tohle se netýká jen interface.

Je to produktové přemýšlení napříč marketingem, designem i technickou implementací.

Vývoj zároveň není jen exekuce požadavků

Stejný problém vzniká, když je engineering vnímán jen jako výrobní oddělení.

Někdo nahoře vymyslí funkci, designer ji nakreslí a vývojář dostane ticket.

„Postav tohle.“

Jenže technická rozhodnutí mohou zásadně ovlivnit produktové možnosti, cenu provozu, rychlost dalšího vývoje i to, jak dobře lze později měřit chování uživatelů.

Pokud vývoj přizveme až ve chvíli, kdy je všechno rozhodnuté, přicházíme o část informací, které mohly ovlivnit samotné zadání.

Technicky silný člověk často dokáže přijít s jednodušším způsobem, jak vyřešit stejný problém. Může upozornit na možnost, kterou ostatní neznali. Nebo naopak včas říct, že zdánlivě jednoduchá funkce znamená týdny práce a existuje varianta, která zákazníkovi vytvoří skoro stejnou hodnotu za zlomek nákladů.

Tohle není pouze otázka developmentu.

Je to business decision.

Produkt by měl mít jednu společnou zpětnou vazbu

Když jednotlivé disciplíny fungují odděleně, vznikají často i oddělené feedback loops.

Marketing sleduje CTR, CPC a ROAS.

Produkt sleduje aktivaci a používání funkcí.

Development sleduje chyby a technickou stabilitu.

Obchod sleduje uzavřené zakázky.

Support sleduje počet požadavků.

Každá metrika něco říká. Skutečná hodnota ale často vznikne až ve chvíli, kdy je propojíme.

Vysoké CTR a nízká konverze na webu může znamenat nesoulad mezi reklamou a landing page.

Vysoký počet registrací a nízká aktivace může znamenat, že marketing přivádí nesprávné publikum — nebo že onboarding nevysvětluje hodnotu produktu.

Rostoucí počet support ticketů po vydání nové funkce může znamenat, že technicky funguje, ale design je nepochopitelný.

Nízká konverze obchodního týmu nemusí být problém obchodníků. Může být důsledkem špatného lead generationu nebo nejasného positioningu.

Bez propojení dat může každé oddělení vidět pouze vlastní část problému a logicky dojít ke špatnému závěru.

Místo předávání práce bych preferoval společné vlastnictví výsledku

Podle mě nejde o to odstranit specializované role.

Specializace je potřebná. Dobrý designer bude v designu lepší než developer, dobrý performance marketer bude lépe rozumět reklamním systémům a zkušený engineer bude dělat lepší technická rozhodnutí.

Problém nastává, když se specializace změní v izolaci.

„Já jsem svoji část udělal.“

Tahle věta podle mě velmi často signalizuje špatně navržený způsob práce.

Protože zákazníkovi je jedno, jestli někdo dokončil svoji část. Zajímá ho výsledná zkušenost.

Místo systému:

marketing → design → development → hotovo

mi proto dává větší smysl model:

problém → společné pochopení → návrh řešení → implementace → distribuce → měření → další iterace

Jednotliví lidé mají stále své kompetence, ale pracují na stejném výsledku.

To je zásadní rozdíl.

Nejrychlejší tým nemusí být ten, kde každý pracuje nejrychleji

Na první pohled může úzká specializace působit efektivně.

Každý dělá přesně to, v čem je nejlepší.

V teorii by tak měl být celý systém rychlejší.

Jenže pokud mezi jednotlivými lidmi vzniká velké množství čekání, oprav, předávání kontextu a změn zadání, lokální efektivita jednotlivců přestává být příliš důležitá.

Designer může vytvořit návrh za čtyři hodiny místo osmi.

Pokud ale developer potom dva dny čeká na doplnění chybějícího stavu, nic jsme nezrychlili.

Developer může implementovat funkci velmi rychle.

Pokud po spuštění zjistíme, že jsme řešili špatný problém, rychlost implementace nám také příliš nepomohla.

Marketing může získat tisíce návštěvníků za výbornou cenu.

Pokud produkt není připravený je konvertovat, pouze jsme efektivněji nakoupili návštěvnost, která nepřinesla výsledek.

Rychlost celého systému tedy neurčuje nejrychlejší část. Často ji určuje místo, kde se jednotlivé části špatně propojují.

Menší týmy tady mají obrovskou výhodu

Velká firma přirozeně potřebuje větší specializaci, více procesů a jasnější organizační strukturu.

U menších týmů ale podle mě nedává smysl kopírovat jejich silosy příliš brzy.

Pět lidí nemusí fungovat jako pět oddělení.

Naopak jedna z největších výhod malého týmu je, že se informace mohou pohybovat velmi rychle. Developer může přímo slyšet zpětnou vazbu zákazníka. Marketér může rozumět produktové roadmapě. Designer může vidět reálná data z kampaní. Founder může propojovat informace napříč celým systémem.

To je obrovská rychlostní výhoda.

Jen je potřeba ji nezničit tím, že si i v malém týmu vytvoříme umělé hranice typu „tohle už není moje práce“.

V rané fázi produktu mi přijde mnohem cennější mít lidi, kteří mají hlubokou expertizu v jedné oblasti, ale současně rozumějí alespoň základům těch ostatních.

Developer nemusí být marketér.

Měl by ale chápat, jak produkt získává zákazníky.

Designer nemusí psát backend.

Měl by ale rozumět technickým omezením.

Marketér nemusí umět navrhovat interface.

Měl by ale chápat, co se s uživatelem stane po kliknutí na reklamu.

Právě tahle schopnost vidět o jednu vrstvu dál podle mě výrazně zlepšuje rozhodování.

Pro foundera je interdisciplinarita ještě důležitější

Founder samozřejmě nemusí být nejlepší člověk v každé disciplíně.

To ani není realistické.

Měl by ale rozumět jejich vztahům.

Pokud technický founder vůbec nerozumí distribuci, může strávit rok stavěním skvělého produktu, který nikdo neobjeví.

Pokud marketingově orientovaný founder nerozumí technickým trade-offům, může produkt zahltit požadavky, které vypadají obchodně zajímavě, ale vytvářejí obrovskou dlouhodobou komplexitu.

Pokud nikdo ve vedení nerozumí designu a uživatelskému chování, mohou jednotlivé funkce fungovat perfektně a celý produkt být stále frustrující.

Podle mě právě tady vzniká hodnota takzvaných T-shaped lidí.

Mají hlubokou expertizu v jedné oblasti, ale dostatečně rozumějí okolním disciplínám na to, aby dokázali dělat rozhodnutí s širším kontextem.

Nejsou nejlepší ve všem.

Ale vidí vazby, které úzce zaměřenému specialistovi mohou uniknout.

Integrace neznamená více meetingů

Když se řekne „lepší spolupráce mezi týmy“, velmi snadno z toho vznikne další pravidelný meeting.

To není to, co mám na mysli.

Pokud potřebujeme každou informaci předávat na hodinové schůzce, systém spolupráce pravděpodobně příliš dobře nefunguje.

Integrace podle mě znamená hlavně:

• společné cíle,
• dostupný kontext,
• rychlé feedback loops,
• jasné vlastnictví výsledku,
• sdílená data,
• a možnost zapojit správného člověka ve chvíli, kdy jeho rozhodnutí může ještě něco ovlivnit.

Někdy to samozřejmě meeting vyžaduje.

Často ale stačí dobře nastavené nástroje, transparentní projektové řízení, dostupná analytika, společná dokumentace a kultura, ve které lidé informace aktivně předávají dál.

Cílem není, aby všichni věděli všechno.

Cílem je, aby správný člověk měl správnou informaci ve chvíli, kdy podle ní může něco udělat.

Jak bych takový systém stavěl

Pokud firma cítí, že mezi vývojem, designem a marketingem vzniká příliš mnoho tření, nezačínal bych organizačním redesignem.

Začal bych jedním konkrétním produktem nebo zákaznickou cestou.

1. Definujte společný výsledek

Ne „marketing zvýší návštěvnost“, „design předělá landing page“ a „development nasadí nový checkout“.

Společný výsledek může být například zvýšení procenta lidí, kteří po příchodu z kampaně dokončí objednávku.

Najednou všechny disciplíny řeší stejný problém.

2. Projděte celou cestu zákazníka

Od prvního kontaktu až po požadovaný výsledek.

Kde člověk produkt objeví? Co očekává? Jaké informace dostane? Kde se musí rozhodnout? Kde může proces opustit? Co se stane potom?

Velmi často zjistíme, že největší problém neleží uvnitř jedné konkrétní disciplíny, ale na přechodu mezi nimi.

3. Propojte data

Pokud marketing vidí jen kliknutí a development jen technické eventy, každý pracuje s jinou realitou.

Potřebujeme umět sledovat zákaznickou cestu přes celý produkt a spojit akvizici, produktové chování a skutečný business výsledek.

Teprve potom můžeme rozumně rozhodovat, která změna opravdu pomohla.

4. Zkraťte feedback loop

Informace, která dorazí po třech měsících, má často výrazně menší hodnotu než stejná informace po třech dnech.

Zpětná vazba zákazníků, data z kampaní, chyby v produktu i poznatky obchodu by proto měly mít jasnou cestu zpátky k lidem, kteří mohou produkt změnit.

5. Optimalizujte celek, ne oddělení

Pokud jedna část systému zlepší svoji metriku a celkový business výsledek se nezmění nebo zhorší, nic jsme nevyhráli.

Dobrá lokální metrika je prostředek.

Ne cíl.

Produkt nekončí deploymentem

Možná největší změna v mém vlastním přemýšlení je právě tady.

Dříve jsem měl tendenci vnímat produkt jako něco, co se navrhne, naprogramuje a nasadí.

Pak začne marketing.

Dnes mi tohle rozdělení přijde umělé.

Deployment je pouze jeden moment v životním cyklu produktu.

Teprve potom začínáme získávat skutečné informace. Kdo produkt používá? Jak? Co nechápe? Za co je ochotný zaplatit? Jak se o něm dozvěděl? Kde odchází? Co mu chybí? Co oceňuje natolik, že se vrátí?

Tyto informace se mají vrátit zpět do designu, vývoje i marketingu.

A celý cyklus začne znovu.

build → distribute → observe → learn → improve

To už není lineární proces.

Je to feedback loop.

A kvalita tohoto loopu podle mě určuje dlouhodobý výkon produktu mnohem víc než dokonalost kterékoliv jedné jeho části.

Co tedy vytváří opravdu dobrý digitální produkt?

Ne nejlepší kód sám o sobě.

Ne nejhezčí design.

Ne nejlepší reklama.

Všechny tři věci mohou být výborné a produkt může stále selhat.

Dobrý digitální produkt vzniká ve chvíli, kdy se technická realizace, zákaznická zkušenost a distribuce navzájem podporují.

Marketing přivádí správné lidi a zároveň poskytuje informace o trhu.

Design převádí tyto informace do srozumitelné zkušenosti.

Engineering umožňuje produkt spolehlivě realizovat, měřit a dál rozvíjet.

Data z reálného používání se vracejí zpět a ovlivňují další rozhodnutí.

Žádná z těchto disciplín není podpůrná funkce té druhé.

Jsou to různé části jednoho systému.

A právě proto podle mě nestačí mít skvělý development, design a marketing vedle sebe.

Musí fungovat společně.

Zdroje

• Altunel, H. — Software Product System Model: A Customer-Value Oriented, Adaptable, DevOps-Based Product Model
• Massa, L., Tucci, C. & Afuah, A. — A Critical Assessment of Business Model Research
• Rajagopal — Systems Thinking and Process Dynamics for Marketing Systems
• Rothman, J. — Applying Systems Thinking to Software Product Development
• Tani, M., Papaluca, O. & Sasso, P. — The System Thinking Perspective in Open Innovation Research