جزئیاتی که جلوی جزئیات را می‌گیرند؛ چرا مدیر محصول نباید از همه جزئیات فاصله بگیرد؟

یکی از رایج‌ترین توصیه‌ها به مدیران محصول این است:

«کمتر درگیر جزئیات شو و بیشتر استراتژیک فکر کن.»

در نگاه اول، توصیه کاملاً منطقی به نظر می‌رسد.

روز مدیر محصول پر شده از:

تیکت‌ها.

ابهام‌های تیم فنی.

پیگیری وابستگی‌ها.

تغییر وضعیت‌ها.

جلسات.

سؤال‌های کوچک.

تصمیم‌هایی که «همین الان» باید گرفته شوند.

در این شرایط طبیعی است که بگوییم مشکل روشن است:

مدیر محصول بیش از حد در جزئیات غرق شده و زمانی برای استراتژی ندارد.

اما یک مشکل وجود دارد.

گاهی دقیقاً کمبود نوع دیگری از جزئیات است که این حجم از کارهای روزمره را تولید می‌کند.

تعریف مبهم یک قابلیت امروز، فردا تبدیل به چند سؤال می‌شود.

یک تصمیم نگرفته‌شده در سطح محصول، توسط چند تیم به شکل‌های مختلف تفسیر می‌شود.

هدف نامشخص، چند هفته بعد خودش را به شکل تغییر مداوم اولویت‌ها نشان می‌دهد.

و چیزی که ابتدا «فقط کمی ابهام» بود، به انبوهی از تیکت، هماهنگی، بازکاری و جلسه تبدیل می‌شود.

بنابراین شاید مدیر محصول به این دلیل در جزئیات غرق نشده که بیش از حد به جزئیات توجه کرده است.

شاید به این دلیل غرق شده که در زمان درست به جزئیات درست توجه نکرده است.

مقاله اصلی این تناقض ظاهری را نقطه شروع خود قرار می‌دهد: از یک طرف مدیر محصول باید از جزئیات عملیاتی فاصله بگیرد تا بتواند استراتژیک فکر کند؛ از طرف دیگر، بی‌توجهی به برخی جزئیات در سطح بالا خودش همان سیلی را ایجاد می‌کند که بعداً مدیر محصول را غرق می‌کند.

کل مسئله در این است که ما دو نوع کاملاً متفاوت از کار را با یک کلمه نام‌گذاری کرده‌ایم:

Detail.

مشکل از خود کلمه «جزئیات» شروع می‌شود

وقتی می‌گوییم کاری «خیلی جزئی» است، معمولاً دو مفهوم را هم‌زمان در ذهن داریم.

اول:

کار در سطح پایین و عملیاتی قرار دارد.

مثلاً:

• پاسخ دادن به یک سؤال کوچک تیم فنی؛
• تعیین وضعیت یک تیکت؛
• پیگیری یک باگ؛
• هماهنگی یک Dependency.

اما «جزئی بودن» می‌تواند معنای دیگری هم داشته باشد:

دقت بالا.

ممکن است روی یک مسئله استراتژیک کار کنیم و در عین حال با دقت بسیار زیاد به جزئیات آن فکر کنیم.

مثلاً:

دقیقاً کدام کاربر را هدف گرفته‌ایم؟

چه مسئله‌ای را حل می‌کنیم؟

چه چیزی عمداً خارج از Scope است؟

اگر دو نیاز با هم تعارض داشته باشند، کدام را ترجیح می‌دهیم؟

تعریف دقیق موفقیت چیست؟

در چه شرایطی می‌گوییم این قابلیت آماده انتشار است؟

این‌ها سؤال‌های سطح بالا هستند.

اما پاسخ دادن به آن‌ها نیازمند جزئیات است.

مقاله اصلی برای توضیح این تفاوت از دو مفهوم استفاده می‌کند:

Altitude — ارتفاع

و

Grain — دانه‌بندی یا میزان ریزشدگی توجه

ارتفاع می‌گوید مسئله در چه سطحی قرار دارد.

دانه‌بندی می‌گوید با چه میزان دقت به آن نگاه می‌کنیم.

این دو مستقل از یکدیگرند.

چهار حالت مختلف کار

اگر «سطح مسئله» و «میزان جزئیات» را از هم جدا کنیم، چهار حالت خواهیم داشت.

سطح پایین + جزئیات زیاد

مثلاً مدیر محصول در حال بررسی دقیق تک‌تک تیکت‌های یک Sprint است.

