Aki megtanulta az első leckét a startupokról, tudja, hogy globális piacra kell tervezni. Sok startupper ennek megfelelően két felhasználói csoportot céloz: ingyenes vagy freemium alkalmazásoknál a "mindenki", fizetős szolgáltatásoknál vagy fizikai megoldásoknál pedig a "25-35 év közötti nyugati középosztály" vagy divatosabban az "Y generáció".

A megközelítés előny, hogy nagyon pesszimista becslések is nagyon szép eredményeket mutatnak. Hiszen ha egy app három barátom közül kettőnek tetszik, akkor ebből extrapollálva a teljese piacra, és a becslést leosztva egy nagyon biztonságos százas osztóval még mindig több tízmilliós felhasználói táborra számíthatok. Azonban vannak hátrányai is. Design thinking szemszögből az egyik nagy probléma, hogy az ilyen széles körben definiált felhasználói bázis nehezen megfogható, így nehéz nekik tervezni.

A felhasználók és a probléma szorosan összefügg. Egy jól megadott felhasználói csoporthoz könnyebb problémát keresni, egy jól meghatározott problémához pedig az embereket, akiket érint. Itt is mint a design thinking használatakor szinte mindenhol iteratív megközelítéssel lehet célt érni. A legkisebb felhasználói csoporttal kell kezdeni: leülni valakivel beszélgetni. Ha már van elképzelésem a területről, célzottan kiválasztok egy embert. A legkönnyebb a közvetlen ismerősök köréből válogatni. Például egy intelligens otthoni hálózat esetén bárki szóba jöhet, aki saját családi házában lakik, és megvannak az anyagi lehetőségei a tervezett költség vállalására. Ilyen embert a legtöbb problémához, ötlethez lehet találni. Persze nehezebb a helyzet, egy külföldi piac esetén, de már itthon is lehet olyan embert találni, aki egy amerikaihoz, némethez, franciához hasonlóan él és gondolkodik.

A felhasználók mindig érdekesek. Szeretem azokat a helyzeteket, amikor irányítatlanul az általa jól ismert témában beszélgethetek valakivel, vagy inkább beszéltethetek valakit. A diákoktól kezdve a szerelőkön, ügyfélszolgálatosokon keresztül más vállalkozókig, kutatókig szívesen veszem a rövid, 30-40 perces beszélgetéseket, amikben betekintést nyerhetek a másik ember hétköznapjaiba. Szigorúan mérnöki szempontból: megismerni a módszereket, amiket használ, és a problémákat, amikkel szembesül.

A kiváncsiság könnyen eljuttat egy jó ötlethez: a jó ötleteket könnyebb megtalálni, mint kitalálni.

A világ tele van problémákkal. Minden ember egyedi, egyedi igényei és nehézségei vannak. Ezért a globalizált piacra tervezett tömegtermékek mellett virágkorukat élik a niche termékek: ha egy probléma csak az emberek 0.01%-át érinti, az is 720.000 potenciális felhasználót jelent.  Felismerni, megismerni és megérteni egy ilyen problémát olyan piaci előnyt jelent, mintha valaki az egyetlen cipész lenne Frankfurtban. 

A terméket a probléma határozza meg. A prezentációs tréningen szembesültem ezzel igazán. Senki sem kíváncsi arra, hogy hogyan oldok meg valamit, amíg nem tudja, hogy mit akarok megoldani. Az első kép, ami bevillant a Teleshop termékek fekete fehér bevezetője volt.

Korábban, ha valaki kérdezte, mit csinálok, magyaráztam, hogy milyen weboldal, meg feladatok, meg elemzések, hogyan lesz az jó. Minden alkalommal, amikor nem tanárokkal beszéltem, azt éreztem, hogy az első mondatok után elvesztettem a közönséget. Ezt a berlini csapattagok utólag be is vallották, amikor megtartottam az első probléma centrikus pitchet, és végre megértették miről van szó.

Sok elkezdett, de félbehagyott, elkészült, de ki nem adott, kiadott de nem támogatott alkalmazáson keresztül tanultam meg hogy sok csapdát rejt magában, ha az appra, a feature-ökre koncentrálva fejlesztek. Rögtön az első, hogy tévesen ítélem meg a kilátásokat. Hiszen nem lesz még egy olyan app, ami pont azt tudja. Ergo sikeresnek kell lennie, hiszen valamiben a legjobb. Fejlesztés közben már nehéz reagálni a visszajelzésekre. Ha a cél egy specifikációnak megfelelő app elkészítése, akkor minden módosító javaslat rosszul esik. Nehéz beépíteni a termékbe, mert az a cél módosításával, tehát az eredeti cél feladásával jár, és ez rombolja a morált.

A problémát szem előtt tartva robosztusabb lesz a projekt. Könnyebb feldolgozni a visszajelzéseket, könnyebb újrakezdeni, átstrukturálni a megoldást. Az így szerzett rugalmasság pedig elengedhetetlen a mai, gyorsan változó piacon. Robosztusabb lesz a csapat is, ha a tagok nem a saját munkájukat védik, hanem a közös cél felé dolgoznak. Könnyebb kritikát adni és fogadni egy designra vagy feature-re, ha a kritika valós igényben gyökerezik és nem egyéni preferenciát, véleményt tükröz. A leendő felhasználók fájdalma egyben motiváció is.

