Termékfelfedezés (product discovery)

Definíció. Egy szoftverprojekt két szakasz: kitalálni, mit építs ("build the right product"), és megépíteni ("build the product right"). Az elsőt Cagan termékfelfedezésnek hívja, a "követelmények és tervezés" helyett, mert két dolgot kell felfedezni: (1) vannak-e valódi felhasználók, akik akarják ezt (piac és lehetőség validálása), és (2) egy olyan megoldást, amely értékes (a felhasználó akarja használni), használható (rá tud jönni, hogyan) és megvalósítható (a rendelkezésre álló idővel, technológiával és pénzzel megépíthető). A felfedezés bizonyítéka egy célfelhasználókon tesztelt, nagy hűségű prototípus, nem egy dokumentum. (Inspired, Bevezetés, 12. fejezet)

Az 1. kiadás (2008) három kritériuma. A 2. kiadás (2017) negyedikként a viability-t (üzleti életképesség) tette hozzá; ez a forrás nem tartalmazza. A wikiben az üzleti oldalt a design-around-the-price és az outside-in-business-case fedi.

Miért fontos

• A mérnöki munka nem pótolja. Cagan HP-s AI-terméke technikailag lenyűgöző volt, a sajtó dicsérte, "just one problem: no one bought it". A tanulság: "it doesn't matter how good your engineering team is if they are not given something worthwhile to build." (Bevezetés)
• A kihagyott felfedezést a mérnökséggel pótolják. "Almost every company executes the discovery process… only instead of using one prototyper for a few weeks, they use the full engineering team for full release cycles… They are using the engineering organization to build a very, very expensive prototype, and they use their live customers as unwitting test subjects." Ezért kell tipikusan három-négy kiadás és egy-két év, mire a termék pénzt hoz, és ezért bukik annyi startup: nincs pénzük két évre. "Ready, fire, aim." (12)
• A vezetés fél tőle, mert nem kiszámítható (mint a Scrum: "hány sprint, mire kész?"), és mert a mérnök a legdrágább erőforrás, "ne csocsózzon" (12). Ironikus módon pont ez pazarolja a mérnöki kapacitást.
• A lehetséges folyton változik. A következő nagy dolog ritkán új; a régi új inkarnációja, ami annyival jobb, hogy újradefiniálja a kategóriát: Google a "kész" keresőpiacon (AltaVista, Infoseek, Snap), iPod száz MP3-lejátszó mellett. "Great product managers combine what is desirable with what is just now possible." (33)

A felfedezés természete

• Kreatív folyamat, nem ütemezhető fázis. A négyhetes forgatókönyv: "az engineering négy hét múlva szabadul, addig annyi időd van, amennyi kell". Első hét interjúk, második prototípus, harmadik teszt, negyedik use case-ek. Aztán: a felhasználók nem olyan lelkesek, mint a vezetés; a prototípust nem értik; "but time is up, the engineers are ready, so you give them what you have." 3-6 hónap ugyanarra a használhatatlan termékre, és mindenki tudja, a PM hibája. "It doesn't help to talk to users, create prototypes, and test with users, if you don't adjust your course based on what you learn." (12)
• A piac felfedezése könnyű, a megoldásé nehéz. A gyógyszeripar példája: nincs hiány jó orvosi problémából, a megoldás bizonytalan, és az iparág ezt beárazta; a szoftver viszont "úgy ütemezi a felfedezést, mintha házat építene". (12)
• Két kiadás párhuzamosan. Amint az 1.0 mérnöki fázisba lép (végrehajtási üzemmód, churn-minimalizálás), indul a 2.0 felfedezése; az új vezetői ötlet oda megy, nem a sütőben lévő termékbe. (12)
• Startup-recept. A szokásos modell: seed pénz → mérnökök felvétele → "stealth mode", a követelmények menet közben → hat hónap múlva alfa, amit először mutatnak meg, "rarely goes well", a run rate magas, a pénz fogy. Helyette: alapító/PM + interakciótervező + prototípus-készítő, tucatnyi prototípus-verzió, napi iteráció, néhány hét-hónap; a végén validált termék, élő spec a mérnököknek, és tudod, mibe vágsz. "Before burning through $500K or more in seed funding." (28)
• A felfedezés csapatmunka. Discovery = a PM, az interakciótervező és a szoftverarchitekt együttműködése; a mérnök az elejétől véleményez (relatív költség, jobb megoldás), a tervező nem "szolgáltatás" a spec után, hanem a legelején a legértékesebb. (Bevezetés, 5., 8., 19.)

