درباره ارزش، هزینه، ریسک و چیزی که در نهایت یک تصمیم محصولی را توجیه می‌کند
فرض کنید تغییری در محصول پیدا کرده‌اید که می‌تواند نرخ تبدیل را به‌طور محسوسی افزایش دهد.
از نگاه Growth، تصمیم جذابی است.
از نگاه کاربر هم شاید مسیر ساده‌تر و کوتاه‌تر شود.
تیم فنی هم می‌گوید اجرای آن شدنی است.
پس احتمالاً باید انجامش بدهیم، درست است؟
نه لزوماً.
اگر همان تغییر باعث شود نرخ لغو بالاتر برود چه؟
اگر هزینه عملیات افزایش پیدا کند؟
اگر ریسک تقلب بیشتر شود؟
اگر بخشی از مسئله فقط از یک مرحله محصول به مرحله دیگری منتقل شود؟
یا حتی اگر همه این اتفاق‌ها نیفتد، اما تیم برای اجرای آن دو ماه زمان بگذارد، در حالی که همان منابع می‌توانستند روی مسئله‌ای با ارزش بسیار بیشتر سرمایه‌گذاری شوند، باز هم تصمیم خوبی گرفته‌ایم؟
هرچه بیشتر در Product کار می‌کنم، بیشتر به یک اصل ساده باور پیدا می‌کنم:
تقریباً هیچ فیچری فقط ارزش ایجاد نمی‌کند.
هر تصمیم محصولی در کنار ارزشی که می‌سازد، هزینه، ریسک و پیامدهایی هم به سیستم اضافه می‌کند.
و بخش مهم Product Management، نه پیدا کردن Benefitها، بلکه دیدن تمام این تصویر است.
بیشتر ایده‌های محصولی که به مرحله بررسی جدی می‌رسند، احتمالاً نوعی ارزش ایجاد می‌کنند.
ممکن است تجربه کاربر را بهتر کنند.
ممکن است Conversion را افزایش دهند.
ممکن است Retention را بهتر کنند.
ممکن است Risk را کاهش دهند.
یا هزینه‌ای را از کسب‌وکار کم کنند.
بنابراین سؤال:
«آیا این فیچر ارزش ایجاد می‌کند؟»
معمولاً سؤال چندان سختی نیست.
خیلی وقت‌ها جواب یک «بله» کاملاً قاطع است.
اما سؤال مهم‌تر این است:
ارزشی که انتظار داریم این تصمیم ایجاد کند، در مقایسه با هزینه و ریسکی که به همراه دارد چقدر است؟
این تغییر کوچک در صورت سؤال، کیفیت تصمیم را کاملاً عوض می‌کند.
برای مثال، اضافه کردن یک مرحله KYC ممکن است ریسک Fraud را کاهش دهد.
این یک ارزش واقعی است.
اما همان مرحله می‌تواند Friction ایجاد کند، نرخ تکمیل را پایین بیاورد و بخشی از کاربران سالم را هم از مسیر خارج کند.
هیچ‌کدام از این دو طرف به‌تنهایی تصویر کاملی از تصمیم نمی‌دهند.
تصمیم زمانی معنا پیدا می‌کند که هر دو را کنار هم ببینیم.
یکی از ساده‌ترین دام‌های تصمیم‌گیری در محصول، Local Optimization است.
فرض کنید یک تغییر باعث شود Conversion Rate بهتر شود.
Dashboard سبز می‌شود.
تیم به Target می‌رسد.
Experiment موفق اعلام می‌شود.
اما آیا Business واقعاً بهتر شده است؟
اگر در همان زمان Cancellation Rate افزایش پیدا کرده باشد چه؟
اگر تعداد تماس با پشتیبانی بیشتر شده باشد؟
اگر Cost-to-Serve افزایش پیدا کرده باشد؟
اگر کیفیت سفارش‌هایی که وارد مراحل بعدی می‌شوند پایین آمده باشد؟
اگر Fraud افزایش پیدا کرده باشد؟
ممکن است یک متریک به‌وضوح بهتر شده باشد، در حالی که خالص ارزش ایجادشده برای کسب‌وکار منفی باشد.
دلیلش ساده است:
محصول یک سیستم است، نه مجموعه‌ای از متریک‌های مستقل.
تغییر در یک نقطه از محصول تقریباً همیشه می‌تواند در جای دیگری اثر بگذارد.
گاهی Friction را حذف نمی‌کنیم؛ فقط آن را به مرحله دیگری منتقل می‌کنیم.
گاهی Cost را کاهش نمی‌دهیم؛ فقط از Product به Operations منتقلش می‌کنیم.
گاهی Conversion را افزایش می‌دهیم، اما کیفیت Conversion پایین می‌آید.
به همین دلیل، اثر مستقیم یک Feature فقط بخشی از تصمیم است.
یک Product Manager باید علاوه بر اثر مستقیم، پیامدهای مرتبه دوم تصمیم را هم ببیند.
یعنی نه فقط بپرسد:
«بعد از این تغییر چه اتفاقی می‌افتد؟»
بلکه:
«بعد از آن اتفاق، چه اتفاق دیگری می‌افتد؟»
یکی دیگر از خطاهای رایج این است که هزینه Feature را با Story Point، تعداد Sprint یا ظرفیت Engineering بسنجیم.
Development Cost مهم است؛ اما معمولاً فقط بخش قابل مشاهده هزینه است.
هر Feature می‌تواند چند نوع هزینه ایجاد کند.
هر مرحله اضافه در Journey یک هزینه دارد.
هر Form، هر Permission، هر Verification، هر انتخاب و هر زمانی که از کاربر می‌گیریم، بخشی از Attention او را مصرف می‌کند.
ممکن است این هزینه خودش را در Drop-off نشان دهد.
ممکن است در Conversion دیده شود.
ممکن است هم هیچ‌کدام را به‌طور واضح تغییر ندهد، اما تجربه کاربر را آرام‌آرام بدتر کند.
گاهی بهترین UX را با انتقال پیچیدگی به پشت صحنه ایجاد می‌کنیم.
فرآیند برای کاربر بسیار ساده‌تر می‌شود، اما حالا تیم Operations باید چند Step جدید را به‌صورت دستی انجام دهد.
از نگاه Product، تجربه بهتر شده است.
اما از نگاه Business، هزینه همچنان وجود دارد.
فقط صاحب آن تغییر کرده است.
Feature زمانی که Release می‌شود تمام نمی‌شود.
تازه تبدیل به چیزی می‌شود که باید برای ماه‌ها یا سال‌ها نگهداری شود.
باید Monitoring داشته باشد.
باید Bugهایش برطرف شود.
باید با تغییرات آینده سازگار شود.
ممکن است Dependency جدید بسازد.
یا در آینده سرعت توسعه را کاهش دهد.
هر Feature در واقع مقداری تعهد آینده ایجاد می‌کند.
محصولات معمولاً یک‌شبه پیچیده نمی‌شوند.
پیچیدگی نتیجه تعداد زیادی تصمیم کوچک و منطقی است.
یک Option جدید.
یک Rule جدید.
یک State جدید.
یک Exception دیگر برای یک Edge Case.
هر کدام به‌تنهایی قابل دفاع‌اند.
اما مجموع آن‌ها می‌تواند محصولی بسازد که فهمیدن، توسعه دادن و حتی استفاده کردن از آن دشوار شده است.
شاید مهم‌ترین Cost همین باشد.
هر بار که تصمیم می‌گیریم کاری را انجام دهیم، هم‌زمان تصمیم گرفته‌ایم چند کار دیگر را انجام ندهیم.
ظرفیت تیم محدود است.
زمان محدود است.
سرمایه محدود است.
Attention سازمان هم محدود است.
بنابراین ممکن است یک Feature واقعاً ارزشمند باشد، اما همچنان تصمیم اشتباهی باشد.
چون همان منابع در جای دیگری می‌توانستند چند برابر ارزش بیشتری ایجاد کنند.
اینجاست که سؤال از:
«آیا ارزش ساختن دارد؟»
به این تبدیل می‌شود:
«آیا در این مقطع، بهترین جایی است که می‌توانیم منابعمان را روی آن سرمایه‌گذاری کنیم؟»
در Product تقریباً هیچ‌وقت همه اطلاعات را نداریم.
دیتا داریم.
User Research داریم.
تجربه داریم.
Benchmark داریم.
Experiment داریم.
اما در نهایت، بخش زیادی از تصمیم‌های مهم را در شرایطی می‌گیریم که هنوز مقداری عدم قطعیت وجود دارد.
یعنی در عمل، داریم روی یک Hypothesis سرمایه‌گذاری می‌کنیم.
فرض می‌کنیم:
اگر این مرحله را حذف کنیم، Conversion افزایش پیدا می‌کند.
اگر Verification را سخت‌گیرانه‌تر کنیم، Fraud کاهش پیدا می‌کند.
اگر این Feature را اضافه کنیم، کاربران بیشتر برمی‌گردند.
اگر تجربه را ساده‌تر کنیم، Completion Rate بهتر می‌شود.
هیچ‌کدام از این‌ها قبل از اجرا حقیقت قطعی نیستند.
برای همین، ارزیابی یک تصمیم فقط با Potential Upside کافی نیست.
باید حداقل چهار موضوع را کنار هم دید:
ارزش مورد انتظار:
اگر فرض ما درست باشد، چه میزان ارزش ایجاد می‌کنیم؟
هزینه:
برای رسیدن به آن ارزش، چه چیزی باید خرج کنیم؟
ریسک:
اگر اشتباه کرده باشیم، Downside چقدر است؟
قابلیت بازگشت:
اگر تصمیم بدی گرفته باشیم، با چه هزینه‌ای می‌توانیم آن را اصلاح کنیم؟
موضوع آخر به نظرم بسیار مهم است.
تصمیمی که به‌راحتی قابل بازگشت است، با تصمیمی که ماه‌ها اثرش در محصول و عملیات باقی می‌ماند، نباید با یک سطح از اطمینان گرفته شود.
هرچه تصمیم Irreversibleتر باشد، باید شواهد قوی‌تری برای گرفتنش داشته باشیم.
هرچه بیشتر در Product کار می‌کنم، بیشتر معتقدم Product Manager بدون درک عمیق Business، نهایتاً تبدیل می‌شود به مدیر Feature.
چون Feature هدف نیست.
Metric هم هدف نیست.
حتی Product به‌تنهایی هدف نهایی نیست.
Product ابزاری است برای اینکه یک Business بتواند به‌شکل پایدار ارزش ایجاد کند، آن ارزش را به مشتری برساند و بخشی از آن را برای ادامه حیات خودش دریافت کند.
به همین دلیل، من به جمله‌ای باور دارم که شاید در نگاه اول کمی تند به نظر برسد:
در نهایت، هیچ‌چیز از Business مهم‌تر نیست.
اما این جمله به این معنا نیست که Revenue این ماه از همه‌چیز مهم‌تر است.
اتفاقاً چنین نگاهی خودش می‌تواند ضد Business باشد.
گاهی بهترین تصمیم برای Business این است که درآمد کوتاه‌مدت را قربانی اعتماد بلندمدت کند.
گاهی باید Conversion کمتری را بپذیریم تا Risk کنترل شود.
گاهی باید Margin پایین‌تری داشته باشیم تا یک مزیت رقابتی جدی شکل بگیرد.
گاهی باید هزینه بیشتری برای Experience بدهیم، چون Retention حاصل از آن در بلندمدت ارزش بیشتری می‌سازد.
و گاهی هم باید Featureای را که User دوست دارد نسازیم، چون هزینه و پیچیدگی آن برای Business قابل توجیه نیست.
پس وقتی می‌گویم Business مهم‌ترین معیار است، منظورم بیشینه کردن درآمد کوتاه‌مدت نیست.
منظورم سلامت و پایداری کل سیستم است.
گاهی User و Business را به شکل دو طرف متضاد یک تصمیم نشان می‌دهیم.
«این تصمیم برای کاربر خوب است، ولی برای Business بد.»
یا برعکس.
در دنیای واقعی ممکن است چنین تعارض‌هایی وجود داشته باشد، اما یک Product پایدار نمی‌تواند برای مدت طولانی روی این تضاد بنا شود.
Business زمانی می‌تواند ادامه پیدا کند که برای User ارزش واقعی ایجاد کند.
و User Value زمانی می‌تواند ادامه پیدا کند که Business توان تأمین هزینه ایجاد و ارائه آن را داشته باشد.
بهترین Experience دنیا اگر Economics آن کار نکند، پایدار نیست.
و بهترین مدل درآمدی دنیا هم اگر Value واقعی برای User نداشته باشد، در بلندمدت دوام نمی‌آورد.
یکی از مهم‌ترین مسئولیت‌های Product همین است:
پیدا کردن نقطه‌ای که User Value و Business Value تا حد ممکن در یک جهت قرار بگیرند.
این نقطه همیشه کامل و بدون اصطکاک نیست.
اما باید قابل دوام باشد.
Trade-off یکی از پرکاربردترین کلمات Product است.
اما فکر می‌کنم گاهی آن‌قدر استفاده می‌شود که معنای اصلی‌اش کمرنگ شده است.
Trade-off فقط یعنی انتخاب بین دو گزینه؟
به نظرم نه.
Trade-off یعنی:
برای به دست آوردن یک ارزش، آگاهانه حاضر باشیم هزینه‌ای را بپذیریم.
اگر Security بیشتری می‌خواهیم، ممکن است Friction بیشتری ایجاد کنیم.
اگر Speed برایمان مهم‌تر است، شاید Scope را کاهش دهیم.
اگر Customization بیشتری ارائه کنیم، احتمالاً بخشی از Simplicity را قربانی می‌کنیم.
اگر Conversion بیشتری می‌خواهیم، ممکن است لازم باشد Risk بالاتری بپذیریم.
تصمیم خوب لزوماً تصمیمی نیست که Cost ندارد.
بیشتر وقت‌ها چنین تصمیمی اصلاً وجود ندارد.
تصمیم خوب، تصمیمی است که بدانیم چه چیزی به دست می‌آوریم، بدانیم چه چیزی از دست می‌دهیم و آگاهانه بپذیریم که این مبادله ارزشش را دارد.
به همین دلیل، یکی از سؤال‌های مورد علاقه من در تصمیم‌های محصولی این است:
«برای ایجاد این ارزش، حاضر هستیم چه هزینه‌ای بپردازیم؟»
گاهی پاسخ همین سؤال، بحث‌های طولانی Product را خیلی سریع روشن می‌کند.
اگر این مدل ذهنی را وارد Measurement کنیم، اهمیت Guardrail Metrics هم واضح‌تر می‌شود.
فرض کنید Success Metric یک Experiment، Conversion Rate است.
Experiment اجرا می‌شود و Conversion افزایش پیدا می‌کند.
آیا موفق شده‌ایم؟
هنوز نمی‌دانیم.
باید ببینیم:
آیا Cancellation Rate تغییر کرده؟
Fraud چه شده؟
NPS چطور؟
Refund چقدر تغییر کرده؟
Cost-to-Serve چه تغییری کرده؟
آیا Operations توان جذب حجم جدید را دارد؟
Success Metric به ما می‌گوید:
آیا چیزی را که می‌خواستیم به دست آوردیم؟
Guardrailها سؤال دیگری می‌پرسند:
برای به دست آوردنش چه هزینه‌ای پرداخت کردیم؟
و به نظرم ارزیابی واقعی یک Product Decision جایی میان همین دو قرار دارد.
نه صرفاً مقدار Value ایجادشده، بلکه:
خالص ارزش ایجادشده پس از در نظر گرفتن هزینه و ریسک.
ساختن Feature دیده می‌شود.
Release دارد.
Demo دارد.
Metric دارد.
و معمولاً احساس پیشرفت ایجاد می‌کند.
اما بخش مهمی از Product Management چیزهایی است که هیچ‌وقت Release نمی‌شوند.
Featureای که User واقعاً می‌خواست، اما Priority بالاتری وجود داشت.
ایده‌ای که می‌توانست یک Metric را بهتر کند، اما هزینه نگهداری آن قابل توجیه نبود.
پروژه‌ای که بازده مثبت داشت، اما Opportunity Cost آن بالا بود.
یا راه‌حلی که جذاب بود، اما Risk آن نسبت به Value مورد انتظار منطقی نبود.
به نظرم یکی از نشانه‌های بلوغ یک Product Team، تعداد Featureهایی نیست که می‌تواند بسازد.
توانایی آن در گفتن یک «نه» آگاهانه است.
نه به یک ایده بد آسان است.
قسمت سخت، نه گفتن به یک ایده خوب است؛ چون انتخاب بهتری وجود دارد.
برای خودم، قبل از تصمیم‌های مهم محصولی چند سؤال کلیدی وجود دارد:
این تصمیم دقیقاً چه ارزش کسب‌وکاری ایجاد می‌کند؟
اندازه این ارزش چقدر است؟
هزینه واقعی آن چیست؛ نه فقط برای Engineering، بلکه برای User، Operations و آینده Product؟
اگر فرضمان اشتباه باشد، چه ریسکی ایجاد می‌شود؟
چقدر به شواهدی که داریم اطمینان داریم؟
اگر اشتباه کنیم، چقدر راحت می‌توانیم برگردیم؟
آیا راه ارزان‌تری برای تست Hypothesis وجود دارد؟
و شاید مهم‌تر از همه:
آیا این بهترین استفاده‌ای است که الان می‌توانیم از منابع محدود Business داشته باشیم؟
اگر پاسخ این سؤال‌ها روشن نباشد، شاید هنوز زمان Build نرسیده باشد.
بخش قابل مشاهده Product Management، چیزهایی است که ساخته و Release می‌شوند.
اما فکر می‌کنم ارزش واقعی این نقش، بیشتر در تصمیم‌هایی است که قبل از Build گرفته می‌شوند.
اینکه بدانیم چه مسئله‌ای ارزش حل کردن دارد.
چه چیزی الان مهم نیست.
برای چه چیزی باید سرمایه‌گذاری کنیم.
کدام Risk ارزش پذیرفتن دارد.
کجا باید سریع Experiment کنیم.
و کجا باید محتاط‌تر باشیم.
کدام هزینه منطقی است.
و کدام Trade-off دیگر ارزشش را ندارد.
تقریباً هیچ تصمیم مهمی در Product فقط یک پاسخ درست ندارد.
هر تصمیم ترکیبی است از ارزش، هزینه، ریسک، فرصت و عدم قطعیت.
و شاید یکی از مهم‌ترین مهارت‌های یک Product Manager این باشد که:
جایی که دیگران فقط ارزش را می‌بینند، هزینه را هم ببیند.
و جایی که دیگران فقط یک Feature می‌بینند، اثر آن را روی کل Business بسنجد.
چون در نهایت سؤال اصلی این نیست:
Can we build it?
حتی فقط این هم نیست:
Will users like it?
سؤال واقعی سخت‌تر است:
آیا ارزش مورد انتظار این تصمیم، هزینه و ریسک آن را توجیه می‌کند؟
و خیلی وقت‌ها پاسخ حرفه‌ای به یک ایده خوب، «بسازیم» یا «نسازیم» نیست.
پاسخ این است:
«ارزش دارد؛ اما نه با این هزینه، نه با این ریسک، یا نه در این مقطع.»
برای ویرگول، این عنوان را هم از نسخه قبلی قوی‌تر می‌دانم: «یک فیچر خوب، لزوماً تصمیم خوبی نیست»؛ چون از همان ابتدا تضاد اصلی مقاله را روشن می‌کند و کنجکاوی بیشتری ایجاد می‌کند.
