---
title: Lehetőségértékelés (tíz kérdés a problémáról)
type: concept
aliases: [opportunity assessment, product opportunity assessment, MRD, market requirements document, "ten questions", lehetőségértékelés, "make a friend in finance", product council, termékbizottság]
tags: [product-management, planning, validation, finance]
sources: [inspired, sprint]
updated: 2026-09-08
status: solid
---

# Lehetőségértékelés (product opportunity assessment)

**Definíció.** A piaci követelménydokumentum (MRD) könnyű változata: tíz kérdés a *megoldandó problémáról*, megoldás nélkül. Célja vagy (a) megakadályozni, hogy a cég rossz lehetőségre költsön (az ötlet "most a polcra kerül"), vagy (b) a jó lehetőségnél fókuszálni a csapatot: mi kell a sikerhez, és hogyan mérjük. Az MRD-k "túl sokáig készülnek, nem olvassák őket, és nem válaszolják meg a kulcskérdéseket", ezért sok PM kihagyja őket, és egyből a termékbe ugrik; ez a "look before you leap" gyors formája. (Inspired, 11. fejezet)

## A tíz kérdés

1. Pontosan milyen problémát old meg? *(értékajánlat)*
2. Kinek oldjuk meg? *(célpiac)*
3. Mekkora a lehetőség? *(piacméret)*
4. Hogyan mérjük a sikert? *(mérőszámok, bevételi stratégia)*
5. Milyen alternatívák vannak most? *(versenykörnyezet)*
6. Miért mi vagyunk a legalkalmasabbak? *(megkülönböztetőnk)*
7. Miért most? *(piaci ablak)*
8. Hogyan visszük piacra? *(go-to-market stratégia)*
9. Milyen tényezők kritikusak a sikerhez? *(megoldás-követelmények: függőségek, korlátok, pl. rendszerintegrátorok bővíthetőségi igénye, márka- vagy partnerkövetelmény)*
10. Mindezek alapján mi az ajánlás? *(go / no-go)*

Megjegyzések a fejezetből:
- **Egyik kérdés sem a megoldásról szól**, szándékosan: aki a problémát a kedvenc megoldásával keveri, az a megoldás nehézségeinél *a lehetőséget* dobja el ("a fürdővízzel a gyereket").
- **A legnehezebb az első.** A legtöbb PM a "milyen problémát old meg" kérdésre "funkciók és képességek csapongó listáját" mondja, nem egy éles, meggyőző problémamondatot.
- **Piacméret:** elemzők, szakmai szövetségek, pénzügy, saját alulról építkező számítás; legyél konzervatív, "nem minden lehetőségnek kell milliárdosnak lennie" (vö. Moore "kolbász"-hasonlata → [[market-research-limits]]).
- **Go-to-market** kiemelten fontos, mert az értékesítés módja a termékkövetelményekre hat (vö. "designing for the sales channel", 38.) → [[distribution-and-pricing-for-the-chasm]].
- Ha a CEO mondja, "ezt csináljuk": stratégiai ok lehet; a gyors értékelés akkor is megéri, "you will become much better informed about what the product involves", és a tanultak megváltoztathatják a CEO véleményét.

## "Build new or fix old?" és "where's the money?"

- Ne százalékos keretet ossz új és meglévő termék közt: minden projekt *befektetés*, a csapat a legjobb lehetőségekért felel. Gyakran a legjobb megtérülés "az orrod előtt van": 100 feliratkozás-kezdésből 9 megy végig; 18-ra emelni "megduplázza a bevételt", és ez "gyakran a legegyszerűbben megoldható" (egy kis prototípus és felhasználói teszt). A cégek azt hiszik, a 9% "nem rossz", vagy több akvizíciós reklám kell, vagy a support "üzemeltetési költség"; valójában "a termék gyenge, és a cég a legjobbat hozza ki abból, amije van" → [[specials-vs-product-requirements]].
- **Barát a pénzügyön.** A legtöbb PM (főleg a mérnöki hátterű) sekélyen ismeri a termék gazdaságtanát: bevételi modell, teljes költség, vevőszerzési költség, élettartam-érték, megtérülés. Cagan minden cégnél kért a CFO-tól egy embert; ő három dologban segít: a termék pénzügyi értékelése (szerződések, licencek, "carrying its own weight?"), a vevők megértése (tranzakció- és fizetési adatok a webanalitikán túl; "Because nobody asked."), és **az üzleti terv összerakása** ("you'll need to provide most of the inputs, but your friend will know how to put together the case").

## Költségbecslés és a termékbizottság (14. fejezet)