کار دقیق است، اما عملیاتی.

سطح پایین + جزئیات کم

کاری اجرایی انجام می‌شود، اما بدون دقت کافی.

مثلاً فقط تیکت‌ها را جابه‌جا می‌کنیم بدون اینکه بفهمیم واقعاً چه اتفاقی افتاده است.

سطح بالا + جزئیات کم

چیزی که معمولاً ظاهری بسیار استراتژیک دارد:

Vision.

North Star.

Roadmap.

اهداف سالانه.

اسلایدهای جهت‌گیری.

اما زیر آن‌ها تعریف دقیقی وجود ندارد.

سطح بالا + جزئیات زیاد

این همان حالتی است که اغلب فراموش می‌کنیم.

استراتژی با دقت بالا.

یعنی مدیر محصول در سطح جهت‌گیری کار می‌کند، اما جزئیات واقعی را هم می‌فهمد:

• رفتار کاربر؛
• محدودیت فنی؛
• Trade-offها؛
• Edge Caseها؛
• ترتیب اجرا؛
• وابستگی‌ها؛
• و پیامد هر تصمیم.

این دیگر Micro-management نیست.

این استراتژی‌ای است که در تماس با واقعیت فرو نمی‌ریزد.

استراتژی واقعی بدون جزئیات ساخته نمی‌شود

گاهی استراتژی را با «فاصله گرفتن از جزئیات» یکی می‌گیریم.

اما استراتژی خوب معمولاً از مجموعه بزرگی از جزئیات ساخته شده است.

فرض کنید تصمیم گرفته‌ایم:

«در سال آینده روی SMEها تمرکز می‌کنیم.»

این جمله ممکن است استراتژیک به نظر برسد.

اما هنوز تقریباً هیچ تصمیمی نگرفته‌ایم.

SME یعنی چه؟

شرکت ۵نفره؟

۵۰نفره؟

۵۰۰نفره؟

کدام صنعت؟

خریدار چه کسی است؟

کاربر چه کسی است؟

مسئله اصلی چیست؟

چه چیزی را برای این بازار نمی‌سازیم؟

چه قابلیت‌هایی برای ورود ضروری‌اند؟

چه چیزی باعث می‌شود کاربر از راه‌حل فعلی خود مهاجرت کند؟

تا زمانی که این سؤال‌ها پاسخ داده نشده‌اند، ما هنوز یک جهت کلی داریم، نه استراتژی قابل‌اجرا.

همین جزئیات هستند که جهت را تبدیل به تصمیم می‌کنند.

دو نوع جزئیات را از هم جدا کنیم

مقاله برای حل مسئله، دو نام کاربردی پیشنهاد می‌کند.

۱. جزئیات عملیاتی (Operational Detail)

این همان چیزی است که معمولاً وقتی می‌گوییم «مدیر محصول در جزئیات غرق شده» منظورمان است.

مثلاً:

• این تیکت باید در کدام Sprint باشد؟
• Backend این Endpoint را چه زمانی تحویل می‌دهد؟
• متن این Tooltip چیست؟
• چرا این Bug هنوز باز است؟
• فلان تیم پاسخ داده یا نه؟
• وضعیت Release چیست؟

این کارها نزدیک به اجرای روزمره‌اند.

قابل مشاهده‌اند.

فوری‌اند.

و معمولاً تعدادشان زیاد است.

۲. جزئیات تعریفی (Definitional Detail)

این نوع بسیار کمتر دیده می‌شود.

اما اثرش بزرگ‌تر است.

مثلاً:

• دقیقاً چه چیزی می‌سازیم؟
• برای چه کسی؟
• چه چیزی خارج از محدوده است؟
• «Done» یعنی چه؟
• در این Trade-off چه چیزی را قربانی می‌کنیم؟
• اگر دو سناریو با هم تعارض داشتند، کدام مقدم است؟
• موفقیت را با چه معیاری می‌سنجیم؟

این کار هم استراتژیک است و هم جزئی.

مقاله همین نوع دوم را «High-altitude, fine-grained work» می‌نامد: کاری در ارتفاع بالا اما با دانه‌بندی بسیار دقیق.

و مشکل اصلی اینجاست:

این نوع کار تقریباً نامرئی است.

چرا بهترین نوع کار محصول دیده نمی‌شود؟

فرض کنید مدیر محصول پیش از شروع توسعه، چند ساعت روی تعریف دقیق یک Edge Case وقت بگذارد.

