A termék megvalósítása minden termékfejlesztés legmunkaigényesebb folyamata. Ilyenkor válik az ötlet kézzelfogható termékké. Gyakori hiba, hogy egy frissen induló cég egyenesen a termék megvalósításával kezdi a termékfejlesztés folyamatát, kihagyva a fontos előkészítő lépéseket. Alapszabály, hogy a termék megvalósítása csak az ötlet kiértékelése és a piackutatás, de legfőképpen a termék project charterének megírása után kerülhet sor.

Mi a project charter?
A project charter többek közt összefoglalja, hogy milyen feladatokat lát el a termék, milyen feladatokat nem lát el, a feladatokat milyen módon valósítja meg, és mik azok a kritériumok, amiknek mérésével megállapítható, hogy a termék a kitűzött célt szolgálja (goal, scope, success criteria, stb.). Csak akkor lehet kiszámíthatóan a cél felé haladni, ha mérni tudjuk, mikor érünk oda.

Mit csinálok, ha megvan és mérhető a cél?
Itt kezdődik a termékmegvalósítás első lépése. A meglévő célt innen (akár több lépésben is) már szét lehet bontani olyan részfeladatokra, amiket egy-egy ember vagy kis csapat meg tud valósítani.

Hogyan bontom szét ilyen lépésekre?
A lépésekre bontott munkát egy “work breakdown structure”-be foglalja a csapat (WBS). Gyakori hiba, hogy a termék fejlesztésekor a csapat elsőre túl nagyot akar harapni. Valami teljesen újat, kiemelkedőt akar azonnal fejleszteni, amin minden elsőre tökéletes. Szintén gyakori a túl nagy titkolózás. Egy black boxban fejlesztett termék a környezeti visszajelzések hiányában nagyon nagy eséllyel kudarcra van ítélve. A nulláról terméket fejleszteni rettentő fáradságos, valamint idő- és pénzigényes munka. Ráadásul egy új terméknél a párhuzamosan futó változások miatt legtöbb esetben sokat kell korrigálni az egyes részegységeken, amíg teljesen kikristályosodik az irántuk támasztott tényleges követelményrendszer. Nem érdemes rohanni az elején, és túl nagy WBS-t építeni. A work breakdown structure egy élő dokumentum. Lehet később hozzáadni vagy elvenni belőle, és módosítani rajta. Érdemes először a változók számát minél alacsonyabban tartani, és egy baseline prototype-ot megtervezni.

Mi az a baseline prototype?
A baseline prototype olyan prototípus, ami a lehető legtöbb helyen már meglévő, bejáratott technológiát használ, és csak a legszükségesebb új fejlesztéseket tartalmazza. A fogalom nem összekeverendő a product baseline-nal. A baseline prototype már a termékfejlesztés korai szakaszában demonstrálja a befektetőknek, hogy a termék fő funkciói megvalósíthatók, a csapatnak pedig segít megtanulni az új technológia buktatóit. Sokkal többet tanul a csapat egy működő, még ha piacra nem is bocsátható prototípusból, mint egy olyan termékből, amit csak a fejlesztés késői szakaszában lehet ténylegesen kipróbálni. Minél korábban előkerülnek a hibák, annál egyszerűbb és olcsóbb kiküszöbölni őket.

Például egy új drón fejlesztését nem érdemes azzal kezdeni, hogy a szerkezettől kezdve a vezérlő elektronikán át a motorokon keresztül a firmware-ig mindent a nulláról létrehoz a csapat. Egy hatékony csapat elsőnek kiválaszt egyet a területek közül. A többire van bejáratott olcsó megoldás. Ha például az egyik fontos kritérium a teherbírás, akkor a csapat indulhat a drón vázának fejlesztésével. Ekkor az elektronika és a firmware lefedésére a drónba kerülhet például egy széles körben használható PX4 vezérlés a kompatibilis hardverrel. 

Egy baseline prototype több funkciót is ellát.

1. Kitűnő demonstrációs eszköz a befektetőknek. Sokkal könnyebb a sikeres munkát egy működő prototípussal bemutatni, mint egy táblánál elmagyarázni, hogy egyszer majd működni fog. Ezzel könnyebb újabb befektetést is szerezni.
2. A baseline feltár rengeteg apró hibát vagy fejlesztési lehetőséget, amire elméleti síkon nem gondolt a csapat, vagy nincsenek meg a tudományos eszközök a megfelelő elemzésre.
3. A baseline megalkotása kiindulási pontot ad a termék piackészre fejlesztésének. 

Ha már megvan, hogy az új technológia hogyan működik együtt a meglévő technológiákkal, akkor a csapat nekiállhat további új technológiákat hozzáadni a termékhez. Lépésenként készre fejleszteni, minden lépésben egy-egy új technológiával. Ha például a váz már bizonyította, hogy bírja mind a terhelést, mind a rezgést, mind az egyéb előírt paramétereket, akkor ráér a csapat nekiállni egy saját vezérlés kifejlesztésének. Ez a stratégia azonnal segít azonosítani a hibákat, ha a termék menet közben egyszer csak “elromlik”. A hibakeresés egy baseline prototype nélküli, a komplett rendszerteszt előtt nem kipróbálható terméken a sok ismeretlen faktor miatt mind anyagilag, mind időben egy rémálom lenne. Ha egy baseline prototype-pal rendelkező terméken egy változtatás után valami nem működik jól, szisztematikusan végig lehet haladni a működő régi és a nem működő új termék közti különbségeken. Meg lehet nézni azt is, hogy a felhasznált rendszerek közti mely interfészek okozhatnak problémákat.

Minden műszaki területnek megvan a saját definíciója az interfészre. Általánosságban az interfész a termékfejlesztésben, ahol két rendszer, eszköz, részegység vagy részelem kapcsolódik. Az interfész a drón esetében lehet például mechanikus, elektronikus vagy szoftveres. Mivel az emberek a saját munkájukat tesztelik a saját környezetükben, a hibák többsége az interfészek mentén fog kialakulni. Ahol az egyik ember munkája érintkezik a másikéval. Ez az autóiparban használatos DRBFM egyik alapelve. Egy baseline prototype rendelkezik egy saját interfész kiosztással, amit érdemes előre, de legkésőbb a baseline prototype elkészülésekor felírni. Ha az interfész kiosztás vizualizálva is van, az rengeteg időt és energiát takarít meg a későbbi hibakeresésben.