Hogyan alkalmazd

1. Előbb a probléma: tíz kérdés megoldás nélkül → opportunity-assessment.
2. A megoldást nagy hűségű prototípusban keresd, és három validálást végezz a mérnöki munka előtt → prototype-testing.
3. A célfelhasználót az elejétől vond be (8-10 charter user) → charter-user-program.
4. A vevő a megoldást mondja, te a problémát halld ki; a kutatás finomít, nem talál ki → the-real-why, market-research-limits.
5. Meglévő terméknél a felfedezés a mérőszám köré szerveződik, nem a funkciókérések köré → specials-vs-product-requirements.
6. Ha a felfedezés azt mutatja, hogy nincs érdeklődés, tedd a polcra: "saving the company the wasted cost of building and shipping a losing product" (22).
7. A teljes folyamat egy oldalon → discovery-techniques-checklist.

Feszültségek

• Ramanujam–Tacke (design-around-the-price, willingness-to-pay): egyetértés a fő tételben (validálj, mielőtt építesz; "a magas bukási arány nem normális"), de a sorrend más. R–T: piac és ár → tervezés → építés, a WTP-beszélgetés a koncepció szakaszában, prototípus előtt, és élő üzleti terv. Cagan: probléma → prototípus → érték-teszt, ahol a "mennyit fizetnél" kérdés csak a prototípus után, mérőszámként hangzik el, és az üzleti terv másodlagos ("a barátod a pénzügyön összerakja"). Cagan felfedezése a használati élmény köré, R–T-é az ár köré épül. A wiki állása: a két sorrend összefér, ha a WTP-tartományt a lehetőségértékelés 4. kérdésénél (sikermérés, bevételi stratégia) mérik, és a prototípus-teszt a funkciónkénti WTP-t finomítja; a feature shock ellen mindkettő ugyanazt mondja (minimális termék, killer-funkciók ki).
• Moore (the-chasm, beachhead-segment): Cagan felfedezése a terméket keresi, Moore a belépési szegmenst; Cagan charter userei = Moore referenciái, de Cagan figyelmeztet, hogy a program tele lehet early adopterrel (Moore látnokaival), ami "csak early adoptereknek érdekes terméket" ad → emotional-adoption-curve.
• Sutherland (market-research-limits): Cagan elutasítja a kutatásból való terméktalálást ("no winning product was created by market research"), de a prototípus-tesztet és a "watch what they do" elvet ajánlja; ez Sutherland kontrollcsoportos, viselkedéses tesztjeinek terméktervezési párja. A gyenge pont közös: a prototípus utáni "tetszik-e / mennyit fizetnél" kérdés kimondott preferencia.
• Sharp (how-brands-grow, nullhipotézis): Cagan könyve a termékről szól, nem a márka növekedéséről; a "9/10 kiadás bukik" nem mond ellent a penetrációs törvényeknek, hanem előfeltétele: a rossz terméket sem az elérés menti meg ("ne adj okot a nem vásárlásra", Sharp 7. szabálya). A "virális marketing" és a "közösség" 37. fejezetbeli tételei Sharp fenntartásával olvasandók (word-of-mouth-vs-advertising).