تیم همان تعریف را اجرا می‌کند.

هیچ اختلافی رخ نمی‌دهد.

هیچ Bug مفهومی ایجاد نمی‌شود.

هیچ جلسه اضطراری‌ای برگزار نمی‌شود.

و پروژه آرام جلو می‌رود.

حالا سؤال:

چگونه ثابت می‌کنیم آن چند ساعت واقعاً ارزشمند بوده است؟

تقریباً نمی‌توانیم.

چون خروجی آن کار چیزی بوده که اتفاق نیفتاده است.

بازکاری اتفاق نیفتاده.

اختلاف بین تیم‌ها اتفاق نیفتاده.

پیاده‌سازی اشتباه رخ نداده.

جلسه اضطراری برگزار نشده.

مقاله سه دلیل برای نامرئی بودن این کار مطرح می‌کند.

نمی‌توان آن را به‌راحتی اندازه گرفت

می‌توان تعداد Bugها را شمرد.

اما Bugهایی که هیچ‌وقت ایجاد نشدند را نمی‌توان شمرد.

نمی‌توان به‌سادگی اثر را به آن نسبت داد

وقتی پروژه روان پیش می‌رود، معمولاً موفقیت به تیم اجرایی، برنامه‌ریزی خوب یا حتی شانس نسبت داده می‌شود.

تصمیم دقیقی که چند هفته قبل جلوی مشکل را گرفته بود، رد قابل‌مشاهده‌ای باقی نگذاشته است.

نمی‌توان Counterfactual را ثابت کرد

مدیر محصول نمی‌تواند اثبات کند:

«اگر من این موضوع را دقیق تعریف نکرده بودم، سه هفته بعد پروژه به مشکل می‌خورد.»

چون آن آینده هرگز اتفاق نیفتاده است.

مقاله این مسئله را با جمله‌ای بسیار دقیق بیان می‌کند:

می‌توان آتش‌هایی را که شروع شده‌اند شمرد؛ اما آتش‌هایی را که هرگز شروع نشدند نه.

این همان چیزی است که کار Definitional را آسیب‌پذیر می‌کند.

نسخه کلاسیک درمان: «جزئیات را کم کن»

حالا فرض کنیم مدیر محصول در کارهای روزمره غرق شده است.

مدیرش می‌گوید:

«باید از جزئیات فاصله بگیری.»

راه‌حل‌ها شروع می‌شوند:

تیکت‌ها را Delegate کن.

از Standup فاصله بگیر.

وضعیت‌ها را خودت دنبال نکن.

بین خودت و تیم فنی یک لایه ایجاد کن.

Inbox را خلوت کن.

جلسات عملیاتی را کم کن.

همه این‌ها می‌توانند کاملاً درست باشند.

مشکل وقتی شروع می‌شود که دستور اصلی فقط این باشد:

«Detail را کم کن.»

چون همان کلمه برای هر دو نوع کار استفاده می‌شود.

در نتیجه ممکن است همراه با Operational Detail، همان Definitional Detail ارزشمند هم حذف شود.

یعنی مدیر محصول از یک طرف از پیگیری تیکت‌ها خلاص می‌شود، اما از طرف دیگر دیگر وقت یا اجازه کافی برای دقیق کردن تعریف محصول هم ندارد.

و همین تصمیم بذر آشفتگی بعدی را می‌کارد.

وقتی جزئیات تعریفی حذف می‌شوند، سه اتفاق می‌افتد

مقاله سه نتیجه اصلی را از هم جدا می‌کند:

Rework

Waste

Priority Churn

هر سه شبیه آشفتگی روزمره دیده می‌شوند، اما سازوکارشان متفاوت است.

۱. بازکاری؛ یک تصمیم چند بار گرفته می‌شود

فرض کنید در طراحی یک قابلیت مشخص نکرده‌ایم:

«کاربری که هنوز احراز هویت کامل نشده، آیا می‌تواند وارد این مرحله شود یا نه؟»

تعریف روشنی وجود ندارد.

Frontend با یک فرض جلو می‌رود.

Backend با فرض دیگری.

QA حالت سومی را منطقی می‌داند.

وقتی اجزا به هم متصل می‌شوند، اختلاف ظاهر می‌شود.

حالا باید:

جلسه برگزار شود.

تصمیم گرفته شود.

کد تغییر کند.

UI اصلاح شود.

Test Caseها بازنویسی شوند.