A jó termékhez elengedhetetlen a jó probléma. Egy felhasználói igény, aminek ismerjük a részleteit, a fontosságát, az érintettek körét. E köré kell építeni a projektet, és akkor nagyobb esély van a sikerre. A design thinking eszköztára a probléma megtalálást is támogatja.

Könnyű beleszeretni egy ötletbe, egy megoldásba. Aztán megkeresni hozzá a problémát, amihez a felhasználói kör már adja magát. Egy mobil appnál az üzleti életképesség sem kérdés: a sok felhasználó hozza majd a reklám-bevételeket, mindig ott a freemium modell, és ha minden kötél szakad lesz valaki, aki jobban tudja, hogy lesz az egészből pénz, és felvásárolja a céget. És már csak a fejlesztőcsapat kell. A legtöbb kezdeményezés ezen a ponton el is hal, mert az egész világon nincs annyi szabad fejlesztő, ahány világmegváltó ötlet egy átlagos belvárosi romkocsmában szerda esténként születik.

Szerencsétlenebb esetben azonban konyítunk egy kicsit a mobil fejlesztéshez, és akkor kezdetét is veszi a projekt. Aztán ahogy halad a munka, elkotyogjuk ismerőseinknek, akik ha jobban tájékozottak a világ dolgaiban, felhívják a figyelmünket néhány konkurens vagy hasonló termékre. De egyik sem lesz ugyanolyan, és ha találunk is olyat, ami ebben vagy abban jobb, csak 1-2 killer featurre van szükség, és újra mi leszünk a piacvezetők - amint kijövünk, és rákapnak a felhasználók. jó esetben 4-5, rossz esetben 12 hónap ellopott órái esténként, hétvégén délelőtt, és készen is van az app. Agonizálva, az utolsó utáni feature-öket polírozva végül egy hónappal később fel is kerül az alkalmazás-boltba. És vállalkozásunk cammogó léptekkel elindul a világsiker felé. Pár ezer, pár tízezer felhasználót megtalálunk. Ha néhány százan rendszeres használót megragad az app, esetleg csöpög egy kis reklámbevétel, egy-két felhasználó megszán minket és kipróbálja a prémiumszolgáltatásokat.

Visszaszámolni nem merjük a ráfordított órákat. A support pedig kínszenvedés, minden lehetséges hiba kijön, száz felhasználó száz eszközön teszteli nap mint nap az appot.

De van egy csodafegyver, amivel mindez elkerülhető. A józanész 21 század eleji neve: design thinking. A design thinking nem egy bombabiztos módszer, amit lépésről lépésre követve garantált lesz egy megoldás sikere, hanem egy gondolkodásmód, egy keretrendszer, amiben könnyebb lesz megtalálni a helyes utat - ha vállaljuk az betervezett kudarcokat, és nem félünk a változástól.

A design thinking segít abban, hogy megfelelő perspektívából szemléljük a feladatokat, kellő rugalmassággal tervezzünk. A mai folyamatosan változó világban a tökéletesen tervezett úton is felbukkanhat egy nem várt akadály.

Ez hagyományosan a projekt lassú halálát jelentheti: a terveket nem lehet feladni, ezért az akadályt kell áttörni. Ezt a megközelítést erősíti az általános szemlélet is. Éveken át azt sulykolják belénk, hogy ha valamit elég erősen akarunk, ha valamiért elég sokat dolgozunk, az sikerülni fog. Ezért nem szabad a nehézségeknél megtorpanni, eltántorodni az eredeti céloktól, és legkevésbbé sem szabad feladni. És ezt sokan félreértjük, egy konkrét akadályra, egy konkrét lépésre próbáljuk értelmezni. Görcsösen markolva a csákányt pattintjuk le az apró szilánkokat az utunkba görgetett szikláról, míg el nem érjük azt a pontot, hogy végre büszkén adhatjuk fel, abban a biztos tudatban, hogy mindent megtettünk.

Hogy milyen eszközökkel lehet ezt jobban csinálni?

Ezt nem lehet megkerülni. A csapatot fel kell építeni. Meg kell teremteni egy bizalmas közeget, ahol bátran szárnyalnak az ötletek, mindenki képes megnyílni, figyelni a többiekre, elfogadni azok hibáit, megismerni errősségeit és építeni rá. És mint azt már megtanultuk, ennek a legjobb eszköze a spagetti-torony építés.

A pénteki egész napi ácsorgás, és a késői fekvés egy kicsit kiütött, szombaton ki sem mozdultam otthonról, haladtam a feladatok programozásával - nem elég gyorsan - és létfenttartottam. Ennek egyik eszköze a Nürnberger Rostbratwurst volt, salsa szósszal, és a szegény ember nachos-szával: vékonyra szelt piritóssal.

A berlini nulladik napomat követő első nap a program szempontjából volt nulladik nap. A gyorsítás - accelarator program - csak hétfőn indul. 12.-én egy könnyed városnézéssel nyitottuk meg, és a Social Impact Lab éves partyjával zártuk a napot (és kezdtük a következőt).

A gép 14:00-kor indul. Előző nap este Attila csomagolt be nekem, így ma délelőtt először ki kellett ürítenem a táskát, és utána kezdetét vette a pakolás. Ami helyet kapott: úszószemüveg, mászócipő, matematika és számításelmélet könyvek. Ami végül nehéz döntések során kiszorult: a elvitelre szánt pólóim fele, tusfürdő, a zoknik és a boxeralsók egy része. Felkészültem az indulásra.