Nem minden termékfejlesztés van sikerre ítélve, de a kudarcnak ára van

Az eredményes termékfejlesztés titka nem (kizárólag) a jó fejlesztői gárda. Hiszen a konkrét fejlesztést megelőző stratégiai lépéseken legalább annyi múlik, mint a termék vagy szolgáltatás elkészítésének módján.

Érdekes számadat következik: az új termékek akár 40-90%-a nem (teljesen) felel meg a piaci elvárásoknak. A legtöbb új kezdeményezés tehát kudarcra van ítélve. Ebből adódóan talán nem meglepőek a Harvard Business Review statisztikái, mely szerint az új termékek mintegy 72%-a nem teljesíti a bevételi elvárásokat.

És az egészben a legfájóbb, hogy mindez nem azért van, mert ezek a termékek alapjaiban véve rosszak. Sokkal inkább a nem optimális folyamatok, a félrevezető gondolkodásmód, és a rosszul felépített struktúrák miatt.

A termékfejlesztési bukásokkal ráadásul nem is maga a kudarc a legnagyobb gond. Hanem az ehhez kapcsolódó tanulás költsége.

Amikor tehát a kudarc esélyét igyekszünk csökkenteni, valójában költséghatékonyabbá (és a piaci igényeknek megfelelőbbé) tesszük a termékfejlesztést.

Lássuk, melyek azok a termékfejlesztési hibák, amelyeket elkerülve drasztikusan növelheted a siker esélyét.

1. fejezet

A 7 leggyakoribb termékfejlesztési hiba

Ezek azok a legtöbbek által elkövetett, mégis viszonylag egyszerűen elkerülhető termékfejlesztési hibák, amelyekkel jelentősen csökkenthető a kudarc esélye.

1. Túl korán lépni a termékfejlesztés fázisába

A jó termékfejlesztés első lépése: felkutatni azt a piaci igényt, amely nincs megfelelően (vagy egyáltalán nincs) kielégítve. Ezután a kutatási fázis eredményeiből meghatározzuk az ideális termék struktúráját, formáját. Az így meghatározott termékötletet pedig átveszi a fejlesztés, elkészíti a végső gyártásra szánt tervet, prototípust készít, teszteli, majd a visszajelzések alapján továbbfejleszti azt.

De tudjuk, hogy a mindennapokban nehéz tartani magunkat a tankönyvekben megfogalmazottakhoz. A határidők, a költségkeretek és egyéb nyomásokkal a vállunkon csábító kihagyni néhány lépést, hogy mielőbb a fejlesztési szakaszra ugorjunk. Ennek a csábításnak kell mindenképpen ellenállni.

A kutatási és a koncepcióalkotási fázis a fejlesztési fázis alapjai. Enélkül a termékfejlesztőkre bízni egy ötletet olyan, mint taktikai utasítás nélkül pályára küldeni a csapatot, mondván: „rúgjunk több gólt, mint az ellenfél.”

2. A fejlesztés visszajelzések nélkül zajlik

Roppant kockázatos visszhangkamrában terméket fejleszteni, a potenciális vevők és felhasználók (és úgy általában bárki) véleményét figyelmen kívül hagyva. A legnagyobb mértékben ezzel növelhető a kudarc esélye.

Pedig ez a buktató viszonylag egyszerűen elkerülhető. A folyamat minden pontján érdemes feedbacket gyűjteni. Azoktól is, akik használni fogják a terméket, nem csak munkatársaktól és ismerősöktől – habár az ő véleményük is fontos.

A neheze pedig csak ezután jön: el kell engednünk az egónkat, és el kell juttatnunk ezeket a visszajelzéseket a termékfejlesztőinknek.

3. Az MVP nem elég minimum

Vagy egyáltalán nincs.

MVP-nek nevezzük azt a legkisebb egységet a termékfejlesztés során, amiből a legtöbbet tanulhatunk. Enélkül a termékfejlesztés költségesebb és időigényesebb – ráadásul semmi sem garantálja, hogy a fejlesztésre szánt idő és pénz végül nem vész kárba. Egy jó MVP mentén validálhatjuk az elképzeléseinket, valamint hasznos visszajelzéseket kaphatunk a potenciális vevőktől termékfejlesztési szinten is.

Nemcsak az MVP teljes hiánya lehet végzetes hiba, hanem az is, ha a prototípus nem a minimumra koncentrál.

De mit értünk ez alatt?

Személyes tapasztalat, hogy sokan túlfejlesztik az prototípust, ezzel épp annak lényegét elvéve. A jól funkcionáló MVP ugyanis egyfelől elég értékes ahhoz, hogy az emberek kezdeti fázisban is hajlandóak legyenek pénzt adni érte. Másfelől elég jövőbeni előnnyel (future benefit) kecsegtet az early adopterek számára. De semmiképp sem tekinthető végleges terméknek. Hiszen épp az a feladata, hogy megfelelő mértékű visszajelzést generáljon a termék- vagy szolgáltatásfejlesztés munkájának segítéséhez.

Nézzünk meg egy példát: ha 0-24-ben működő automatizált chat supportot szeretnél a szolgáltatásod mögé, az MVP nem az, hogy valóban lefejleszted ezt az automatikus rendszert. Hanem például az, hogy egy néhányhetes periódusra felveszel 3-4 ügyfélszolgálatost, akik váltott műszakban a nap 24 órájában ellátják a chat supportot.

Ez ugyanis költséghatékonyabb megoldás, mint a teljes rendszert lefejleszteni, előzetes validáció nélkül. Ha pedig látod, hogy van rá igény, a felhasználói visszajelzések alapján nekikezdesz a fejlesztésnek.