این همان Rework است.

مقاله تعریف بسیار خوبی ارائه می‌دهد:

بازکاری هزینه تصمیمی است که به‌جای یک بار، چند بار گرفته شده است.

یعنی مشکل فقط اجرای بد نیست.

تصمیمی که باید بالا و یک‌بار گرفته می‌شد، پایین و چندبار گرفته شده است.

۲. اتلاف؛ کار را درست انجام می‌دهیم، اما کار اشتباه را

Waste با Rework فرق دارد.

در Rework چیزی ساخته شده و بعد باید اصلاح شود.

اما در Waste ممکن است تیم محصول و فنی فوق‌العاده کار کرده باشند.

Feature بدون Bug تحویل شده.

Performance عالی است.

UI زیباست.

اما کسی قبل از شروع نپرسیده:

«آیا اصلاً باید این را می‌ساختیم؟»

در نتیجه تیم چیزی را کاملاً درست ساخته که اساساً مسئله درستی را حل نمی‌کند.

مقاله این تفاوت را دقیق بیان می‌کند:

بازکاری یعنی یک چیز را دوبار ساختن؛ اتلاف یعنی یک‌بار، چیز اشتباه را ساختن.

این نوع شکست اغلب بسیار گران‌تر از Bug است.

چون تمام فرایند Delivery می‌تواند موفق باشد و در عین حال محصول شکست خورده باشد.

۳. نوسان اولویت‌ها؛ وقتی هیچ نقطه ثابتی برای تصمیم نداریم

یکی دیگر از نشانه‌های رایج سازمان‌های محصول:

هر هفته اولویت‌ها عوض می‌شوند.

یک مدیر وارد جلسه می‌شود؛ یک Feature اول می‌شود.

یک مشتری شکایت می‌کند؛ Roadmap عوض می‌شود.

رقیب قابلیتی منتشر می‌کند؛ همه‌چیز کنار گذاشته می‌شود.

حادثه‌ای اتفاق می‌افتد؛ پروژه جدیدی شروع می‌شود.

معمولاً این اتفاق را به ضعف Prioritization نسبت می‌دهیم.

اما مقاله استدلال می‌کند مشکل ممکن است در سطحی قبل‌تر باشد.

برای اولویت‌بندی باید چیزی وجود داشته باشد که موارد را نسبت به آن بسنجیم.

اگر هدف ثابت نباشد، هیچ Ranking پایداری هم ممکن نیست.

وقتی هدف تعریف نشده، اولویت طبیعی سازمان تبدیل می‌شود به:

آخرین چیزی که فشار بیشتری ایجاد کرده است.

بلندترین صدای Stakeholder.

آخرین جلسه.

آخرین Incident.

مقاله می‌گوید اولویت‌هایی که مدام تغییر می‌کنند لزوماً نتیجه ضعف در Ranking نیستند؛ ممکن است نتیجه نبودن یک «نقطه ثابت» برای Ranking باشند.

چرخه‌ای که خودش را تکرار می‌کند

حالا می‌توانیم حلقه کامل را ببینیم.

مرحله ۱

مدیر محصول در جزئیات عملیاتی غرق می‌شود.

مرحله ۲

سازمان می‌گوید:

«باید از Detail فاصله بگیری.»

مرحله ۳

همراه با کار عملیاتی، بخشی از کار تعریفی هم حذف می‌شود.

مرحله ۴

ابهام‌های بالادستی باقی می‌مانند.

مرحله ۵

تیم‌ها تصمیم‌ها را محلی و متفاوت می‌گیرند.

مرحله ۶

Rework، Waste و Priority Churn افزایش پیدا می‌کند.

مرحله ۷

همه این مشکلات دوباره به شکل Operational Detail ظاهر می‌شوند:

• تیکت بیشتر؛
• سؤال بیشتر؛
• جلسه بیشتر؛
• Clarification بیشتر؛
• هماهنگی بیشتر.

مرحله ۸

مدیر محصول دوباره در جزئیات غرق می‌شود.

و سازمان دوباره می‌گوید:

«باید از جزئیات فاصله بگیری.»

همان درمان دوباره تجویز می‌شود.

و همان درمان بخشی از علت بیماری می‌شود.

این ادعای مرکزی مقاله است: راه‌حل استاندارد فقط ممکن است شکست نخورد؛ گاهی خودش شرایطی را بازتولید می‌کند که قرار بود از بین ببرد.

