A CB Insights évente közzéteszi a startupok kudarcainak elemzését. Évek óta az első számú ok mindig ugyanaz: "nincs piaci igény." Nem rossz végrehajtás. Nem a pénz elfogyása. Nem egy rossz csapat. A termék egyszerűen nem oldott meg olyan problémát, amiért az emberek elég ok lett volna a viselkedésük megváltoztatásához.
Ez a statisztika megdöbbentő, ha figyelembe vesszük, mennyi erőfeszítés megy a termékek fejlesztésébe. A csapatok hónapokat — néha éveket — töltnek rendszerek tervezésével, kód írásával, architektúráról vitatkozással és folyamatok tökéletesítésével. És a kudarc leggyakoribb oka az, hogy senki nem kérdezte meg, hogy mindez megold-e valós problémát.
Olyan termékek fejlesztése, amelyeket az emberek valóban akarnak, nem tehetség. Ez fegyelem. Van módszere, és a módszer megtanulható.
A leggyakoribb termékfejlesztési hiba az, hogy beleszeret valaki egy megoldásba, mielőtt mélyen megértette volna a problémát. Ez szinte általános az első termékfejlesztők körében, és meglepően elterjedt a tapasztaltaknál is. A minta mindig ugyanaz: valakinek van egy ötlete, meggyőzőnek találja, és elkezd fejleszteni. Az ügyfél utógondolat — valaki, akit meg kell győzni, nem megérteni.
Az ellenszer nem bonyolult, de fegyelmet igényel: töltsd több időt a problémán, mint amennyit szükségesnek gondolsz, mielőtt egyáltalán megoldásokon gondolkodnál. Beszélj azokkal az emberekkel, akiknek van a problémájuk. Figyeld meg a munkájukat. Értsd meg azokat a kerülőutakat, amelyeket ma használnak, és miért tökéletlenek azok a kerülőutak. Csak ezután van elég kontextusod ahhoz, hogy valóban illeszkedő dolgot tervezz.
A jó termékfejlesztés nem egyenes vonal — hanem egy hurok. A hurok minden körülfordulása lehetőség arra, hogy a feltételezéseket bizonyítékokra cseréljük. Azok a csapatok fejlesztenek olyan termékeket, amelyeket az emberek akarnak, akik ezt a hurkot gyorsan és gyakran teljesítik.
A hurok nem formalitás. Minden szakasznak van egy konkrét kimenete, amely a következő szakasz bemenete lesz. A szakaszok kihagyása — leggyakrabban a Problémától egyenesen a Fejlesztésre ugrás — az, ami olyan termékeket produkál, amelyek nem találják el a célpontot.
Nem minden probléma érdemes megoldásra. Egy jó termékproblémának három tulajdonsága van: gyakori (sokszor, nem ritkán érinti az embereket), intenzív (az emberek eléggé érzik ahhoz, hogy enyhülést kívánnak), és a meglévő megoldások valóban nem kielégítőek (nem csak kissé eltérőek attól, amit te fejlesztenél).
A hiba az, hogy az első tulajdonságra optimalizálsz, és figyelmen kívül hagyod a másik kettőt. "Az emberek időt pazarolnak a megbeszéléseken" gyako ri. De ha a fájdalom alacsony — ha az emberek elég jó megoldásokat találtak — a probléma talán nem érdemes kereskedelmi megoldásra. És ha már tizenkét eszköz csinálja, amit te csinálni akarsz, nagyon konkrét indokod kell arra, hogy a tied legyen választva.
A kutatásnak rossz híre van a termékfejlesztői körökben — lassú tanácsadókhoz, vastag jelentésekhez és senki által nem olvasott eredményekhez társítják. Ez a végrehajtás kudarca, nem a gyakorlaté. A jó termékfejlesztési kutatás gyors, konkrét és megváltoztatja, amit fejlesztesz.
A kutatás célja nem az, hogy megerősítse, a probléma valódi. Ezt már hinned kell, mielőtt komolyan befektetsz a kutatásba. A cél az, hogy elég mélyen értsd meg a problémát ahhoz, hogy tudd, mire néz ki egy jó megoldás: konkrétan kinek van a problémája, milyen kontextusban, mit próbáltak már ki, milyen szavakkal írják le, és "megoldva" számukra mire nézne ki.
A hipotézis egy konkrét, megcáfolható előrejelzés arról, amit igaznak hiszel. Tisztaságra kényszerít. Ha nem tudsz egyértelmű hipotézist leírni, még nem érted elég jól a problémát ahhoz, hogy megoldást fejlessz.
Egy hasznos termék-hipotézisnek három része van:
A jel a legfontosabb rész — és a leggyakrabban kihagyott. Előre vállalt jel nélkül minden kísérlet "valahogy működött." A csapatok módot találnak arra, hogy a kétértelmű adatokat kedvezően értelmezzék. A megcáfolási feltétel nélküli hipotézis csupán kívánság.
A fejlesztési szakasz az, amelyre a legtöbb csapat túl sok időt fordít. A cél nem a termék megépítése — hanem a minimális dolog megépítése, amely jelet ad a hipotézisedről. Ezek különböző célkitűzések, és nagyon különböző eredményeket produkálnak.
A legtöbb korai fázisú hipotézis esetén a minimum sokkal kevesebb, mint amennyit a csapatok gondolnak. Manuálisan meg tudod-e csinálni azt, amit a szoftver tenne, tíz embernek, hogy teszteld, értékelik-e az eredményt? Össze tudod-e fűzni a meglévő eszközöket és tesztelni a munkafolyamatot, mielőtt új infrastruktúrát fejlesztesz? Le tudod-e vázolni egy prototípust és átmenni rajta öt felhasználóval, mielőtt bármilyen kódot írsz?
A fegyelem itt az, hogy bármit fejleszteni előtt megkérdezd: "Mit akarok megtanulni?" és "Mi a minimum, ami lehetővé tenné, hogy megtanuljam?" A válasz szinte mindig kisebb, mint amit a csapat fejleszteni akar.
A bevezetés után — legyen az prototípus, manuális pilot vagy élesített funkció — a mérési szakasz az, ahol a csapatok leggyakrabban becsapják magukat. Megkérdezik a felhasználókat, tetszett-e nekik. A felhasználók azt mondják, igen. A csapat validáltnak jelöli a kísérletet.
Az érzelem nem jel. Az egyetlen megbízható jel a viselkedés: megtették-e az emberek az adott dolgot? Visszatértek-e? Fizettek-e? Szóltak-e másoknak?
A kvantitatív méréshez a bevezetés előtt állítsd be a mérőszámokat. Tudd, mely konkrét műveleteket követed nyomon. Állíts fel előre egy küszöbértéket — "akkor tekintjük validáltnak, ha a felhasználók X%-a Y-t végez el Z napon belül." A kvalitatív méréshez végezz strukturált utánkövetési interjúkat, ne nyílt végű elégedettségi felméréseket.
A tanulási szakasz célja a felhasználóról és a problémáról alkotott mentális modelled frissítése, nem csupán annak eldöntése, mit fejlessz legközelebb. Az ezt a lépést kihagyó csapatok adatokat gyűjtenek, de nem halmoznak fel megértést. Gyorsan hajtanak végre, de idővel nem javítják az ítélőképességüket.
Egy jó tanulási ülés azt kérdezi: Mit jósoltunk? Mi történt valójában? Mit árul el a különbség a feltételezéseinkről? Mi most a legfontosabb dolog, amit nem tudunk?
A tanulási szakasz kimenete egy élesebb problémameghatározás, egy felülvizsgált hipotézis, vagy — ha a kísérlet egyértelműen megbukott — döntés egy teljesen más irány követéséről. Mindezek az eredmények értékesek. A legrosszabb eredmény a kétértelműség: "tanultunk valamit, de nem vagyunk biztosak benne, mit tegyünk legközelebb." Ez azt jelzi, hogy a kísérlet nem volt elég konkrét.
A termékfejlesztés soha nem éri el azt a szakaszt, ahol abbahagyod ennek a huroknak a futtatását. A kérdések változnak — a korai szakaszban azt validálod, valós-e a probléma; később azt, hogy egy konkrét megoldási elem működik-e — de a struktúra mindig ugyanaz. Figyelj meg, feltételezz, tesztelj, tanulj.
Azok a csapatok fejlesztenek olyan termékeket, amelyeket az emberek akarnak, amelyeknek nem a legjobb eredeti meglátásuk van. Hanem azok, akik a leggyorsabban és a legőszintébben teljesítik a hurkot. A tanulás sebessége, nem a szállítás sebessége a versenyelőny.