• A könyv nem ad adatot arra, mennyivel jobb a prototípussal felfedezett termék; a "3+ kiadás, 1-2 év" tapasztalati becslés.

• Knapp (sprint, design-sprint, beolvasva): a design sprint Cagan felfedezésének egyhetes, csapatos recept-változata: ugyanaz a mag (validálj építés előtt egy valósnak látszó prototípussal célvevőkön; "instead of waiting to launch a minimal product… get clear data from a realistic prototype"), de három új elem: (1) időkeret — öt nap, tíztől ötig, prototípus csütörtökön, öt vevő pénteken; (2) a Decider — egy döntéshozó a szobában (SquidCo: a hiányzó CPO megölte a jól tesztelt projektet), delegálással és cameóval; (3) történet-központú tervezés — térkép → egy vevő, egy pillanat → storyboard nyitójelenettel a versenytársak mellett (map-and-target, decide-without-debate). Ütközés az ütemezhetőségen: Cagan szerint a felfedezés nem ütemezhető (a négyhetes forgatókönyv rossz terméket ad), Knapp szerint öt nap alatt válasz van. Feloldás: a sprint nem a felfedezést, hanem egy tanulási kört ütemez (hipotézis → homlokzat → öt reakció), és a könyv a sprint után követő sprintet, aztán építést és nagy mintás tesztet kér (Slack 3 hét múlva 5/5; Medium: egy hét építés + részleges kiadás); Cagan négyhetes forgatókönyvének hibája nem az időkeret, hanem a "give them what you have" — amit a sprint pénteke épp kizár ("Can we stop after Decide? No."). Egyezés: a "vevő nem tudja, mit akar" tétel Knappnál "reactions are solid gold, feedback is worth pennies" (fake-it-prototype); Cagan hat egymást követő sikeres felhasználója vs. Knapp öt vevője egy nap alatt (five-user-test); mindkettő szűri az early adoptert, a barátot, az iparági bennfentest. Ami Knappnál sincs: ár, üzleti terv, piacméret — a sprint interjúja nem kérdez árat, R–T WTP-je továbbra is külön lépés → design-around-the-price.

Fitzpatrick: a felfedezés beszélgetés-oldala (beolvasva 2026-09-14)

the-mom-test (rob-fitzpatrick) ugyanezt a munkamegosztást mondja ki egy mondatban: "They own the problem, you own the solution." — a vevő nem mondhatja meg, mit építs, te nem mondhatod meg, mi a problémája. Ez szó szerint Cagan ("no winning product was created by market research") és Horowitz ("a helyes termék kitalálása az innovátor dolga") álláspontja, kiegészítve azzal, hogy a probléma oldalán viszont kérdezni kell, és lehet is, ha múltbeli konkrétumot kérdezel → mom-test-rules, good-question-bad-question.

Két gyakorlati kiegészítés: (1) a termékkockázat és a piackockázat szétválasztása — ahol a kockázat a terméknél van ("ha meg tudod csinálni, veszünk belőle": videojáték, hirdetési kereslet, affiliate jutalék), ott a beszélgetés nem validál, és korábban, kevesebb bizonyossággal kell építeni; (2) a tanulási szűk keresztmetszet tilalma: aki egyedül jár a beszélgetésekre és nem osztja meg a jegyzeteket, de facto diktátor lesz "a vevő azt mondta" trumffal — Fitzpatricknál emiatt mondott fel a CTO. Ellenszer: a teljes alapítócsapat az előkészítésen, kettesével interjú (egy kérdez, egy jegyzetel), szó szerinti idézetek, közös utókövetés. És: a felfedezést nem lehet kiszervezni — a bérelt kutató a langyos jelet elkeni → mom-test-rules.

Kapcsolódó

inspired · marty-cagan · prototype-testing · opportunity-assessment · charter-user-program · product-management-vs-product-marketing · discovery-techniques-checklist · design-around-the-price · four-monetization-failures