اما گاهی واقعاً باید از جزئیات فاصله گرفت

اینجا مهم است که مقاله تبدیل به دفاع بی‌قیدوشرط از «درگیر بودن مدیر محصول در همه‌چیز» نشود.

چون بعضی مدیران محصول واقعاً بیش از حد درگیرند.

همه تیکت‌ها را خودشان کنترل می‌کنند.

در تمام جلسات حضور دارند.

تصمیم‌هایی را نگه می‌دارند که تیم به‌راحتی می‌تواند بگیرد.

گزارش‌هایی تولید می‌کنند که هیچ‌کس نمی‌خواند.

Statusهایی را دنبال می‌کنند که ابزارها می‌توانند نشان دهند.

از ترس از دست دادن کنترل، اجازه نمی‌دهند تیم مستقل شود.

این کارها ارزش Definitional ندارند.

فقط Noise هستند.

مقاله صریحاً این حالت را می‌پذیرد و می‌گوید حذف این نوع Operational Detail نه‌تنها مشکل ندارد، بلکه فوراً مفید است.

بنابراین پیام مقاله این نیست:

«مدیر محصول باید در جزئیات بماند.»

پیام دقیق‌تر این است:

«قبل از حذف جزئیات، بفهم کدام جزئیات را حذف می‌کنی.»

همه آشفتگی‌ها هم تقصیر تعریف ضعیف نیستند

فرض کنیم مدیر محصول همه‌چیز را عالی تعریف کرده است.

باز هم ممکن است آشفتگی رخ دهد.

رقیب محصول بزرگی منتشر می‌کند.

قانون جدیدی تصویب می‌شود.

مدیرعامل جهت شرکت را تغییر می‌دهد.

بودجه کاهش می‌یابد.

تیم Reorg می‌شود.

یک مشتری بزرگ قرارداد را لغو می‌کند.

این‌ها مسائل Exogenous یا بیرونی هستند.

هیچ مقدار Definitional Detail قبلی نمی‌توانسته آن‌ها را کاملاً حذف کند.

در چنین شرایطی محافظت کردن مدیر محصول از Noise واقعاً منطقی است.

مقاله این نکته را نیز می‌پذیرد: هر مدیر محصولی که در آشفتگی غرق شده، قربانی تصمیم‌های تعریف‌نشده خودش نیست. بخشی از آشفتگی واقعاً از بیرون وارد می‌شود.

حتی «جزئیات تعریفی» هم می‌تواند تبدیل به پناهگاه شود

این شاید مهم‌ترین ضد استدلال مقاله باشد.

فرض کنیم مدیر محصول می‌گوید:

«من تیکت‌ها را دنبال نمی‌کنم؛ دارم Discovery می‌کنم.»

اما Discovery شش ماه ادامه دارد.

Persona دوباره نوشته می‌شود.

Problem Statement دوباره اصلاح می‌شود.

Workshop دیگری برگزار می‌شود.

Research دیگری انجام می‌شود.

Scope بار دیگر بازتعریف می‌شود.

و هیچ‌چیز Ship نمی‌شود.

همه‌چیز در ظاهر شبیه کار دقیق محصول است.

اما ممکن است این دقت صرفاً شکل محترمانه‌ای از ترس از تصمیم گرفتن باشد.

مقاله این حالت را «Definitional avoidance» می‌داند:

اجتناب از Commitment که لباس Rigour پوشیده است.

این خطر حتی از Micro-management سخت‌تر قابل تشخیص است.

چون از بیرون بسیار حرفه‌ای به نظر می‌رسد.

تحقیق.

تحلیل.

Refinement.

Discovery.

Strategy.

همه کلمات درست‌اند.

اما در نهایت هیچ تصمیمی گرفته نمی‌شود.

پس مسئله «مقدار جزئیات» نیست؛ مسئله قضاوت است

در این نقطه روشن می‌شود که عبارت معروف:

«مقدار مناسبی از Detail لازم است.»

تقریباً هیچ کمکی نمی‌کند.

«مقدار مناسب» یعنی چه؟

برای چه کاری؟

در چه سطحی؟

در چه زمانی؟

مسئله اصلی Quantitative نیست.

کیفی است.

باید تشخیص دهیم:

• این Detail حیاتی است یا Noise؟
• این آشفتگی نتیجه ابهام داخلی است یا تغییر بیرونی؟
• این Discovery واقعاً Definition می‌سازد یا فقط تصمیم را عقب می‌اندازد؟
• این سؤال باید توسط PM پاسخ داده شود یا تیم خودش می‌تواند تصمیم بگیرد؟

