A startup világban van egy visszatérő forgatókönyv: építenek egy technikailag tökéletes terméket, rengeteget költenek rá – majd senki sem akarja használni. Ez történt a Redditen megosztott történetben, ahol egy csapat 300,000 dollárt és 18 hónapot fektetett egy „technikai csúcstermékbe” a háziorvosi szektorban… amit végül egyetlen orvos sem akart adaptálni. Mi lehet ennek az oka? És mit tanulhatunk belőle, hogy ne essünk ugyanebbe a hibába?
A tökéletes app, amit senki sem használ
A Redditen megosztott történet főszereplője két évvel ezelőtt seed befektetést kapott, hogy háziorvosok számára készítsen egy betegmenedzsment alkalmazást. Felkértek egy boutique fejlesztőcéget, és 18 hónap alatt, 300,000 dollárból megalkották a „technikai szempontból tökéletes” terméket:
- hibamentes működés,
- letisztult felület,
- integráció a legnagyobb EHR rendszerekkel,
- teljes HIPAA-kompatibilitás.
A csapat büszke volt az eredményre – ám amikor több mint 50 orvosi praxisnak bemutatták, mindenhol ugyanazt a választ kapták:
- „Szép, de nem illik a napi munkamenetünkbe.”
- „Túl sok klikkelés.”
- „Már van rendszerünk, ami működik.”
Miért bukott el?
A kudarc fő oka az lett, hogy a fejlesztés inkább a saját elképzeléseik szerint zajlott, ahelyett, hogy a kezdettől a célfelhasználók valós igényeit és munkafolyamatait tették volna a középpontba.
Közben a piacon sokkal egyszerűbb, kevésbé látványos appok hatalmas sikert arattak – mert pontosan egy égető problémát oldottak meg.
Mit lehetett volna másképp csinálni?
Utólag persze könnyű okoskodni, és tanulhatunk mások kárából. Egy bukott projekt története mindig erős üzenetet hordoz: megmutatja, hol csúszhat félre egy jó szándékú és technikailag erős fejlesztés. A most következő tanulságok nemcsak erre az egy konkrét esetre érvényesek, hanem bármelyik iparágban előfordulhatnak, ahol egy csapat új terméket próbál a piacra vinni. Ha ezeket szem előtt tartjuk, sok időt, pénzt és csalódást spórolhatunk meg magunknak.
Mély felhasználói kutatás nélkül nincs siker
A történet legfontosabb tanulsága, hogy a felhasználók valós igényeinek megértése nélkül a legjobb fejlesztői csapat és a legtökéletesebb technikai megoldás is elbukhat. Ennél a projektnél az első hiba már a kiindulásnál megtörtént: a fejlesztés alapja nem egy alapos kutatás volt, hanem a csapat saját elképzelése arról, hogy mi lehet hasznos a háziorvosoknak. Ha a kezdetektől interjúkat készítettek volna, megfigyelték volna az orvosok munkáját, és közösen ötleteltek volna velük, már korán kiderült volna, hogy nem egy újabb, komplex rendszerre vágynak. Sokkal inkább a napi munkájukban leginkább zavaró, időrabló folyamatok egyszerűsítését szeretnék látni.
Fontos, hogy a termékünk valós igényeket oldjanak meg, és ne csak kitaláljunk valamit, ami szerintünk működhet.
Kisebb, célzottabb indulás
Ha a felhasználói kutatás alapján készült volna egy célzott, egyszerű prototípus, sok felesleges kört meg lehetett volna spórolni. Ahelyett, hogy azonnal egy minden funkciót lefedő, teljeskörű rendszert építettek volna, elegendő lett volna egy kicsi, de pontosan célba találó funkciót gyorsan éles környezetben tesztelni. Egy ilyen minimum viable product lehetőséget ad arra, hogy a startup már a fejlesztési folyamat elején visszajelzést kapjon, és ha kell, időben irányt váltson. Ha a teszt során kiderül, hogy az ötlet nem illeszkedik a mindennapi munkafolyamatokba, akkor nyitva áll a lehetőség egy nagyobb változtatásra még azelőtt, hogy hónapok és százezrek mennének kárba.
Workflow-központú tervezés
Az egészségügyre – és sok más szakmai területre – igaz, hogy a felhasználók berögzült munkafolyamatai nehezen változnak meg. Ezért minden új rendszernek úgy kell megjelennie, hogy szinte észrevétlenül beilleszkedjen a meglévő rutinokba. A tervezés során nem feltétlenül a vizuális tökéletesség a döntő, hanem az, hogy az eszköz mennyire gördülékenyen illeszkedik a napi használathoz. Sok esetben ez azt jelenti, hogy a fejlesztői víziót és az esztétikai elvárásokat a gyakorlati használhatóság érdekében kompromisszumokkal kell felülírni.
A bevezetés és az elfogadás támogatása
Egy sikeres bevezetésnél nem csak maga a termék számít. Az orvosok – és általában a szakmai felhasználók – nagyon magas váltási költséggel dolgoznak: időbe telik az új rendszer megtanulása, az adatok átmigrálása, valamint a megszokott folyamatok átalakítása. Mindez pedig nagy kockázatnak tűnhet a szemükben. Ha egy termékhez már az elején együtt jár egy jól átgondolt betanítás, folyamatos támogatás és fokozatos bevezetés, akkor sokkal nagyobb esély van arra, hogy elfogadják. A bevezetési stratégia éppoly fontos, mint maga a fejlesztés.