A vezetés korán akar költséget tudni, a mérnökség csak a megoldás ismeretében tud becsülni; ebből vagy "vadul pontatlan" korai becslés, vagy sticker shock lesz. Cagan folyamata: a lehetőségértékelésnél csak **S/M/L** ("SWAG"); a prototípus és a validálás után **részletes, nagy bizonyosságú becslés**, amit a teljes csapat vállal. A **termékbizottság** (product council; Maynard Webb, eBay) a keresztfunkciós vezetők ≤10 fős köre, amely nem tervez terméket, hanem négy mérföldkőnél dönt: (1) stratégia és roadmap → mely lehetőségeket vizsgáljuk; (2) lehetőségértékelés → go/no-go a felfedezésre; (3) prototípus, teszteredmények, részletes becslés → go/no-go az építésre; (4) kész termék, QA, bevezetési terv, közösségi hatás → go/no-go a bevezetésre; 3-6 hónappal a bevezetés után üzleti eredmény-beszámoló.

## Hogyan alkalmazd

1. Egy oldal, tíz válasz, számokkal a 3-4. kérdésnél; a megoldást hagyd ki, még ha van is.
2. A 4. kérdésbe tedd a WTP-tartományt és a bevételi modellt is, hogy a felfedezés az ár köré is épüljön → [[willingness-to-pay]], [[monetization-models]].
3. A 8. kérdés (csatorna) írja elő a termékkövetelmények egy részét → [[whole-product]].
4. Mutasd be a vezetésnek, és kérj explicit döntést; a "nem" is siker.
5. A becslés csak S/M/L, amíg nincs prototípus.

## Feszültségek

- **Ramanujam–Tacke ([[outside-in-business-case]]):** R–T az üzleti tervet *élő modellnek* tartják WTP-vel, rugalmassággal és versenytársi reakcióval, és a tervek 95%-át azért bírálják, mert nincs bennük WTP; Cagan az MRD-t és a hosszú üzleti tervet bírálja, mert *senki nem olvassa* és hamis biztonságot ad, és a business case-t a pénzügyes barátra bízza. Nem ellentmondás, hanem hangsúly: Cagan tíz kérdése R–T "alapanyag-listájának" (piacméret, szegmensek, érték, WTP, modell, költség, versenytársak) rövid, *probléma-oldali* változata, WTP nélkül; R–T modellje Cagan 3. mérföldkövénél (prototípus + részletes becslés) válik értelmessé. A wiki állása: a lehetőségértékelés a "nézz, mielőtt ugrasz" minimum, a WTP-vel kiegészítve; az R–T-féle modell a felfedezés *után*, a build-döntéshez.
- **Moore ([[beachhead-segment]], [[chasm-crossing-checklist]]):** Moore célvevő-forgatókönyve (egy oldal: vevő, egy nap előtte és utána, gazdasági következmény) a 2. és az 1. kérdés narratív változata; Cagan tíz kérdése a *teljes* lehetőségre, Moore forgatókönyve a *belépési szegmensre*. A "size matters" piacméret-kritika és Cagan "légy konzervatív" tanácsa egybevág.
- **Keenan ([[current-state-discovery]]):** a PIC (probléma / hatás / gyökérok) az 1. kérdés egy vevőnél, számszerűsítve; Cagan tíz kérdése a piac szintjén.
- Az MRD-kritika 2008-as; az "opportunity assessment" a 2. kiadásban a "customer letter" és az OKR-alapú "product vision" mellé kerül, ami itt nincs.

- **Knapp ([[sprint]], [[map-and-target]], beolvasva):** a sprint hétfője a lehetőségértékelés *csapatos, egynapos* párja: hosszú távú cél ("Why are we doing this project? Where do we want to be in six months, a year, five years?"), **sprintkérdések** (a feltevés kérdéssé fordítva: "To reach new customers, what has to be true? — They have to trust our expertise. — Will customers trust our expertise?"), térkép, szakértő-interjúk, egy célvevő és egy célpillanat. Cagan tíz kérdése *piaci és üzleti* (méret, alternatívák, miért mi, miért most, go-to-market, bevételi stratégia), Knapp hétfője *történet és kockázat* (szereplő, lépések, hol bukhat el) — piacméret, WTP és csatorna nélkül. Ahol Knapp többet ad: a *kérdés* formája (tesztelhető egy hét alatt), a "nobody knows everything, not even the CEO" elv (a sales-vezető átrajzolta a CEO által jóváhagyott térképet), és a HMW-cédulák, amelyek a problémát lehetőséggé fordítják. A wiki állása: a lehetőségértékelés a sprint *előtt* dönti el, érdemes-e a probléma és mennyit ér (Cagan 4. kérdése + R–T WTP-tartomány); a hétfő a lehetőségértékelés 1–2. kérdését bontja sprintkérdésekre; a Decider Cagan "explicit vezetői döntés" elvének megszemélyesítése.

## Kapcsolódó

[[inspired]] · [[product-discovery]] · [[prototype-testing]] · [[outside-in-business-case]] · [[discovery-techniques-checklist]] · [[product-principles]]