مقاله می‌گوید دقیقاً همین Judgment است که نسخه ساده «Detail را کم کن» قادر به انجامش نیست.

شاید سؤال بهتر این باشد: این جزئیات چه کاری انجام می‌دهند؟

به‌جای پرسیدن:

«آیا این خیلی جزئی نیست؟»

سؤال بهتری وجود دارد:

«این جزئیات از چه تصمیمی محافظت می‌کنند؟»

مثلاً اگر مدیر محصول نیم ساعت روی متن دقیق Empty State بحث می‌کند، شاید Micro-management باشد.

اما اگر همان Empty State باعث می‌شود کاربر در یک مرحله مالی نداند پولش کجاست، آن تصمیم ممکن است کاملاً Load-bearing باشد.

اگر PM وارد بحث Database Schema شده، شاید بی‌دلیل در کار Engineering دخالت کرده است.

اما اگر انتخاب مدل داده تعیین می‌کند محصول در آینده اصلاً بتواند مدل کسب‌وکار موردنظر را پشتیبانی کند، شاید این موضوع یک Detail استراتژیک باشد.

خود «کوچک بودن موضوع» تعیین‌کننده نیست.

پیامد تصمیم تعیین‌کننده است.

Load-bearing Detail چیست؟

می‌توان از معماری استعاره گرفت.

در یک ساختمان، همه اجزا وزن یکسانی ندارند.

بعضی دیوارها صرفاً جداکننده‌اند.

برخی Load-bearing هستند.

برداشتن یکی تقریباً هیچ اتفاقی ایجاد نمی‌کند.

برداشتن دیگری ممکن است کل ساختمان را ضعیف کند.

جزئیات محصول هم همین‌طورند.

مثلاً این تصمیم:

«دکمه باید ۴۸ پیکسل باشد یا ۵۲؟»

ممکن است در بسیاری از موقعیت‌ها Load-bearing نباشد.

اما این تصمیم:

«آیا کاربر می‌تواند پول تخصیص‌یافته به یک هدف را برای هدف دیگری خرج کند؟»

ممکن است چهار بخش محصول، مدل مالی، طراحی UX و حتی Compliance را تعیین کند.

هر دو «Detail» هستند.

اما وزنشان یکسان نیست.

مشکل دیگری به نام «استراتژی با دانه‌بندی پایین»

وقتی سازمان مدیر محصول را از همه جزئیات دور می‌کند، معمولاً چیزی باقی می‌ماند که از بیرون بسیار استراتژیک دیده می‌شود.

Vision Deck.

OKR.

Roadmap.

North Star.

Strategic Pillars.

ولی هیچ لایه دقیقی زیر آن‌ها وجود ندارد.

مقاله این حالت را:

High altitude, coarse grain

می‌نامد.

ارتفاع بالا، دانه‌بندی پایین.

یعنی مدیر محصول در سطح بالا قرار گرفته اما دیگر واقعیت ریز محصول را در دست ندارد.

نتیجه چیزی است که شبیه استراتژی است، اما دوام استراتژی را ندارد.

در جلسه خوب به نظر می‌رسد.

اسلایدها تمیزند.

جهت مشخص به نظر می‌رسد.

اما اولین بار که این جهت با یک سناریوی واقعی کاربر، محدودیت فنی یا Trade-off اقتصادی برخورد می‌کند، مشخص می‌شود تعریف کافی وجود ندارد.

و دوباره سؤال‌ها شروع می‌شوند.

استراتژی‌ای که در تماس با واقعیت دوام نیاورد، استراتژی کامل نیست

فرض کنید Roadmap می‌گوید:

«تجربه پرداخت را کاملاً منعطف می‌کنیم.»

خوب است.

اما انعطاف دقیقاً یعنی چه؟

کاربر می‌تواند چند منبع مالی را ترکیب کند؟

اعتبار و موجودی نقدی هم‌زمان قابل استفاده‌اند؟

Refund چگونه توزیع می‌شود؟

اگر یکی از منابع منقضی شود چه؟

ترتیب مصرف منابع چیست؟

Merchant چه چیزی می‌بیند؟

Accounting چگونه ثبت می‌شود؟

تا زمانی که بخشی از این سؤال‌ها پاسخ نگرفته‌اند، «انعطاف در پرداخت» یک جهت است، نه یک مدل محصول.

