https://virgool.ir/feed/@m_83662544Agile Coach - Product managerfa2026-11-10 18:46:50https://files.virgool.ir/upload/users/1500771/avatar/i8h6MB.jpeghttps://virgool.ir/@m_83662544https://virgool.ir/@m_83662544/ارزش-هزینه-ریسک-سه-ضلع-تصمیم-محصولی-akkk1qd6sbcc درباره ارزش، هزینه، ریسک و چیزی که در نهایت یک تصمیم محصولی را توجیه می‌کندفرض کنید تغییری در محصول پیدا کرده‌اید که می‌تواند نرخ تبدیل را به‌طور محسوسی افزایش دهد.از نگاه 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 باید علاوه بر اثر مستقیم، پیامدهای مرتبه دوم تصمیم را هم ببیند.یعنی نه فقط بپرسد:«بعد از این تغییر چه اتفاقی می‌افتد؟»بلکه:«بعد از آن اتفاق، چه اتفاق دیگری می‌افتد؟»هزینه واقعی یک فیچر فقط Development Cost نیستیکی دیگر از خطاهای رایج این است که هزینه 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تر باشد، باید شواهد قوی‌تری برای گرفتنش داشته باشیم.اینجاست که Business مهم می‌شودهرچه بیشتر در Product کار می‌کنم، بیشتر معتقدم Product Manager بدون درک عمیق Business، نهایتاً تبدیل می‌شود به مدیر Feature.چون Feature هدف نیست.Metric هم هدف نیست.حتی Product به‌تنهایی هدف نهایی نیست.Product ابزاری است برای اینکه یک Business بتواند به‌شکل پایدار ارزش ایجاد کند، آن ارزش را به مشتری برساند و بخشی از آن را برای ادامه حیات خودش دریافت کند.به همین دلیل، من به جمله‌ای باور دارم که شاید در نگاه اول کمی تند به نظر برسد:در نهایت، هیچ‌چیز از Business مهم‌تر نیست.اما این جمله به این معنا نیست که Revenue این ماه از همه‌چیز مهم‌تر است.اتفاقاً چنین نگاهی خودش می‌تواند ضد Business باشد.گاهی بهترین تصمیم برای Business این است که درآمد کوتاه‌مدت را قربانی اعتماد بلندمدت کند.گاهی باید Conversion کمتری را بپذیریم تا Risk کنترل شود.گاهی باید Margin پایین‌تری داشته باشیم تا یک مزیت رقابتی جدی شکل بگیرد.گاهی باید هزینه بیشتری برای Experience بدهیم، چون Retention حاصل از آن در بلندمدت ارزش بیشتری می‌سازد.و گاهی هم باید Featureای را که User دوست دارد نسازیم، چون هزینه و پیچیدگی آن برای Business قابل توجیه نیست.پس وقتی می‌گویم Business مهم‌ترین معیار است، منظورم بیشینه کردن درآمد کوتاه‌مدت نیست.منظورم سلامت و پایداری کل سیستم است.User Value و Business Value قرار نیست دشمن هم باشندگاهی User و Business را به شکل دو طرف متضاد یک تصمیم نشان می‌دهیم.«این تصمیم برای کاربر خوب است، ولی برای Business بد.»یا برعکس.در دنیای واقعی ممکن است چنین تعارض‌هایی وجود داشته باشد، اما یک Product پایدار نمی‌تواند برای مدت طولانی روی این تضاد بنا شود.Business زمانی می‌تواند ادامه پیدا کند که برای User ارزش واقعی ایجاد کند.و User Value زمانی می‌تواند ادامه پیدا کند که Business توان تأمین هزینه ایجاد و ارائه آن را داشته باشد.بهترین Experience دنیا اگر Economics آن کار نکند، پایدار نیست.و بهترین مدل درآمدی دنیا هم اگر Value واقعی برای User نداشته باشد، در بلندمدت دوام نمی‌آورد.یکی از مهم‌ترین مسئولیت‌های Product همین است:پیدا کردن نقطه‌ای که User Value و Business Value تا حد ممکن در یک جهت قرار بگیرند.این نقطه همیشه کامل و بدون اصطکاک نیست.اما باید قابل دوام باشد.Trade-off دقیقاً یعنی چه؟Trade-off یکی از پرکاربردترین کلمات Product است.اما فکر می‌کنم گاهی آن‌قدر استفاده می‌شود که معنای اصلی‌اش کمرنگ شده است.Trade-off فقط یعنی انتخاب بین دو گزینه؟به نظرم نه.Trade-off یعنی:برای به دست آوردن یک ارزش، آگاهانه حاضر باشیم هزینه‌ای را بپذیریم.اگر Security بیشتری می‌خواهیم، ممکن است Friction بیشتری ایجاد کنیم.اگر Speed برایمان مهم‌تر است، شاید Scope را کاهش دهیم.اگر Customization بیشتری ارائه کنیم، احتمالاً بخشی از Simplicity را قربانی می‌کنیم.اگر Conversion بیشتری می‌خواهیم، ممکن است لازم باشد Risk بالاتری بپذیریم.تصمیم خوب لزوماً تصمیمی نیست که Cost ندارد.بیشتر وقت‌ها چنین تصمیمی اصلاً وجود ندارد.تصمیم خوب، تصمیمی است که بدانیم چه چیزی به دست می‌آوریم، بدانیم چه چیزی از دست می‌دهیم و آگاهانه بپذیریم که این مبادله ارزشش را دارد.به همین دلیل، یکی از سؤال‌های مورد علاقه من در تصمیم‌های محصولی این است:«برای ایجاد این ارزش، حاضر هستیم چه هزینه‌ای بپردازیم؟»گاهی پاسخ همین سؤال، بحث‌های طولانی Product را خیلی سریع روشن می‌کند.Success Metric بدون Guardrail می‌تواند گمراه‌کننده باشداگر این مدل ذهنی را وارد 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هایی نیست که می‌تواند بسازد.توانایی آن در گفتن یک «نه» آگاهانه است.نه به یک ایده بد آسان است.قسمت سخت، نه گفتن به یک ایده خوب است؛ چون انتخاب بهتری وجود دارد.قبل از اینکه Build کنیمبرای خودم، قبل از تصمیم‌های مهم محصولی چند سؤال کلیدی وجود دارد:این تصمیم دقیقاً چه ارزش کسب‌وکاری ایجاد می‌کند؟اندازه این ارزش چقدر است؟هزینه واقعی آن چیست؛ نه فقط برای Engineering، بلکه برای User، Operations و آینده Product؟اگر فرضمان اشتباه باشد، چه ریسکی ایجاد می‌شود؟چقدر به شواهدی که داریم اطمینان داریم؟اگر اشتباه کنیم، چقدر راحت می‌توانیم برگردیم؟آیا راه ارزان‌تری برای تست Hypothesis وجود دارد؟و شاید مهم‌تر از همه:آیا این بهترین استفاده‌ای است که الان می‌توانیم از منابع محدود Business داشته باشیم؟اگر پاسخ این سؤال‌ها روشن نباشد، شاید هنوز زمان Build نرسیده باشد.Product Management بیشتر از ساختن، درباره کیفیت تصمیم استبخش قابل مشاهده Product Management، چیزهایی است که ساخته و Release می‌شوند.اما فکر می‌کنم ارزش واقعی این نقش، بیشتر در تصمیم‌هایی است که قبل از Build گرفته می‌شوند.اینکه بدانیم چه مسئله‌ای ارزش حل کردن دارد.چه چیزی الان مهم نیست.برای چه چیزی باید سرمایه‌گذاری کنیم.کدام Risk ارزش پذیرفتن دارد.کجا باید سریع Experiment کنیم.و کجا باید محتاط‌تر باشیم.کدام هزینه منطقی است.و کدام Trade-off دیگر ارزشش را ندارد.تقریباً هیچ تصمیم مهمی در Product فقط یک پاسخ درست ندارد.هر تصمیم ترکیبی است از ارزش، هزینه، ریسک، فرصت و عدم قطعیت.و شاید یکی از مهم‌ترین مهارت‌های یک Product Manager این باشد که:جایی که دیگران فقط ارزش را می‌بینند، هزینه را هم ببیند.و جایی که دیگران فقط یک Feature می‌بینند، اثر آن را روی کل Business بسنجد.چون در نهایت سؤال اصلی این نیست:Can we build it?حتی فقط این هم نیست:Will users like it?سؤال واقعی سخت‌تر است:آیا ارزش مورد انتظار این تصمیم، هزینه و ریسک آن را توجیه می‌کند؟و خیلی وقت‌ها پاسخ حرفه‌ای به یک ایده خوب، «بسازیم» یا «نسازیم» نیست.پاسخ این است:«ارزش دارد؛ اما نه با این هزینه، نه با این ریسک، یا نه در این مقطع.»برای ویرگول، این عنوان را هم از نسخه قبلی قوی‌تر می‌دانم: «یک فیچر خوب، لزوماً تصمیم خوبی نیست»؛ چون از همان ابتدا تضاد اصلی مقاله را روشن می‌کند و کنجکاوی بیشتری ایجاد می‌کند.بهزاد عربگریبهزاد عربگریThu, 10 Sep 2026 15:43:36 +0330https://virgool.ir/@m_83662544/محصول-شما-مشکل-فیچر-ندارد-مشکل-تصمیم-دارد-vblixblsvzwyچرا بیشتر تیم‌های محصول، مشغول حل کردن اشتباه‌ترین مسئله هستند؟چند سال پیش اگر از یک Product Manager می‌پرسیدید محصول خوب چه محصولی است، احتمالاً از تعداد قابلیت‌ها، نوآوری یا سرعت توسعه حرف می‌زد.امروز اگر همان سؤال را بپرسید، پاسخ‌ها حرفه‌ای‌تر شده‌اند.داده.NPS.Product Discovery.Experimentation.Customer Centricity.همه این‌ها درست‌اند.اما به نظرم یک سؤال مهم هنوز کمتر پرسیده می‌شود:چرا با وجود اینکه داده بیشتری داریم، ابزارهای بهتری داریم و بیشتر از گذشته با کاربران صحبت می‌کنیم، هنوز تعداد زیادی محصول شکست می‌خورند؟مشکل این نیست که تیم‌ها داده ندارند.مشکل این است که داده را با تصمیم اشتباه می‌گیرند.هر محصول، نتیجه هزاران تصمیم است؛ نه هزاران فیچر.وقتی درباره محصول صحبت می‌کنیم، معمولاً خروجی را می‌بینیم.صفحه جدید.قابلیت جدید.داشبورد جدید.اما محصول از این‌ها ساخته نشده است.محصول، نتیجه هزاران تصمیم کوچک و بزرگی است که قبل از ساختن گرفته شده‌اند.اینکه چه چیزی را نبینیم.چه چیزی را نسازیم.چه مسئله‌ای را اصلاً حل نکنیم.و مهم‌تر از همه...کدام فرض را قبل از هزینه کردن، به چالش بکشیم.بزرگ‌ترین دشمن محصول، پیچیدگی نیست.اطمینان کاذب است.خیلی از تصمیم‌های بد، از کمبود اطلاعات نمی‌آیند.از این می‌آیند که فکر می‌کنیم اطلاعات کافی داریم.کاربر گفته این قابلیت را می‌خواهد.داده نشان می‌دهد نرخ تبدیل افت کرده است.رقیب این ویژگی را اضافه کرده است.همه این‌ها ممکن است درست باشند.اما هیچ‌کدام الزاماً مسئله واقعی را توضیح نمی‌دهند.تیم‌های ضعیف سریع جواب پیدا می‌کنند.تیم‌های خوب، بیشتر سؤال می‌پرسند.ما عاشق راه‌حل‌ها هستیم.چون راه‌حل‌ها قابل اندازه‌گیری‌اند.می‌توان آن‌ها را توسعه داد.منتشر کرد.روی Roadmap گذاشت.اما سؤال خوب، چنین ویژگی‌ای ندارد.هیچ‌کس برای یک سؤال عالی جشن انتشار نمی‌گیرد.در حالی که کیفیت یک محصول، بیشتر از کیفیت پاسخ‌هایش، به کیفیت سؤال‌هایی بستگی دارد که تیمش می‌پرسد.یک سؤال که هر Product Manager باید از خودش بپرسدوقتی کاربران از چیزی ناراضی هستند، معمولاً اولین واکنش این است:«چه چیزی باید اضافه کنیم؟»اما شاید سؤال بهتر این باشد:اگر اجازه نداشتیم هیچ فیچر جدیدی بسازیم، باز هم می‌توانستیم این مشکل را حل کنیم؟این سؤال، زاویه دید را عوض می‌کند.شاید مسئله، نبود قابلیت نباشد.شاید مسئله، ترتیب نمایش اطلاعات باشد.شاید پیام‌های سیستم مبهم باشند.شاید کاربر نمی‌داند قدم بعدی چیست.شاید محصول بیش از حد از کاربر تصمیم می‌خواهد.همه این‌ها مشکل محصول‌اند، بدون اینکه به یک فیچر جدید نیاز داشته باشند.فیچر، ارزان‌ترین بخش محصول است.ساختن یک قابلیت، معمولاً ساده‌تر از تصمیم گرفتن درباره ساختن آن است.چیزی که هزینه واقعی ایجاد می‌کند، کد نیست.پیامد تصمیم است.هر فیچر جدید یعنی:یک مسیر جدید برای تست.یک سناریوی جدید برای پشتیبانی.یک تصمیم جدید برای کاربر.یک پیچیدگی جدید برای تیم.به همین دلیل، بلوغ یک تیم محصول را نباید از تعداد قابلیت‌هایی که منتشر می‌کند سنجید.بلکه باید از تعداد قابلیت‌هایی سنجید که آگاهانه تصمیم گرفته هرگز نسازد.محصول، هنر کم کردن است.سال‌ها تصور می‌کردیم نوآوری یعنی اضافه کردن.امروز بیشتر باور دارم که نوآوری، در بسیاری از مواقع، یعنی حذف کردن.حذف یک کلیک.حذف یک تصمیم.حذف یک ابهام.حذف یک فرض اشتباه.حذف یک فیچر که هیچ‌وقت نباید ساخته می‌شد.به همین دلیل، شاید مهم‌ترین سؤال هر جلسه Product Review این نباشد که:«بعدی چیست؟»بلکه این باشد:«اگر از امروز مجبور شویم با نصف امکانات فعلی محصول کار کنیم، کدام بخش را حفظ می‌کنیم و چرا؟»پاسخ این سؤال، معمولاً هسته واقعی ارزش محصول را نشان می‌دهد.پایانبه نظرم، تفاوت بین تیم‌های متوسط و تیم‌های بزرگ، در کیفیت کدنویسی یا حتی کیفیت طراحی نیست.تفاوت، در کیفیت تصمیم‌هاست.محصول خوب، محصولی نیست که بیشترین قابلیت را داشته باشد.محصول خوب، محصولی است که بیشترین تعداد تصمیم درست را پشت سر هم گرفته باشد.و شاید مهم‌ترین مهارت یک Product Manager هم همین باشد:نه ساختن فیچرهای بیشتر...بلکه ساختن سیستمی که تصمیم‌های بهتری بگیرد.بهزاد عربگریبهزاد عربگریSun, 05 Jul 2026 17:14:48 +0330https://virgool.ir/@m_83662544/paat-product-as-a-trip-etdh9xfyacehشما تصور کنید که می‌خواهید کمی ریلکس کنید.در این راستا تصمیم می‌گیرید به یک سفر بروید.مرحله بعد: باید تصمیم بگیرید که کجا می‌خواهید بروید.انتخاب در راستای هدف: بنابراین هدف سفر می‌شود یک نقطه جغرافیایی (چون من خودم شیرازیم، پس شیراز). بنابراین انتخاب می‌کنید که از تهران به سمت شیراز سفر کنید.استراتژی:از چه طریقی می‌خواهید به شیراز برسید؟گزینه ۱: پروازگزینه ۲: قطارگزینه ۳: ماشینبررسی و انتخاب راه‌حل‌ها:قابلیت اجرایی (Viable): اگر با ماشین بروم، ۲ روز از مرخصی‌ام در راه می‌سوزد - آیا می‌خواهم در اصفهان بمانم یا نه - ...صرفه اقتصادی (Valuable): از نظر اقتصادی کدام گزینه به‌صرفه‌تر است و پول کافی دارم؟ - ...قابلیت انجام (Feasible): هوا خوب است که با پرواز برویم - شهر مبدأ یا مقصد فرودگاه دارد؟ - شهر مبدأ یا مقصد ایستگاه قطار دارد؟ - ماشین دارم؟ - ...قابلیت استفاده (Usable): اصلاً من بهزاد با قطار حال نمی‌کنم و هیچ‌وقت سوارش نمی‌شوم - من با رانندگی حال می‌کنم؟ - ...انتخاب گزینه: خودروی شخصیتجربه (Experiment):نقشه راه: وارد خودرو می‌شویم و از یک راهنمای سفر استفاده می‌کنیم و مقصد را وارد GPS می‌کنیم. مسیرهای مختلف را بررسی می‌کنیم تا نزدیک‌ترین یا زیباترین یا مطلوب‌ترین مسیر را انتخاب کنیم. ممکن است برایمان مهم باشد که سریع‌ترین زمان ممکن به شیراز برسیم. اینجا چندین عامل را باید بررسی کنیم که کدام مسیر سریع‌تر است. ممکن است برایمان مهم باشد که از زیبایی جاده نیز لذت ببریم. اینجا چندین عامل را باید بررسی کنیم که کدام مسیر را دوست داریم ببینیم. ممکن است برایمان مهم باشد که شب اول حتماً در اصفهان بمانیم. اینجا چندین عامل را باید بررسی کنیم که ابتدا به اصفهان برویم و بعد به شیراز.همواره باید حواسمان به GPS باشد که به ما کمک می‌کند ببینیم که آیا در مسیر درست هستیم یا نه؟ و در صورت نیاز راه درست را دنبال کنیم یا نه...مرحله بعد: در حالی‌که به سمت مقصد خود در حرکتیم، ماشین ما یک‌سری داشبوردهایی دارد که شاخص‌های دیگری را نیز به ما نشان می‌دهد و مثلاً به ما می‌گوید که چقدر بنزین داریم و دمای موتور ماشین چقدر است و... . مادامی‌که عقربه‌های داشبورد در محدوده مشخص قرار دارند، ما به آن‌ها اهمیت نمی‌دهیم و چیزی که از همه مهم‌تر است برایمان، پایبندی به نقشه راه است. اما اگر داشبورد ما نشان دهد که سوختمان رو به پایان است، در اینجا باید مسیرمان را سریع تغییر دهیم و دوباره آن را تنظیم کنیم و حتماً در پمپ بنزین توقف کنیم و بنزین بزنیم.این مقایسه روشی عالی است برای فهمیدن تفاوت بین استراتژی، OKR و مانیتور کردن KPIها:استراتژی شما فرآیند تصمیم‌گیری درباره مقصد و نقشه راه است که به ما کمک می‌کند تصمیم بگیریم کجا و چگونه می‌خواهیم برویم. فریم‌ورک OKR جی‌پی‌اس ماست. سیستم راهیابی خودروی شما که به شما کمک می‌کند ببینید که آیا در مسیر درست قرار دارید و مسیر را در صورت لزوم اصلاح کنید. مانیتور کردن KPIها در واقع عقربه‌های صفحه داشبورد خودروی شما هستند که آن‌ها به شما می‌گویند که آیا همه چیزهای دیگر رو به راه است یا نه.بهزاد عربگریبهزاد عربگریFri, 21 Jun 2024 18:25:46 +0330https://virgool.ir/@m_83662544/value-and-bcg-eeufth9y20yaمن به کررات گفتم مهمترین بخش یه پروداکت value ایی هست که اون پروداکت ایجاد میکنه .حالا یکی از ماتریس هایی که همیشه میشه باهاش متریک کرد اون ارزش رو ٬ یکیش ماتریس BCG هست.در موردش بخوام بگم ؛ماتریس BCG توسط گروه مشاوران بوستون ارائه شد و به همین دلیل به نام ماتریس بوستون هم شناخته می‌شه.این ماتریس، از نموداری ساخته شده که محور X آن به نام "سهم نسبی از بازار" و محور Y آن با عنوان "سرعت رشد بازار" شناخته می‌شود.سهم نسبی از بازار از تقسیم میزان سهم ما از بازار بر میزان سهم بزرگ‌ترین رقیب ما از بازار حاصل می‌شود.مولفه دیگر، سرعت رشد بازار است.سرعت رشد بازار به طیفی از بازارهای ضعیف تا قوی تقسیم می‌شود.و به صورت کلی بخوایم دو محور رو بررسی کنیم ٬ سوال هایی واسمون باید شکل بگیره به این شکل که:رشد بازار: آیا بازاری که در آن محصول فروخته می‌شه، به‌سرعت رشد می‌کنه؟ به‌آرامی رشد می‌کنه؟ یا اصلاً رشد نمی‌کنه؟سهم بازار: سهم بازار محصول نسبت به بزرگترین رقیب در بازار چه وضیعتی داره؟بر اساس همین دو مولفه، چهار قسمت در این ماتریس شکل می‌گیره که نام‌گذاری عجیبی هم دارن؛.علامت سوال ها· ستاره ها· گاو های شیرده· سگ هاعلامت سوال ها ؛محصولاتی هستن که سهم بازار پایینی دارن ولی در صنعتی قرارگرفته‌ اند که نرخ رشدشون بالاست؛ اما چون سرعت رشد بازار مشخص نیست برای تصمیم‌گیری در مورد کار با این محصولات ، تحقیقات بیشتری لازمه که انجام بشه.سهم بازار این محصولات در حال حاضر پایینه ؛ اما با توجه به رشد بالای بازار، با استراتژی‌های مناسب و سرمایه‌گذاری، این محصولات می‌توانند تبدیل یه یک گاو شیرده یا حتی ستاره بشن. اما به همان نسبت احتمال دارد که با یک برنامه‌ریزی اشتباه سقوط کنند و سرمایه شما را به باد دهند. بنابراین آینده مشخصی ندارند.پس ما اینجا سوال میپرسیم که پروداکتمون میتونه خفن بشه و ارزش جدیدی رو ایجاد کنه یا نه؟ستاره ها ؛ با توجه به اینکه سهم بازار بالایی دارن و رشد بازارشون هم خیلی بالاست تعجبی نداره که صاحبان مشاغل عاشق ستاره‌ها باشن؛ محصولاتی که در این ربع قرار میگیرن، ارزش بالایی دارن چراکه سرمایه‌گذاری روی این محصولات به خاطر رشد بالای بازار و محبوبیتی که دارنن همچنان سود آینده رو تضمین می‌کنن.گاو های شیرده؛ این محصولات چون سهم بازار بالایی دارن سود و درآمد بسیار خوبی را تولید می‌کنن ولی توی بازاری قرار گرفتن که رشد کمی داره. دقت داشته باشید که به دلیل سهم بالای بازارِ این نوع محصولات، اگر فروش آنها سودآور باشه میتونن فعالیت‌های دیگر شرکت را از نظر مالی تامین کنند.سگ ها؛سگ‌ها محصولاتی هستند که سهم بازار پایینی نسبت به رقبا دارن و رشد بازارشون هم بسیار کم و شاید گاهاً صفر باشه. این محصولات معمولاً سودآور نیستند و همان سهم بازارشان را هم به‌سختی حفظ می‌کنن. واضح است که محصولاتِ با سود کم و حتی زیان، در این ربع قرار می‌گیرن. اگر سگ‌ها سودآور باشن می‌تونیم روی سرمایه‌گذاری برای افزایش سهم بازارشون فکر کنیم وگرنه انحلال فروش آن‌ها بهترین تصمیم ممکن خواهد بود.با توجه به صحبت های بالا پس ما مکررا باید پروداکتمون رو بررسی کنیم و بعضی وقت ها با اضافه کردن یه فیچر که رنج جدید مشتریمون رو برطرف میکنه و ارزش جدیدی رو خلق میکنه ٬پروداکتمون رو از ربع سگ ها ببریم تو ستاره ها یا گاو های شیرده.پ.ن: نمودار BCG میتونه خیلی جاها مکمل PLC باشه واسه پروداکت#bcg - Boston Consulting Group #plc -Product Life Ciycleبهزاد عربگریبهزاد عربگریFri, 22 Jul 2022 17:21:03 +0430https://virgool.ir/@m_83662544/فرق-مدیریت-پروژه-ها-به-روش-های-سنتی-با-agile-product-management-به-شیوه-مدرن-تو-چیه-opuyfhutwgybمیخوام این موضوع رو با یه مثال که خودم خیلی ملموس تجربش کردم و تقریبا به تمام کسایی که میخوان وارد این فیلد بشن باهاشون به اشتراکش میزارم توضیحش بدم.من چندین سال بواسطه رشته اول دانشگاهم ٬ مدیر پروژه ٬ # پروژه های راه سازی بودم.سال ۹۳ اینا بود ما یه دیوار سنگی با سنگ لاشه به طول تقریبا ۲۱۰ متر و ارتفاع ۳ متر ساخته بودیم. ناظر بعد از ۳ ماه اومد به پروژه سر بزنه ...و اتفاقی که نباید افتاد ...ما دیوار رو ۱ متر به اشتباه جلوتر ساخته بودیم. بعد کلی جر و بحث با ناظر متوجه شدیم که آره ؛ درست میگفت ما اشتبااااااه کرده بودیم۳ ماه هزینه نیرو انسانی ٬ مصالح ٬ زمان و انرژی کاملا به هدر رفته بود پیمانکار اون پروژه کلی ضرر مالی کردنیرو ها بازخواست شدنذینفع اون پروژه تایم تحویل پروژه اش بجای ۳ ماه شد ۷ ماهولی ولی اگه بر اساس مدیریت بر اساس اجایل بود؛ قطعا ما هیچ کدوم از این مشکلات رو نداشتیم اون تایم و اون همه هدر رفت نداشتیم ....بهزاد عربگریبهزاد عربگریMon, 20 Jun 2022 22:01:11 +0430https://virgool.ir/@m_83662544/value-proposition-apcl9ycouewp بنظر شما مهم ترین خونه یه بیزینس مدل کدوم بخشش هست؟ عکس از کتاب خلق مدل کسب و کار اگه از من بپرسن میگم Value Proposition .حالا چرا ؟ چون ما تا ارزشی رو خلق نکنیم نمیتونیم پولی بابتش دریافت کنیمچون ما تا وقتی pain های Persona رو ندونیم نمیتونیم بابتش سگمنتی رو هدف قرار بدیم .چون تا وقتی ما ندونیم چه Gain رو به مشتری باید بدیم ٬ key resource ها برامون اهمیتی ندارن.و در کل بنظرم ما تا وقتی تو یه بازار میتونیم بمونیم و نفس بکشیم که خلق ارزش کنیم ؛ روزی که Value خوبی نداشته باشیم پروداکتمون وارد قسمت افول ( چرخه عمر محصول ) PLC خودش میشه.PLCبهزاد عربگریبهزاد عربگریFri, 17 Jun 2022 22:22:24 +0430