Szintén probléma lehet, ha az elkészült prototípussal túl sok customer jobot (az ügyfél által vágyott állapot eléréséhez végzendő feladat) akarunk megoldani. A prototípusoknak, MVP-knek specifikus kérdéseket kell megválaszolniuk. Ha egynél több kérdésre keressük a választ, érdemes szétbontanunk, és külön prototípusokként tesztelnünk őket, hogy minden kérdésünkre megfelelő választ kapjunk.

Az MVP egy újra és újra ismétlődő folyamat: azonosítsd a legkockázatosabb feltevéseid, teszteld a lehető legkisebb egységenként, és módosítsd a teszteredmények alapján.

Jim Brikman

4. „Megoldjuk házon belül”

A Business Model Canvasben sem véletlenül kapott helyet a Kritikus Partnerek oszlop. A költséghatékony, dinamikus fejlesztés alapja, hogy ki tudjuk szervezni azokat a részfeladatokat, amelyek házon belül túl időigényesek és/vagy költségesek lennének.

Mindez a költségterv szempontjából is elemi fontosságú. Egyes fejlesztői számítások alapján a termék gyártási költségeinek körülbelül 70%-át a fejlesztési szakasz elején meghozott tervezési döntések határozzák meg. Azaz már az ötletelési fázisban tudnunk kell, milyen beszállítókkal, elosztói hálózattal és gyártási partnerekkel akarunk együtt dolgozni.

Ez a jelenség azonban nemcsak a kiszervezés kérdését tárgyalva fontos.

Előfordul ugyanis, hogy a egyes vezetők – vagy egy szűk projektcsapat – nem von be más osztályokat a fejlesztési folyamatba. Egyedül akarja megoldani. Ezzel egy olyan szűk véleménybuborékot vagy visszhangkamrát alkotva, amely elzárja a fejlődéshez szükséges „oxigént” az ötlettől. Így az a legtöbbször el sem éri a végső – a piaci igényeket maximálisan – kielégítő formáját.

5. Vevő és felhasználó közti különbség figyelmen kívül hagyása

Nem minden esetben a vevő használja a terméket. Ezért elemi fontosságú, hogy már a tervezési fázisban elkülönítsük a vevőket a userektől (felhasználóktól). A tévhitekkel ellentétben ugyanis a vásárlási döntés folyamata nem ér véget ott, ahol a kassza csörög. Hiszen a felhasználói élmény hosszú távon a legjobb értékmérő.

Ha ugyanis a termék használat közben bukik meg, az üzleti modell is gyorsan bedől, nem jutunk el a korai többség által beindított bevételbeli robbanásig. Éppen ezért kell már a tervezési fázisban különbontani a vevőt és a felhasználót, és figyelembe vennünk mindkét csoport igényeit, mielőtt briefelnénk a fejlesztőcsapatot.

6. Összekeverni a termékelőnyt a terméktulajdonsággal

A reggeli kávé koffeintartalma egy terméktulajdonság (feature). Az, hogy a kritikus napszakban (például a reggeli meeting során) éles leszel tőle, már termékelőny (benefit). A vevőket – és a felhasználókat különösen – elsősorban a termékelőny mozgatja, nem a -tulajdonság.

A termékfejlesztők számára különösen egyszerű előtérbe helyezni a termék tulajdonságait, annak előnyeivel. Hiszen a tulajdonságokat fejlesztik. A kristálytiszta, egyszerű és vonzó értékajánlat azonban segít, hogy a fejlesztők megértsék, milyen igényeket kell kiszolgálnia a készülő terméknek.

És bár sokszor úgy tűnik, hogy a termékelőny csak a vevő számára lefordított terméktulajdonság, ez tévedés. Érezhető a különbség, ha az egyedi termékajánlatról (USP) szóló cikkünk példáját vizsgáljuk meg. Hiszen nem mindegy, hogy a tóparti fürdőzésre vágyóknak egy újabb vasúti sínt építünk Siófokig, vagy felújítjuk a Lupa-avat.

7. Nem számolni a sikerrel

Kényelmes helyzetnek tűnhet, ha bejön a számításunk, de valójában nem mindig az. A tervezési folyamat során ugyanis a sikerrel is számolnunk kell. Ha ugyanis a termék berobban, az ellátóhálózat viszont képtelen ekkora mértékű megrendelésnek eleget tenni, a siker könnyen kudarcba fordulhat. (Gondoljunk csak a neves külföldi előadók koncertjegyeit értékesítő weboldalak hirtelen terhelés miatti leállására, vagy a Neptun szemeszterenkénti vesszőfutására.)

Az ilyen bakik derékba törhetik az ötlet skálázhatóságát. Ezzel pedig a megtérülési mutatók is lefelé görbülnek. Hiszen az így keletkező pluszköltségek (pl. új szerverek vagy plusz gyártási kapacitás bérlése, expressz szállítás finanszírozása) mellett komoly potenciális bevételtől esünk el.

Egyértelműen látszik, hogy a legtöbb termékfejlesztési hiba elkerülhető, ha ragaszkodunk a tudatos, következetes és szisztematikus tervezéshez. Máskülönben a termékfejlesztés inkább sötétben tapogatózás és tippjáték, mint tervezhető folyamat.

Ingyenes anyagainkkal igyekszünk egyszerűbbé és átláthatóbbá tenni az ezzel kapcsolatos stratégiai folyamatokat is. Ha bármiben elakadnál, esetleg kérdésed van, írj bátran, válaszolunk. Ha pedig szeretnél mielőbb a tettek mezejére lépni, érdemes egy pillantást vetned az Üzleti Modell Innováció workshopunkra.