Definitional Detail همان چیزی است که استراتژی را از اسلاید به سیستم تبدیل می‌کند.

یک Product Manager خوب باید کجا جزئی باشد؟

نه همه‌جا.

این شاید ساده‌ترین پاسخ باشد.

PM باید بیشترین Detail را جایی مصرف کند که تصمیم:

• برگشت‌پذیری پایینی دارد؛
• چند تیم را تحت تأثیر قرار می‌دهد؛
• معماری آینده را محدود می‌کند؛
• رفتار اصلی کاربر را تعیین می‌کند؛
• درآمد یا ریسک را تغییر می‌دهد؛
• و اگر مبهم بماند، چند نفر آن را متفاوت تفسیر خواهند کرد.

در مقابل، هر Detailی که:

• محلی است؛
• برگشت‌پذیر است؛
• پیامد کمی دارد؛
• و فرد نزدیک‌تر به کار بهتر می‌تواند تصمیم بگیرد،

احتمالاً باید Delegate شود.

این یعنی هدف خروج از Detail نیست.

هدف تخصیص هوشمند توجه است.

یک تست ساده برای تشخیص جزئیات مهم

می‌توان قبل از ورود به یک بحث جزئی از خود پرسید:

اگر من این تصمیم را نگیرم، چه کسی خواهد گرفت؟

اگر پاسخ «تیم خودش به‌راحتی می‌تواند تصمیم بگیرد» باشد، احتمالاً لازم نیست PM وارد شود.

اما اگر پاسخ این باشد:

«Frontend یک چیز برداشت می‌کند، Backend چیز دیگری و Business چیز سوم»،

احتمالاً Definitional Detail داریم.

اگر این تصمیم اشتباه باشد، هزینه اصلاح چقدر است؟

اگر با ده دقیقه تغییر قابل اصلاح است، شاید لازم نیست امروز بیش از حد روی آن وقت بگذاریم.

اگر اصلاحش دو ماه بعد به تغییر معماری نیاز دارد، ارزش فکر دقیق دارد.

آیا تصمیم فقط یک‌بار گرفته می‌شود یا همه بعداً دوباره آن را خواهند گرفت؟

هرچه احتمال تفسیر چندباره بیشتر باشد، Definition اولیه ارزشمندتر است.

سازمان چگونه این کار نامرئی را ببیند؟

یکی از مشکلات اصلی مقاله همین است:

Definitional Detail اثری بر جا نمی‌گذارد.

پس اگر بخواهیم از آن محافظت کنیم، باید کمی آن را قابل‌مشاهده کنیم.

نه با افزایش Documentation بی‌دلیل.

بلکه با ثبت تصمیم‌های مهم.

مثلاً:

Decision Log

چه تصمیمی گرفته شد؟

چرا؟

چه Trade-offی پذیرفته شد؟

Product Principles

وقتی دو گزینه با هم تعارض دارند، چه اصلی تعیین‌کننده است؟

Definition of Done

چه چیزی واقعاً «تمام‌شده» محسوب می‌شود؟

Non-goals

چه چیزی را عمداً حل نمی‌کنیم؟

Boundary Conditions

این راه‌حل تا کجا معتبر است و از کجا به بعد نیست؟

این Artifactها قرار نیست بوروکراسی ایجاد کنند.

نقششان این است که تصمیم مهم یک‌بار گرفته شود و بعد همه بتوانند به آن رجوع کنند.

شاید بهترین PM کسی نیست که کمترین جزئیات را می‌بیند

بلکه کسی است که می‌داند:

کدام جزئیات ارزش دیدن دارند.

مدیر محصول ضعیف ممکن است همه چیز را کنترل کند.

مدیر محصول دیگری ممکن است از ترس Micro-management تقریباً از همه‌چیز فاصله بگیرد.

اما مدیر محصول قوی‌تر میان این دو حرکت می‌کند.

در سطح بالا تصمیم می‌گیرد.

وقتی موضوع Load-bearing است، عمیق می‌شود.

وقتی موضوع محلی و برگشت‌پذیر است، Delegate می‌کند.

دوباره بالا می‌آید.

و توجهش را جایی مصرف می‌کند که بیشترین ابهام آینده را از بین می‌برد.

از «تیکت» به «ابهام»

شاید حتی بتوان تعریف بهتری از Operational Load ارائه کرد.

به‌جای اینکه بگوییم:

«چرا این‌همه تیکت داریم؟»

