ہمدردی اور دریافت
مسلسل، ثبوت پر مبنی دریافت کے ذریعے بیان کردہ خواہشات سے حقیقی طلب کو الگ کر کے تعمیر کا حق حاصل کریں۔
Explainer
ڈسکوری وہ کام ہے جس سے آپ 'بنانے کا حق' حاصل کرتے ہیں۔ زیادہ تر پروڈکٹ ناکامیاں عملدرآمد کی ناکامیاں نہیں ہیں؛ یہ شپ کیے گئے فیچرز کے بھیس میں طلب کی ناکامیاں ہیں۔ مضبوط ڈسکوری آرام دہ شارٹ کٹس کو مسترد کرتی ہے — رویّے کے بغیر سروے، فوکس گروپس، 'تصدیق' کے لیے روڈ-شو ڈیموز — اور ان کی جگہ ایک کسی ہوئی لوپ رکھتی ہے: انٹرویو، مشاہدہ، تجزیہ، اور مقداری اشارے کے ساتھ معیاری شواہد کا تثلیث — جب تک ٹیم گزشتہ ہفتے کے مقابلے میں ایمانداری سے کم غلط نہ ہو جائے۔
بیان کردہ ترجیح بمقابلہ ظاہر شدہ رویّہ
صارفین اپنے ہی رویّے کے ناقابلِ اعتبار پیشین گو ہیں۔ وہ آپ کو بتائیں گے کہ انہیں ایسا فیچر چاہیے جو وہ کبھی استعمال نہیں کریں گے، کہ وہ ایسی چیز کے لیے ادائیگی کریں گے جس کے لیے وہ کبھی نہیں کریں گے، اور یہ کہ وہ ایک ایسے UI سے نفرت کرتے ہیں جس پر وہ بار بار واپس آتے ہیں۔ ڈسکوری وہ نظم ہے جو صارفین جو کہتے ہیں اس سے زیادہ صارفین جو کرتے ہیں اس پر بھروسا کرے۔ انٹرویو ماضی کا رویّہ دوبارہ تعمیر کرنے کا اوزار ہے، مستقبل کے رویّے کی پیشین گوئی کا نہیں۔
- ماضی کا رویّہ > بیان کردہ نیّت > فرضی ترجیح، اسی ترتیب میں۔
- جب فرضی پوچھنا ضروری ہو، کسی مخصوص حالیہ لمحے پر لنگر ڈالیں، عمومی مستقبل پر نہیں۔
- اگر صارف کہے 'میں اس کے لیے یقیناً ادائیگی کروں گا'، پوچھیں: 'آج آپ جو ورک اراؤنڈ استعمال کر رہے ہیں اس کے لیے آپ نے اب تک کتنا خرچ کیا ہے؟'
Jobs-to-be-Done — تین مکاتب
JTBD ایک چیز نہیں ہے؛ تین متداخل مکاتب ہیں۔ انہیں خلط ملط کرنا PMs کی سب سے عام غلطی ہے۔ اپنے فیصلے سے میل کھاتا مکتب چنیں اور اسی کی اصطلاحات پر جمے رہیں۔
- Christensen / Switch (Bob Moesta, Chris Spiek): پرانی حل سے نئی حل پر سوئچ کرنے کے لمحے پر مرکوز۔ اصطلاحات: تشویشات، عادات، push، pull، چار قوتیں۔
- Outcome-Driven Innovation (Tony Ulwick): فعلی jobs کو قابلِ پیمائش مطلوبہ نتائج میں توڑا جاتا ہے، اہمیت اور موجودہ اطمینان پر اسکور کیا جاتا ہے۔ اصطلاحات: opportunity score = اہمیت + max(اہمیت − اطمینان، 0)۔
- Strategyzer (Alex Osterwalder): jobs کو ویلیو پروپوزیشن ڈیزائن کے ان پٹ کے طور پر — فعلی، جذباتی اور سماجی jobs، تکالیف اور فوائد کے ساتھ جوڑے۔
Switch انٹرویو اور چار قوتیں
Switch انٹرویو اس لمحے کو دوبارہ تعمیر کرتا ہے جب صارف ایک حل سے دوسرے پر گیا۔ فریم ورک: موجودہ صورتحال کا push، نئی حل کا pull، سوئچ کرنے کی تشویشات، اور حال کی عادات۔ طلب وہاں ہے جہاں push + pull > تشویشات + عادات۔ مضبوط PMs ہر قوت کو واضح طور پر کھنگالتے ہیں۔
- Push: پہلے ورک فلو میں خاص طور پر کیا ٹوٹا؟ کب؟ کس کے ساتھ؟
- Pull: نئی پسند کے کس پہلو نے 'کوشش کے لیے کافی اچھا' کی حد عبور کی؟
- تشویش: اپنانے میں کیا فکرمند کرتا تھا؟ لاگت، خطرہ، سماجی خطرہ، سیکھنے کا منحنی؟
- عادت: push ظاہر ہونے کے بعد بھی آپ کو پرانے طریقے پر اتنی دیر کیا روکے رہا؟
- اگر تشویشات یا عادات push + pull سے بڑی ہوں، طلب نظریاتی ہے، حقیقی نہیں۔
صارف انٹرویو کی میکانکس
اکثر PMs اپنے انٹرویوز کے معیار کا حد سے زیادہ اندازہ لگاتے ہیں۔ سب سے بڑے مسائل: رہنما سوالات، حل کا پراڈکٹ کرنا، صارفین سے ڈیزائن کروانا، اور بیان کردہ وجوہات کو من و عن قبول کرنا۔ ایک اچھا انٹرویو ساختہ ہوتا ہے مگر اسکرپٹڈ نہیں — وہ زندہ تفصیل کے ساتھ رویّہ دوبارہ تعمیر کرتا ہے۔
- کسی مخصوص حالیہ لمحے سے شروع کریں: 'گزشتہ بار جب یہ ہوا، مجھے قدم بہ قدم بتائیں'۔
- منٹ بہ منٹ ٹائم لائن کھنگالیں؛ خلاصہ بیانات قبول نہ کریں۔
- توانائی کی تبدیلیاں سنیں — آہیں، تیزی، توقف — اور انہیں فالو کریں۔
- حل تجویز کرنے سے پہلے ورک اراؤنڈ کے بارے میں پوچھیں؛ ورک اراؤنڈ داخلے کی قیمت ہے۔
- انٹرویو ختم کرنے سے پہلے یہ پوچھنا نہ بھولیں: 'میں نے کیا نہیں پوچھا جو پوچھنا چاہیے تھا؟'
- (اجازت سے) ریکارڈ کریں اور ٹرانسکرپٹس کو ٹیگ کریں؛ یاد داشت 48 گھنٹوں میں سب سکیڑ دیتی ہے۔
ہفتہ وار عادت کے طور پر مسلسل ڈسکوری
Teresa Torres کی مسلسل ڈسکوری روایت 'ڈسکوری مرحلہ' کو ہفتہ وار تال سے بدلتی ہے۔ مقصد: پروڈکٹ سہ گانہ (PM، ڈیزائن، انجینئرنگ ٹیک لیڈ) ہر ہفتے کم از کم ایک صارف سے بات کرتا ہے، ہر ہفتے، اور ایک واضح مطلوبہ نتیجے کے خلاف Opportunity Solution Tree اپڈیٹ کرتا ہے۔
- ایک مسلسل پینل بھرتی کریں؛ ہر پروجیکٹ پر سورسنگ نئے سرے سے شروع نہ کریں۔
- ٹری اپڈیٹ کرنے کے لیے سہ گانے کی ہفتہ وار sync رکھیں، اجازت لینے کے لیے نہیں۔
- بغیر انٹرویو کے کسی بھی ہفتے کو ڈسکوری کا قرض سمجھیں — اسے نام دیں اور ادا کریں۔
- ڈسکوری اور ڈلیوری ایک دوسرے میں بنتے ہیں؛ ایک دوسرے کا گیٹ نہیں ہے۔
Opportunity Solution Tree
OST ایک سلسلہ بصری طور پر دکھاتا ہے: مطلوبہ نتیجہ → مواقع (تحقیق سے ابھرنے والے مسائل / غیر پوری شدہ ضروریات) → امیدوار حل → مفروضہ ٹیسٹ۔ اوپر سے نیچے پڑھیں تو دکھتا ہے کہ ہر حل پر کیوں غور ہو رہا ہے۔ نیچے سے اوپر پڑھیں تو ہر ٹیسٹ ایک حقیقی صارف-موقع تک پہنچتا ہے جو ٹیم کے نتیجے سے بندھا ہے۔
- جڑ میں ایک نتیجہ؛ متعدد مواقع؛ فی موقع متعدد حل؛ فی حل متعدد ٹیسٹ۔
- ایسے حلوں کا مزاحمت کریں جو کسی نامزد موقع تک نہیں جوڑتے۔
- ٹری سے بحث کریں: 'کیا یہ موقع اُس سے بڑا ہے؟'، 'کون سا حل اس موقع کو بہترین نشانہ بناتا ہے؟'
- ہفتہ وار نئی شواہد سے تازہ کریں؛ جن شاخوں کی شواہد کم ہو ان کی کانٹ چھانٹ کریں۔
خطرے-مفروضے کی نقشہ سازی
Marty Cagan ہر پروڈکٹ آئیڈیا کے لیے چار قسم کے خطرات کو الگ کرتے ہیں: قدر (کیا صارفین استعمال کریں گے؟)، قابلِ استعمال ہونا (کیا وہ استعمال کر سکتے ہیں؟)، تکنیکی امکان (کیا ہم بنا سکتے ہیں؟)، اور کاروباری قابلیت (کیا یہ کاروبار کے لیے کام کرتا ہے — لیگل، سیلز، سپورٹ، فنانس؟)۔ ڈسکوری وہ مشق ہے کہ پہچانیں ہر آئیڈیا میں کون سا خطرہ غالب ہے، پھر اس خطرے کو ختم کرنے کے لیے سب سے سستا تجربہ ڈیزائن کریں۔
- قدر کا خطرہ نئی کیٹیگریز اور نئے سامعین میں غالب ہوتا ہے۔
- قابلِ استعمال کا خطرہ بنیادی UI تبدیلیوں میں غالب ہوتا ہے۔
- تکنیکی امکان کا خطرہ تکنیکی طور پر نئے کام (ML، ریئل ٹائم، اسکیل) میں غالب ہوتا ہے۔
- کاروباری قابلیت کا خطرہ ریگولیٹڈ یا قیمت-حساس علاقوں میں غالب ہوتا ہے۔
صارف کا سفر-نقشہ اور سروس بلیو پرنٹس
سفر-نقشے ایک واحد صارف-پرسونا کو وقت کے ساتھ ایک حقیقی ورک فلو سے گزارتے ہیں — اعمال، خیالات، جذبات اور رگڑ کے لمحات کو پکڑتے ہیں۔ سروس بلیو پرنٹس سفر کو پسِ پردہ عمل تک بڑھاتے ہیں — کمپنی، سسٹمز اور پالیسیوں کو کیا کرنا ہے تاکہ سامنے کا لمحہ کام کرے۔ زیادہ تر B2B اور آپس-بھاری پروڈکٹس اسکرین پر نہیں، پسِ پردہ ناکام ہوتے ہیں۔
- ورکشاپ کے اندازوں سے نہیں، بلکہ حقیقی ریکارڈ شدہ سیشن سے نقشہ بنائیں۔
- ہر قدم کو اس سے نشان زد کریں: عمل، خیال، جذبہ، رگڑ، گزرا وقت۔
- سروس بلیو پرنٹس کے لیے، پسِ پردہ اعمال، سپورٹ سسٹمز اور SLAs شامل کریں۔
- ان 'سچائی کے لمحات' کو نمایاں کریں جہاں تجربہ کامیاب ہوتا ہے یا ٹوٹتا ہے۔
سروے ڈیزائن اور زیادہ تر سروے کیوں جھوٹ بولتے ہیں
سروے مقبول ہیں کیونکہ یہ اسکیل کرتے ہیں؛ غلط استعمال ہوتے ہیں کیونکہ یہ آسان ہیں۔ زیادہ تر پروڈکٹ سروے انتخاب کے تعصب (صرف پُرجوش جواب دیتے ہیں)، سماجی پسندیدگی کے تعصب (جواب دہندگان وہی بتاتے ہیں جو وہ سمجھتے ہیں آپ سننا چاہتے ہیں)، اور ترتیب کے اثرات (اوپر کا سوال نیچے کے جواب میں رِستا ہے) کا شکار ہیں۔ سروے ایسی فرضیہ کو مقدار میں ڈھالنے کے لیے کارآمد ہیں جسے آپ نے پہلے سے کوالیٹیٹیو طور پر ترقی دی ہے — صفر سے دریافت کے لیے تقریباً کبھی نہیں۔
- سروے کا استعمال سائز ناپنے کے لیے کریں، دریافت کے لیے نہیں۔
- 'کیا آپ استعمال کریں گے' اور 'آپ کتنا ادا کریں گے' سے بچیں — دونوں ناقابلِ اعتبار ہیں۔
- سوالات کو گزشتہ ہفتے کے رویّے پر لنگر ڈالیں، تجریدی ترجیحات پر نہیں۔
- بھیجنے سے پہلے 10 صارفین پر پائلٹ کریں؛ 80% ڈیزائن غلطیاں پہلے 5 جوابات میں پکڑی جاتی ہیں۔
- ہمیشہ ایک کھلا سوال شامل کریں؛ verbatim عام طور پر ریٹنگ اسکیلز سے زیادہ مفید ہوتے ہیں۔
تثلیث: کوالیٹیٹیو + کوانٹیٹیٹیو + مارکیٹ
ایک ہی ذریعے کی بصیرتیں خطرناک ہیں۔ کوالیٹیٹیو انٹرویوز (کیوں)، کوانٹیٹیٹیو اینالیٹکس (کتنا بڑا)، اور مارکیٹ شواہد (کیا دنیا اس رجحان کی حمایت کرتی ہے؟) کو ملا کر تثلیث کریں۔ جب تینوں متفق ہوں، یقین زیادہ ہوتا ہے۔ جب اختلاف ہو، اختلاف کی پیروی کریں — سب سے مفید سیکھ وہیں رہتی ہے۔
- کوالیٹیٹیو بتاتا ہے کیا ہو رہا ہے اور کیوں۔
- کوانٹیٹیٹیو بتاتا ہے کتنا بڑا اور کتنی بار۔
- مارکیٹ شواہد (مدِمقابل، ملحقہ صنعتیں، ابتدائی اشاریے) بتاتے ہیں ہوا آپ کے حق میں ہے یا خلاف۔
- ہر ذریعے کو اس کے اعتماد کے درجے کے ساتھ دستاویز کریں؛ اوسط نہ نکالیں، وزن دیں۔
ڈسکوری کا آؤٹ پٹ: انسائٹ لائبریری
آرٹیفیکٹ کے بغیر ڈسکوری ایک PM کے سر میں سڑ جاتی ہے۔ ٹیم کو ایک مشترکہ انسائٹ لائبریری چاہیے — ٹیگ شدہ انٹرویو اقتباسات، مواقع، شواہد — جو PM کی تبدیلی سے بچ جائے اور پروجیکٹس کے درمیان جمع ہو۔ یہاں تک کہ مستقل ٹیگنگ کے ساتھ ایک سادہ شیئرڈ ڈاک ایک شاندار مگر تنہا یاد داشت کو شکست دیتا ہے۔
- ہر اقتباس کو اس سے ٹیگ کریں: پرسونا، job، موقع، شدت، اعتماد۔
- لائبریری کو قابلِ تلاش بنائیں؛ اگر آپ 30 سیکنڈ میں ٹیگ شدہ اقتباس نہیں ڈھونڈ سکتے، تو سسٹم ناکام ہے۔
- ہر سہ ماہی میں اوپر کے مواقع کو اگلی سہ ماہی کے OST جڑ-امیدواروں کے طور پر دیکھیں۔
Framework atlas
Reference cards for each method in this mission
Expand a card for when to deploy it, misuse patterns, sequencing guidance, and (where relevant) shorthand formulas.
Discovery interview · Bob Moesta & Chris Spiek (Re-Wired Group / The Rewired Group)Switch / Forces of Progress(Switch)
A structured interview format that reconstructs a user's switch from an old solution to a new one, mapped to the four forces: push, pull, anxiety, habit.
When to use
- Understanding why users adopted (or didn't adopt) a category.
- Pricing and packaging research.
- Churn and switching investigations.
When not to
- Pure usability testing of a specific UI.
- Discovery for an entirely new behavior with no prior solution to switch from.
How to apply
- Recruit users who switched within the last 90 days.
- Anchor the conversation to the day of the switch.
- Probe push, pull, anxiety, habit explicitly with timeline questions.
- Identify the moment of first thought, struggle, deciding event, and consumption event.
- Synthesize forces and map to demand strength.
- Asking about preference instead of behavior.
- Letting users summarize ('I just got tired of it') instead of reconstructing the timeline.
Discovery synthesis · Teresa TorresOpportunity Solution Tree(OST)
Visual structure connecting a desired outcome to opportunities (problems), candidate solutions, and the experiments that test them.
When to use
- Continuous discovery teams aligning on what to learn next.
- Quarterly planning where the outcome is fixed but the path is not.
When not to
- When the team has not yet defined a clear outcome — fix that first.
How to apply
- State the outcome at the root.
- Surface opportunities from research; cluster duplicates.
- Map candidate solutions under each opportunity.
- Define the riskiest assumption per solution and an experiment to test it.
- Update weekly with new evidence; prune unsupported branches.
- Stuffing every feature request as a 'solution' regardless of opportunity fit.
- Letting the tree become a static slide deck instead of a living doc.
Discovery quantification · Tony UlwickOutcome-Driven Innovation(ODI)
Decomposes a job into outcome statements (e.g. 'minimize the time it takes to identify duplicate contacts'), then surveys users on importance and current satisfaction. Opportunity score = importance + max(0, importance - satisfaction).
Opportunity = Importance + max(0, Importance − Satisfaction)
When to use
- Mature markets where the job is well understood and you need to find under-served outcomes.
- Roadmap arbitration when many possible directions look equally appealing.
When not to
- Brand-new categories where the user can't articulate the job yet.
How to apply
- Identify the core functional job through interviews.
- Decompose into outcome statements (verb + object + clarifier, e.g. 'minimize time to ___').
- Survey 100+ users for importance (1-10) and satisfaction (1-10).
- Compute the opportunity score per outcome.
- Prioritize outcomes with score > 12 as under-served opportunities.
- Writing outcome statements that contain solutions ('add an auto-detect button').
- Surveying users who don't actually do the job.
Discovery prioritization · Marty Cagan / SVPGRisk-Assumption Mapping
Categorizes the risks of a product idea into Value, Usability, Feasibility, and Viability and tests the largest risks first with the smallest possible experiment.
When to use
- Before committing eng capacity to a non-trivial bet.
- When the team feels unable to articulate why an idea might fail.
When not to
- Tiny incremental changes where a single A/B test is enough.
How to apply
- List all assumptions the idea depends on.
- Tag each as Value / Usability / Feasibility / Viability risk.
- Score by impact-if-wrong and confidence-now.
- Design the cheapest experiment to retire the top 1-2 risks.
- Re-rank weekly as evidence accumulates.
Root cause analysis · Sakichi Toyoda / Toyota Production SystemFive Whys
Iteratively ask 'why' to walk from a symptom to a root cause. Useful in user interviews, post-mortems, and bug triage.
When to use
- Surface-level user complaints whose real cause is unclear.
- Post-incident reviews.
When not to
- Multi-causal complex systems where a single 'why' chain oversimplifies; use a fishbone diagram instead.
How to apply
- Start with the observed symptom or complaint.
- Ask 'why' and capture the answer; don't accept generalities.
- Repeat 4–5 times until the answer is structural rather than personal.
Product Psychology
Cognitive biases that distort product decisions
Confirmation Bias in Interviews
Interviewers selectively probe and remember evidence that confirms the going hypothesis.
Product Risk
The team walks out of every research round 'validated', regardless of what users actually said.
Research Countermove
Pre-register the hypothesis and the falsification criterion. Have a second interviewer or transcriber tag quotes blind to the hypothesis.
Researcher / Demand Effect
Users mirror what they believe the interviewer wants to hear, especially when interviewer comes from the company that might pay them or refer them.
Product Risk
Hypotheticals get inflated agreement; pricing surveys inflate willingness to pay; feature interest is overstated.
Research Countermove
Use neutral recruiters who don't disclose the hypothesis. Pay users a fixed incentive regardless of stated enthusiasm. Anchor questions in past behavior, not future preference.
Recency Bias in Synthesis
The most recent interview disproportionately influences the synthesis even when earlier interviews carried the same signal.
Product Risk
Roadmaps swing toward whichever user the team last heard from, especially executives or vocal users.
Research Countermove
Tag every quote at intake, not at synthesis. Synthesis should weight every tagged quote equally, not by memorability.
Articulation Bias
Users who can articulate clearly are over-represented; quieter users with the same problem are missed.
Product Risk
Power-user features ship while novice-user pain remains invisible.
Research Countermove
Recruit deliberately across articulation styles; supplement interviews with observation, screen-share recordings, and unmoderated tests.
Hawthorne Effect
Users behave differently because they know they're being observed.
Product Risk
Lab usability tests overstate competence; users perform for the researcher.
Research Countermove
Use unmoderated remote tests, in-product analytics, and longitudinal studies whenever possible. Treat moderated lab tests as one of multiple data sources.
Cargo-Cult Discovery
Adopting discovery rituals (interviews, OSTs, story maps) without the underlying behavioral change in the team's decision-making.
Product Risk
Discovery becomes documentation theater; the same backlog ships regardless of what was learned.
Research Countermove
Tie every discovery output to a decision: 'This week's research changes our roadmap in this specific way, or it changes our confidence in this specific item.'
Organizational anti-patterns
When ceremonies look like rigor but aren't
Validating, Not Discovering
Research is scheduled after the spec is written; goal is to confirm rather than challenge.
PM has already committed to the solution and uses 'discovery' as a checkpoint to feel safe.
Run discovery before scoping. If you must run it after, give the team explicit permission to kill the idea based on findings.
The Persona Slide That Lives Forever
A glossy persona deck made 18 months ago is still cited in decisions; nobody can name a real recent user.
Personas are easier to display than to maintain; nobody owns their freshness.
Replace static personas with a continuous panel. Cite real recent quotes and behaviors in decisions, not 'Marketer Mary'.
Survey-First Discovery
The team's first move on every new question is to send a survey.
Surveys feel scientific and scale fast; interviews feel slow and subjective.
Lead with 5-7 interviews; only survey to size what interviews already revealed qualitatively.
The Loudest User Drives the Roadmap
Roadmap shifts in response to the latest angry support ticket or executive escalation.
Without an aggregated insight library, vivid recent feedback wins by default.
Aggregate weekly: count themes across interviews, support tickets, NPS verbatims, and churn reasons. Make the count visible in roadmap meetings.
Insights as Slide Decks
Research findings live as polished one-time decks; they don't accumulate into a searchable corpus.
Researchers and PMs are rewarded for visible deliverables, not infrastructure.
Standardize tagging. Build a searchable repository — even a structured Notion/Coda/Airtable database is enough.
Worked examples
Walkthroughs translated from real trade-off rooms
Catching a phantom feature with a switch interview
A team is convinced users want richer reporting. Surveys show 78% interest. Internal advocates are pushing for a Q1 build.
- Run 8 switch interviews with users who recently adopted a competitor that already has rich reporting.
- Map the four forces. Push and pull are real; anxieties (cost, change) are large; habit (existing internal dashboards) is the largest force.
- Find that only 2/8 actually use the rich reporting after switching; 6/8 still rely on legacy dashboards exported to spreadsheets.
- Reframe the opportunity: not 'rich reporting in product' but 'reduce the spreadsheet round-trip'. Ship a CSV export with templated views in 3 weeks instead of a 4-month reporting build.
TakeawayStated demand was real but did not translate into post-switch usage. The actual job was about leaving the product, not staying in it.
Using ODI to find the under-served outcome
A meeting-notes product wants to know which AI feature to build first.
- Interview 12 users to identify the functional job: 'capture decisions and action items from a meeting'.
- Decompose into 14 outcome statements, e.g. 'minimize time to identify action items', 'minimize chance of missing a decision'.
- Survey 200 users for importance and satisfaction.
- Highest opportunity scores: 'minimize time to share notes with absentees' (15.2) and 'minimize chance of missing a decision' (14.8).
- Lower than expected: 'minimize time to identify action items' (10.1) — already considered well-served by the existing product.
TakeawayODI redirected the team from auto-summarization (already satisfying) toward decision tracking and absentee summaries (under-served).
Killing a feature using risk-assumption mapping
Team wants to add an in-app marketplace for third-party integrations.
- List assumptions: users want to discover integrations in-product; partners will list; we can review submissions; legal can manage liability; revenue model works.
- Tag risks: Value (partial — direct evidence weak), Viability (dominant — legal & revenue model unsolved), Feasibility (medium).
- Test viability first with 5 partner conversations and a legal review — both come back negative under current contracts.
- Kill the marketplace; instead, ship a curated integrations directory and a partner program with handpicked launch partners.
TakeawayThe dominant risk was viability, not value. Testing the right risk first prevented a 6-month build that would have shipped into a legal wall.
Resources / Case Studies
Curated reading for this mission
Teresa Torres
The canonical operating manual for weekly discovery practices, the Opportunity Solution Tree, and assumption testing.
The single most actionable book on modern discovery practice; every team benefits from running its first 90 days.
Teresa Torres
The original blog series introducing the OST as a connective tissue between outcomes, opportunities, solutions, and tests.
The clearest free reference for the OST diagram and its discipline.
Bob Moesta
Moesta's articulation of JTBD applied to selling. Covers the four forces, switching moments, and the timeline interview.
Translates JTBD from theory to operational interview craft for PMs and sales partners.
Tony Ulwick (Strategyn)
Ulwick's school of JTBD with outcome-driven innovation, opportunity scoring, and quantitative discovery.
The right tool when the team needs to size and prioritize unmet needs at scale, not just understand them qualitatively.
Marty Cagan (SVPG)
Cagan's Value/Usability/Feasibility/Viability framework and prototyping techniques for retiring each risk type.
Establishes the risk-typing language that the rest of the industry uses.
Steve Portigal
Portigal's craft-level guide to interviewing users without leading them. Covers question design, listening, and synthesis.
The best stand-alone book on interview mechanics, especially for PMs without UX research training.
Rob Fitzpatrick
How to run customer conversations that surface real evidence even when users (and your mom) want to be encouraging.
A 90-minute read that fixes the most common interview mistake — asking questions that beg for compliments.
Product Talk
Templates for OSTs, interview snapshots, and weekly trio cadences.
Saves teams the design-thinking-template hunt; production-ready artifacts to drop into Notion or Miro.
Alan Klement
JTBD case study showing how customers hire and fire products through unexpected substitutions.
Strong narrative companion to the Switch interview methodology.
Lenny Rachitsky
Practitioner case studies on user research from PMs at Airbnb, Stripe, Notion, and more.
Recurring real-world examples from current product teams; a complement to the canonical books.
Alberto Savoia
Pretotyping and the search for 'the right it' before 'building it right'. Practical low-cost demand experiments.
Bridges discovery and early experimentation, with concrete templates for fake-door tests, smoke tests, and the like.
How to operationalize ongoing user research at scale: panels, ops, tooling, and synthesis.
Covers the operational layer that most discovery books skip.