Termékfejlesztésről dióhéjban

 

Kilenc bizonyítékokra épülő gyakorlat az új termékek sikerének növeléséhez

A legtöbb innovációs projekt nem egy kitűnő  ötlettel kezdődik, inkább egy olyan elképzeléssel indul, amely első látásra logikusnak tűnik, illeszkedik a vállalat meglévő képességeihez, és gyorsan lelkes támogatókat szerez magának. 

A probléma abból adódik, hogy a belső lelkesedés nagyon gyenge mutatója a külső keresletnek.

Gyakran halljuk, hogy az új termékek 80–90 százaléka megbukik, a kutatási eredmények azonban nem támasztják alá ezt a szélsőséges állítást. Robert G. Cooper összefoglalása szerint a piacra ténylegesen bevezetett termékek körülbelül 40 százaléka sikertelen. 

Amennyiben a mérést a folyamat elején kezdjük, már jóval kedvezőtlenebb képet kapunk: hét-tíz kezdeti koncepcióból átlagosan csak egy válik kereskedelmi sikerré. Sok projekt a pénzügyi céljait, a határidőt vagy az elvárt nyereséget sem éri el.

A metaanalízisek szerint az új termékek eredményességét termék-, piac-, folyamat-, szervezeti és stratégiai tényezők együttesen alakítják. Egyetlen workshop, kreativitási technika vagy agilis rituálé sem képes ellensúlyozni azt, ha a termék nem nyújt valódi ügyfélértéket, vagy a vállalat túl sok gyenge projekt között osztja szét az erőforrásait.

1. Ne a megoldás iránti lelkesedéssel, hanem a probléma bizonyítékaival kezdjünk

A termékfejlesztő csapatok gyakran már egy kész megoldással indítják el a projektet. Lehet ez egy új anyag, technológia, funkció, alkalmazás vagy egy fontos ügyfél ötlete. A következő lépésben olyan érveket kezdenek keresni, amelyek igazolják a fejlesztés szükségességét.

A helyes megközelítés megfordítja ezt a sorrendet. Mielőtt részletesen beszélnénk a megoldásról, meg kell vizsgálnunk, hogy létezik-e és eléggé jelentős a probléma.

Ennek egyik egyszerű eszköze a problémabizonyíték-interjú. Ne azt kérdezzük az ügyféltől, hogy milyen terméket szeretne, hanem kérjük meg, hogy mesélje el, mikor találkozott legutóbb a problémával. 

Vizsgáljuk meg, mi váltotta ki a helyzetet, mit próbált tenni, milyen alternatívát használt, mennyibe került neki a probléma, és miért bizonyult elégtelennek a jelenlegi megoldás.

A „Megvásárolná ezt?” vagy a „Tetszik az ötletünk?” típusú kérdések többnyire udvarias találgatásokat eredményeznek. A közelmúltban megtörtént viselkedésre vonatkozó kérdések sokkal erősebb bizonyítékot adnak.

Minden interjú után készíthetünk egy rövid Problémabizonyíték-kártyát, amely tartalmazza a cél felhasználót, a helyzetet, a problémát, annak gyakorlati vagy pénzügyi következményét, a jelenlegi kerülő megoldást és a rendelkezésre álló bizonyíték erősségét. 

Több interjú visszatérő mintázatai többet érnek, mint egyetlen különösen lelkes ügyfél véleménye.

Az ügyfél kutatás akkor a leghasznosabb, amikor problémákat, elvárásokat, követelményeket és kívánt eredményeket tár fel, és nem az ügyféllel próbáltatja megtervezni a végső megoldást. 

Az ügyfeleket az ötleteléstől kezdődően az innováció, a termék fejlesztés sok lépésébe bevonhatjuk, de járjunk el óvatosan. A leendő vevőt mindig egy autóvezetőhöz hasonlítom, aki egy körforgalomban halad és én éppen egy másik irányból próbálok ugyanabba a körbe belépni. Nem elégséges ha az autójának a jelzését nézem, és sok esetben az sem ha a vezető arcát vizsgálom, csak az autó valódi haladásának iránya adja meg azt, hogy hol lép ki az autós a körforgalomból. Ehhez hasonlóan érdemes hallgatni a vevőkre, kikérni a véleményüket, de tartsunk távolságot tőlük, az igazi haladásuk majd akkor dől el, amikor pénzt kellene adniuk a termékért.

2. Az ügyfél szemszögéből határozzuk meg a termékelőnyt

Egy termék nem attól lesz jobb, hogy több technológiát tartalmaz, újszerűbb, vagy különösen nehéz volt kifejleszteni. Akkor tekinthető jobbnak, ha az ügyfél számára érzékelhető előnyt nyújt a rendelkezésére álló alternatívákhoz képest.

A fejlesztés jóváhagyása előtt négy próbának érdemes alávetni a koncepciót.

A különbség legyen jelentős, vagyis javítson valamin, amit az ügyfél valóban fontosnak tart. Legyen érzékelhető, tehát az ügyfél lássa, tapasztalja vagy mérni tudja a javulást. Legyen jobb, mint a jelenlegi megoldás vagy kerülőút. Végül legyen hihető, vagyis a vállalat képes legyen bizonyítani az ígéretét.

Hasznos fegyelmet teremt, ha egyetlen mondatban kell megfogalmazni az értékajánlatot:

A [konkrét ügyfélcsoport] számára, amely [konkrét helyzetben] a [bizonyított problémával] küzd, termékünk [mérhető eredményt] biztosít, szemben a [jelenlegi alternatívával], mert [bizonyítható ok vagy képesség].

Ez a gyakorlat gyorsan láthatóvá teszi a homályos állításokat. Az „innovatív”, „intelligens”, „fenntartható”, „kiváló minőségű” vagy „felhasználóbarát” önmagában nem előny. Ezek csak akkor válnak azzá, amikor egy meghatározott ügyfél számára fontos eredményre fordítjuk le őket.

3. A tanulást hozzuk előre, ne a befektetést

A vállalatok gyakran késleltetésként tekintenek a korai kutatásra. Minél gyorsabban szeretnék elkezdeni a fejlesztést, a nehéz kérdéseket pedig későbbre halasztják.

A gyengén definiált projektek korábban kerülnek a fejlesztési szakaszba, később azonban specifikáció változások, műszaki meglepetések, belső viták és ismételt áttervezések lassítják őket.

Használhatunk helyette időben korlátozott front-end feltáró sprintet. Egy jelentősebb projekt esetében a csapat tíz munkanap alatt megvizsgálhatja az öt legfontosabb bizonytalanságot:

 az ügyfél- és piaci igényt, 

a versengő alternatívákat, 

a műszaki megvalósíthatóságot,

 a gyártási és ellátási feltételeket, 

valamint az alapvető gazdasági logikát.

A cél nem egy százoldalas üzleti terv elkészítése, azt kell feltárni, hogy mely állításokat kezeli a szervezet tényként megfelelő bizonyíték nélkül.

Ebben segíthet a Feltételezés Térkép. Helyezzük el a feltételezéseket két dimenzió mentén: mekkora hatással vannak a projektre, és mennyire erős bizonyíték támasztja alá őket. A nagy hatású, gyengén bizonyított feltételek kerüljenek a kutatás és a kísérletezés középpontjába.

Ez a megközelítés azt is megakadályozza, hogy a csapat mindig azt vizsgálja, amit könnyű mérni. A legfontosabb kérdés gyakran nem az, amelyhez már rendelkezésre állnak az adatok.

A sikeresebb vállalatok több figyelmet fordítanak az előzetes piaci és műszaki értékelésre, az ügyfélkutatásra, a működési koncepció bizonyítására és a pénzügyi elemzésre, mielőtt megkezdik a teljes fejlesztést. Ez a korai munka a teljes átfutási időt is csökkentheti, mert a költséges változtatások hamarabb derülnek ki.

4. Készítsünk egyoldalas termék definíciót

Az innovációhoz rugalmasság szükséges, a folyamatos bizonytalanság azonban nem jelent agilitást. Amikor a célpiac, az értékajánlat és a termékkövetelmények néhány hetente, világos bizonyíték nélkül változnak, a csapat nem alkalmazkodik, csak mozgó célpontokat kerget.

A jelentősebb fejlesztés megkezdése előtt készítsünk Egy oldalas termék definíciót. 

Szerepeljen benne a célügyfél,

 a megoldandó probléma vagy elvégzendő feladat,

 a kívánt előny,

 a jelenlegi alternatíva,

 a tervezett ár vagy gazdasági logika,

 a nélkülözhetetlen követelmények,

 a projekt által tudatosan nem kezelt területek 

és a siker mérőszámai.

Különösen fontos annak rögzítése, hogy mivel nem foglalkozik a projekt. Ez védi meg a csapatot a terjedelem fokozatos és ellenőrizetlen növekedésétől.

A definíciót nem kell örökre befagyasztani, új ügyfél- vagy műszaki bizonyíték indokolhatja a változtatást. Minden jelentős módosítást érdemes egy egyszerű változás naplóban rögzíteni, amely megmutatja az új bizonyítékot, a tervezett változást, valamint annak költségre, időre, kockázatra és ügyfélértékre gyakorolt hatását.

5. A rejtett fejlesztést váltsuk fel tanulási ciklusokkal

Sok csapat hónapokra eltűnik a fejlesztésben, majd egy majdnem kész termékkel tér vissza. Ekkor már rendkívül költséges felismerni, hogy az ügyfelek nem értik, nem értékelik vagy nem bíznak a megoldásban.

Egy erősebb működési modell a következő:

Építsd meg → Teszteld → Gyűjts visszajelzést → Módosítsd

Az első változatnak nem kell működő terméknek lennie. A vizsgált bizonytalanságtól függően elegendő lehet egy rajz, szimuláció, történetvázlat, makett, CAD-modell, anyagminta, kezdetleges prototípus vagy korlátozott minimális működő termék.

Minden iteráció egy fontos kérdésre adjon választ.

 Képes-e a felhasználó segítség nélkül működtetni a terméket?

 Valós körülmények között is érzékelhető marad-e az ígért előny?

 Hajlandó-e az ügyfél lecserélni a jelenlegi megoldását?

 Képes-e a gyártás ismételten teljesíteni a követelményeket?

A fizikai termékeket fejlesztő csapatok is alkalmazhatják az agilis módszerek elemeit. Sprintjeik általában hosszabbak lesznek, mint a szoftverfejlesztésben, és gyakran tesztelhető termék reprezentációval, nem teljesen működő termékkel zárulnak. A lényeg a fókuszált munka, a gyakori kommunikáció, az ügyfél-visszajelzés és a terv rendszeres felülvizsgálata.