---
title: Termékfelfedezés
type: concept
aliases: [product discovery, discovery, "valuable usable feasible", "build the right product", "értékes, használható, megvalósítható", termékfelfedezés, "can you schedule discovery"]
tags: [product-management, validation, innovation, research]
sources: [inspired, sprint, the-mom-test]
updated: 2026-09-14
status: solid
---

# 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]]