بپرسیم:

«چرا این‌همه سؤال تولید شده است؟»

هر Clarification یک نشانه است.

گاهی تیم واقعاً به اطلاعات جدید نیاز دارد.

اما اگر یک نوع سؤال بارها تکرار می‌شود، احتمالاً چیزی بالادست تعریف نشده است.

مثلاً اگر دائماً سؤال داریم:

«در این حالت کاربر چه می‌بیند؟»

شاید State Model محصول کامل نیست.

اگر دائماً سؤال داریم:

«این Feature مهم‌تر است یا آن یکی؟»

شاید Goal واضح نیست.

اگر دائماً سؤال داریم:

«این تیم مسئول است یا آن تیم؟»

شاید Boundary سیستم مشخص نشده است.

Operational Detail گاهی فقط علامت بیماری است.

مدیر محصول باید از «کار» فاصله بگیرد، نه از «واقعیت»

این تفاوت مهمی است.

PM لازم نیست هر کار را خودش انجام دهد.

اما نباید آن‌قدر از اجرا فاصله بگیرد که دیگر اثر تصمیم‌هایش را نبیند.

اگر مدیر محصول فقط Dashboard، Roadmap و Presentation ببیند و دیگر نداند کاربران کجا گیر می‌کنند، تیم فنی چه ابهام‌هایی دارد و چه تصمیم‌هایی دائماً دوباره گرفته می‌شوند، استراتژی‌اش به‌تدریج از واقعیت جدا می‌شود.

فاصله درست یعنی:

از اجرای مستقیم فاصله بگیر؛ از Feedback نه.

چه زمانی باید از Detail خارج شویم؟

سه نشانه ساده:

وقتی تصمیم برگشت‌پذیر است

لازم نیست PM ساعت‌ها روی چیزی بحث کند که فردا در چند دقیقه قابل اصلاح است.

وقتی فرد دیگری اطلاعات محلی بهتری دارد

Designer ممکن است درباره فاصله‌گذاری بهتر تصمیم بگیرد.

Engineer درباره Implementation داخلی.

Content Writer درباره یک عبارت.

وقتی تصمیم هیچ اثر زنجیره‌ای مهمی ندارد

هرچه Blast Radius کوچک‌تر باشد، نیاز به ورود PM کمتر است.

و برعکس:

هرچه اثر تصمیم بزرگ‌تر و چندبخشی‌تر باشد، Detail ارزشمندتر می‌شود.

جمع‌بندی؛ بعضی جزئیات باید حذف شوند، بعضی باید زودتر حل شوند

توصیه «مدیر محصول باید کمتر درگیر جزئیات شود» اشتباه نیست.

اما ناقص است.

بعضی جزئیات واقعاً باید حذف شوند:

• Status chasing؛
• Micro-management؛
• جلسات کم‌ارزش؛
• تصمیم‌های محلی؛
• پیگیری‌هایی که سیستم یا تیم می‌تواند انجام دهد.

اما نوع دیگری از Detail وجود دارد که اگر حذف شود، همان آشفتگی را چند هفته بعد دوباره تولید می‌کند:

• هدف دقیق؛
• Scope؛
• Trade-off؛
• Boundary؛
• Definition؛
• Non-goal؛
• و تصمیم‌هایی که باید قبل از برخورد تیم‌ها با ابهام گرفته شوند.

مقاله اصلی در پایان به همین نکته برمی‌گردد: دو شکایت ظاهراً متناقض — «PM بیش از حد در جزئیات است» و «PM به‌اندازه کافی به جزئیات توجه نکرده» — در واقع درباره دو نوع متفاوت Detail صحبت می‌کنند.

شاید به همین دلیل سؤال مناسب برای مدیر محصول این نباشد:

«آیا زیادی وارد Detail شده‌ام؟»

بلکه این باشد:

«این Detail چه چیزی را در آینده حذف می‌کند؟»

اگر پاسخ:

جلسه، بازکاری، ابهام، اختلاف، Waste یا تغییر بی‌دلیل اولویت‌هاست،

احتمالاً آن Detail مزاحم استراتژی نیست.

بخشی از خود استراتژی است.

و شاید بهترین نوع جزئیات همان‌هایی باشند که وقتی درست انجامشان می‌دهیم، دیگر هیچ‌کس متوجه وجودشان نمی‌شود؛ چون مسئله‌ای که قرار بود ایجاد شود، هیچ‌وقت ایجاد نشده است.