A CB Insights évente közzéteszi a startupok kudarcainak okait. Évek óta az első számú ok ugyanaz: „nincs piaci igény”. Nem a rossz kivitelezés. Nem a pénz elfogyása. Nem a rossz csapat. A termék egyszerűen nem oldott meg olyan problémát, amely elég fontos lett volna az embereknek ahhoz, hogy miatta megváltoztassák a viselkedésüket.
Ez a statisztika megdöbbentő, ha belegondolunk, mennyi erőfeszítés megy a termékek fejlesztésébe. A csapatok hónapokat — néha éveket — töltenek rendszerek tervezésével, kódírással, az architektúráról való vitával és a folyamatok tökéletesítésével. És a kudarc leggyakoribb oka az, hogy senki nem kérdezte meg, megold-e mindez egyáltalán valódi problémát.
Olyan termékeket építeni, amelyeket az emberek valóban akarnak, nem tehetség kérdése. Fegyelem. Van módszere, és ez a módszer megtanulható.
A leggyakoribb termékfejlesztési hiba az, hogy valaki beleszeret egy megoldásba, mielőtt mélyen megértené a problémát. Ez szinte általános az első vállalkozásukat építő alapítók körében, és meglepően gyakori a tapasztaltaknál is. A minta mindig ugyanaz: valakinek van egy ötlete, meggyőzőnek találja, és elkezd építeni. Az ügyfél csak utólagos szempont — valaki, akit meg kell győzni, nem megérteni.
Az ellenszer nem bonyolult, de fegyelmet igényel: tölts több időt a problémával, mint amennyit szükségesnek gondolsz, még mielőtt egyáltalán megoldásokon kezdenél gondolkodni. Beszélj azokkal, akiknek megvan ez a problémájuk. Figyeld meg őket munka közben. Értsd meg azokat a kerülőutakat, amelyeket ma használnak, és miért tökéletlenek azok. Csak ezután lesz elég kontextusod ahhoz, hogy valóban illeszkedő dolgot tervezz.
A jó termékfejlesztés nem egyenes vonal — hanem hurok. A hurok minden egyes körülfordulása lehetőség arra, hogy a feltételezéseket bizonyítékokkal váltsuk fel. Azok a csapatok építenek olyan termékeket, amelyeket az emberek akarnak, amelyek ezt a hurkot gyorsan és gyakran végigjárják.
A hurok nem formalitás. Minden szakasznak van egy konkrét eredménye, amely a következő szakasz bemenete lesz. A szakaszok kihagyása — leggyakrabban a Problémától egyenesen az Építésre ugrás — az, ami olyan termékeket eredményez, amelyek nem találnak célba.
Nem minden probléma érdemel megoldást. Egy jó termékproblémának három tulajdonsága van: gyakori (sokakat érint, nem ritkán), intenzív (az emberek eléggé érzik ahhoz, hogy enyhülést akarjanak), és a meglévő megoldások valóban elégtelenek (nem csak kissé térnek el attól, amit te építenél).
A hiba az, hogy az első tulajdonságra optimalizálnak, a másik kettőt pedig figyelmen kívül hagyják. „Az emberek időt pazarolnak a megbeszéléseken” — ez gyakori. De ha a fájdalom csekély — ha az emberek elég jó kerülőutakat találtak —, akkor a probléma kereskedelmi szempontból talán nem érdemes megoldásra. És ha már tizenkét eszköz csinálja azt, amit te szeretnél, nagyon konkrét okra van szükséged, amiért éppen a tiedet választanák.
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, hogy a probléma valós. Ezt már eleve hinned kell, mielőtt komolyan beruháznál a kutatásba. A cél az, hogy elég mélyen megértsd a problémát ahhoz, hogy tudd, hogyan néz ki egy jó megoldás: konkrétan kinek van a problémája, milyen helyzetben, mit próbáltak már ki, milyen szavakkal írják le, és hogyan nézne ki számukra a „megoldott” állapot.
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.
Az építési szakasz az, ahol a legtöbb csapat túl sok időt tölt. A cél nem a termék megépítése — hanem az a minimális dolog, amely jelzést ad a hipotézisedről. Ezek különböző célok, és nagyon különböző eredményeket hoznak.
A legtöbb korai szakaszú hipotézisnél a minimum sokkal kevesebb, mint amennyit a csapatok gondolnak. Meg tudod-e csinálni kézzel azt, amit a szoftver tenne, tíz embernek, hogy kiderüljön, é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 építenél? Fel tudsz-e vázolni egy prototípust, és végigmenni vele öt felhasználóval, mielőtt bármilyen kódot írnál?
A fegyelem itt az, hogy mielőtt bármit is építenél, megkérdezd: „Mit akarok megtanulni?”, és „Mi az a minimum, amelyből ezt megtanulhatom?” A válasz szinte mindig kisebb, mint amit a csapat építeni akar.
Az indítás után — legyen az prototípus, manuális kísérleti futás vagy élesített funkció — a mérési szakasz az, ahol a csapatok a leggyakrabban becsapják magukat. Megkérdezik a felhasználókat, tetszett-e nekik. A felhasználók azt mondják, igen. A csapat igazoltnak jelöli a kísérletet.
A vélemény nem jelzés. Az egyetlen megbízható jelzés a viselkedés: megtették-e az emberek azt a dolgot? Visszatértek-e? Fizettek-e? Szóltak-e valakinek?
Mennyiségi méréshez az indítás előtt építsd be a mérést. Tudd, mely konkrét műveleteket követed nyomon. Állíts fel előre egy küszöbértéket — „igazoltnak tekintjük, ha a felhasználók X%-a Z napon belül elvégzi Y-t”. Minőségi méréshez végezz strukturált utókövető 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 építs legközelebb. Azok a csapatok, amelyek kihagyják ezt a lépést, adatokat gyűjtenek, de nem halmoznak fel megértést. Gyorsan kivitelezik a dolgokat, de idővel nem javul az ítélőképességük.
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 ér el olyan szakaszt, ahol abbahagyhatod ennek a huroknak a futtatását. A kérdések változnak — a korai szakaszban azt igazolod, hogy valós-e a probléma; később azt, hogy egy konkrét megoldáselem működik-e —, de a szerkezet mindig ugyanaz. Figyelj, állíts fel hipotézist, tesztelj, tanulj.
Azok a csapatok építenek olyan termékeket, amelyeket az emberek akarnak, amelyek nem a legjobb kezdeti meglátással rendelkeznek, hanem a hurkot a leggyorsabban és a legőszintébben járják végig. A tanulás sebessége, nem a szállítás sebessége a versenyelőny.