مدیریت محصول (Product Management) چیست؟
💡 این متن «بازنویسی آزاد» است: ایدهها و مفاهیم مطلب اصلی با نگارش کاملاً مستقل فارسی و مثالهای تازه بازگو شدهاند و ترجمهٔ کلمهبهکلمه نیست. بخشهای افزودهٔ مترجم در جعبهٔ منبع مشخص شدهاند. ترجمه و بازنویسی این متن با کمک هوش مصنوعی انجام شده است.
طراحی یک طرح را برای بازبینی میبرد. مدیر محصول میپرسد: «این مسئله اصلاً اولویت ماست؟» طراح جواب میدهد: «مسئله را تو تعریف کرده بودی.» هر دو کمی دلخور از جلسه بیرون میآیند.
این صحنه در بسیاری از تیمها تکرار میشود. دلیلش معمولاً بدخلقی نیست. دو نقشی که بیشترین کار مشترک را دارند، روشن نکردهاند مرز کارشان کجاست. این مقاله دربارهٔ مدیریت محصول است، ولی از نگاه طراحی که هر روز با مدیر محصول کار میکند.
مدیریت محصول چیست؟
مدیریت محصول (Product Management) به تعریف منبع، به کار بستن سه فهم با هم است: فهم نیاز کاربر، فهم هدفهای کسبوکار و فهم فناوری. نتیجه باید محصولی باشد که هم تجربهٔ روانی بدهد و هم هدف کسبوکار را برآورده کند. مدیر محصول نیاز کاربر و هدف شرکت را پیدا میکند و به زبان روشن درمیآورد. محصول باید به همین دو جواب بدهد.
ریشهٔ این نقش قدیمیتر از محصول دیجیتال است. این بخش را من اضافه میکنم. در سال ۱۹۳۱ نیل مکالروی، که آن زمان مدیر تبلیغات جوانی در شرکت پراکتر اند گمبل بود، یادداشتی داخلی نوشت. در آن یادداشت پیشنهاد کرد برای هر برند یک «مرد برند» باشد که مسئول کل موفقیت آن برند است، از فهمیدن مشتری تا فروش. این یادداشت را معمولاً نقطهٔ شروع مدیریت محصول میدانند. شرکتهای فناوری دههها بعد همین ایده را برای نرمافزار بازتعریف کردند.
کار مدیر محصول
منبع فهرستی از مسئولیتها میآورد. من آنها را در سه دسته گذاشتهام.
فهمیدن. پژوهش بازار و پژوهش کاربر. مدیر محصول باید بداند مشتری چه میخواهد و بازار به کدام سمت میرود. در تیمهای خوب، این پژوهش را با طراح و پژوهشگر مشترک انجام میدهد.
جهت دادن. تعریف چشمانداز و هدفهای محصول، ساختن راهبرد و نگهداری نقشهٔ راه، و اولویتبندی ویژگیها بر اساس هدف کسبوکار. این بخش همان چیزی است که بیشتر مردم از مدیر محصول انتظار دارند.
سنجیدن و تکرار. پیگیری سنجههای کلیدی عملکرد و اصلاح محصول بر اساس بازخورد. منبع چند سنجهٔ رایج را نام میبرد: رضایت کاربر، نرخ تکمیل کار، نرخ تبدیل و ماندگاری، نرخ ریزش، و زمان انجام کار. چند تا از اینها، مثل نرخ تکمیل کار و زمان انجام کار، سنجههای کاربردپذیریاند و طراح هم مستقیم به آنها نگاه میکند.
منبع پنج مرحله هم برای کار محصول میآورد: کشف، طراحی، آزمون، ساخت و سنجش. جالب اینکه در این ترتیب، آزمون پیش از ساخت آمده. یعنی ایده باید پیش از نوشتن کد با کاربر آزموده شود، و این دقیقاً جایی است که کار طراح و مدیر محصول در هم میرود.
منبع مهارتهای مدیر محصول را هم برمیشمارد: شناخت طراحی تجربه و رابط کاربری، تفکر راهبردی و درک کسبوکار، پژوهش کاربر و تحلیل داده، رهبری و ارتباط، حل مسئله و همدلی، مدیریت پروژه، و سواد فنی. منبع تأکید میکند که سواد فنی لزوماً به معنای برنامهنویسی نیست. کافی است بداند چه چیزی ساختنش سخت است و چرا.
اگر این فهرست را با مهارتهای یک طراح باتجربه مقایسه کنید، نیمی از آن مشترک است. پژوهش، همدلی، حل مسئله و ارتباط همان مهارتهاییاند که طراح هر روز به کار میبرد. چیزی که طراح معمولاً کم دارد، درک کسبوکار و تفکر راهبردی است: اینکه یک ویژگی چقدر درآمد میآورد، چقدر هزینه دارد، و در کنار بقیهٔ کارها چه اولویتی دارد. به همین دلیل مسیر رفتن از طراحی به مدیریت محصول یکی از مسیرهای رایج شغلی است.
تیم سهنفره و چهار خطر
این بخش افزودهٔ من است. منبع تفاوت مدیر محصول و طراح را با «چه و چرا» در برابر «چگونه» توضیح میدهد. این تمایز درست است، ولی کامل نیست. یک چارچوب کمک میکند تقسیم کار روشنتر شود.
مارتی کیگن، نویسندهٔ کتاب Inspired که منبع هم به آن ارجاع میدهد، میگوید هر محصول تازه با چهار خطر روبهروست. خطر ارزش: آیا مشتری آن را میخرد یا استفاده میکند؟ خطر کاربردپذیری: آیا کاربر میتواند با آن کار کند؟ خطر شدنی بودن: آیا تیم میتواند آن را بسازد؟ و خطر ماندنی بودن کسبوکار: آیا این محصول با قید و هدف شرکت جور است؟
به گفتهٔ کیگن، هر کدام از این خطرها صاحب اصلی دارد. نمودار بالای صفحه همین را نشان میدهد. مدیر محصول صاحب خطر ارزش و ماندنی بودن است. طراح صاحب کاربردپذیری است. مهندس ارشد صاحب شدنی بودن است. ولی کشف، یعنی کاری که این خطرها را پیش از ساخت کم میکند، کار هر سه با هم است.
ترزا تورس بعدها برای این گروه نام «سهتای محصول» را رایج کرد. پیشنهادش این است که این سه نفر هر هفته با هم با کاربر حرف بزنند و فرضهایشان را بیازمایند، نه اینکه یکی فرض را بسازد و به دیگری تحویل دهد. کشف پیوسته را جداگانه باز کردهایم.
مرز مسئله و راهحل
این بخش هم افزودهٔ من است، و برمیگردد به صحنهٔ ابتدای مقاله.
تمایز «چه و چرا» در برابر «چگونه» این تصور را میسازد که مرز میان دو نقش یک خط تیز است. در عمل، این مرز یک طیف است. در سر راست طیف، پرسش «چرا و برای چه کسی؟» است که بیشتر کار مدیر محصول است. در سر چپ، «با چه جزئیاتی؟» که بیشتر کار طراح است. ولی میانهٔ طیف، یعنی «چه چیزی» و «چطور» در سطح کلی، جای هر دو است.
بیشتر دلخوریها از همین میانه میآید. وقتی مدیر محصول مسئله را تعریف کند و بدون طراح بگوید «یک دکمه اینجا بگذار»، به فضای راهحل رفته. وقتی طراح بدون مدیر محصول تصمیم بگیرد این ویژگی اصلاً لازم نیست، به فضای مسئله رفته. هیچکدام خطا نیست، به شرط اینکه با هم انجام شود.
راه عملی سادهای برای این هست. مسئله را با هم بنویسید، در یک جملهٔ مشترک که هر دو امضایش کنید. بعد، هر وقت کسی خواست از مرز رد شود، به همان جمله برگردید. اگر مسئله عوض شده، جمله را با هم عوض کنید.
افسانهٔ مدیرعامل کوچک
این بخش هم افزودهٔ من است. جملهای معروف هست که مدیر محصول را «مدیرعامل محصول» مینامد. این تعبیر معمولاً به یادداشتی از بن هوروویتز در دههٔ ۱۹۹۰ برمیگردد و از آن زمان بارها تکرار شده.
بخشی از این تعبیر درست است. مدیر محصول، مثل مدیرعامل، مسئول نتیجهٔ کل است. ولی بخش مهمش گمراهکننده است. مدیرعامل اختیار دارد و مدیر محصول معمولاً ندارد. طراحان و مهندسان به او گزارش نمیدهند و بودجه دست او نیست. مدیر محصول باید با اقناع کار کند، نه با دستور.
این تفاوت برای طراح مهم است. مدیر محصولی که خودش را مدیرعامل بداند، ممکن است با طراح مثل اجراکننده رفتار کند. مدیر محصولی که بداند اختیار ندارد، طراح را شریک میکند، چون بدون او به نتیجه نمیرسد. منبع هم در فهرست مهارتها رهبری و ارتباط را کنار تفکر راهبردی آورده است. یعنی همان مهارتهایی که بیاختیار کار میکنند.
منبع تفاوت مدیر محصول با مدیر پروژه را هم روشن میکند. مدیر محصول راهبرد و چشمانداز را جلو میبرد، و مدیر پروژه زمانبندی و تحویلها را اجرا میکند. این دو نقش گاهی در یک نفر جمع میشوند، ولی کارشان یکی نیست.
در بافت فارسی
چند نکته برای طراحان و مدیران محصولی که در ایران با هم کار میکنند.
یک: «مدیر محصول» گاهی همان مدیر پروژه است. در بسیاری از آگهیهای فارسی، عنوان مدیر محصول برای کاری به کار میرود که در اصل مدیریت پروژه است: پیگیری زمانبندی و هماهنگی تیمها. اگر طراحید و با چنین مدیر محصولی کار میکنید، بپرسید تعیین نقشهٔ راه با کیست. شاید جواب مدیرعامل یا صاحب شرکت باشد.
دو: در تیم کوچک، طراح نیمهمدیر محصول است. در استارتاپهایی که مدیر محصول ندارند، طراح اغلب بخشی از کار او را انجام میدهد: پژوهش بازار، اولویتبندی و حتی نوشتن نقشهٔ راه. این سهم را ببینید و در رزومه بنویسید. همین تجربه راه رایجی برای رفتن از طراحی به مدیریت محصول است.
سه: بدون داده، اولویتبندی سلیقه میشود. در تیمهایی که ابزار تحلیل ندارند یا دادهٔ رفتار کاربر را جمع نمیکنند، اولویتبندی به سلیقهٔ بلندترین صدا تبدیل میشود. از روز اول سنجهها را با هم تعریف کنید. حتی چند سنجهٔ ساده بهتر از هیچ است. سنجههای تجربهٔ کاربری از همینجا شروع میشود.
چهار: صاحب محصول در اسکرام با مدیر محصول یکی نیست. در تیمهایی که با اسکرام کار میکنند، نقش «صاحب محصول» صف کار تیم را اداره میکند. مدیر محصول جهت کل محصول را تعیین میکند. در خیلی از شرکتها یک نفر هر دو کار را میکند و این دو نقش در هم میروند. بدانید با کدام طرفید.
پنج: مسئولیت بیاختیار را روشن کنید. مدیر محصول تازهکار ممکن است مسئول نتیجه باشد ولی هیچ تصمیمی با او نباشد. اگر مدیر محصولید، بنویسید کدام تصمیمها با شماست. اگر طراحید، از مدیر محصولتان بپرسید. این کار جلوی همان دلخوریهای ابتدای مقاله را میگیرد.
جمعبندی
مدیریت محصول یعنی ترکیب نیاز کاربر، هدف کسبوکار و فناوری در یک محصول. ریشهاش به یادداشتی در سال ۱۹۳۱ برمیگردد. مدیر محصول میفهمد، جهت میدهد و میسنجد. کار او با طراح بیش از هر نقش دیگری گره خورده است.
چهار خطر کیگن این گره را روشنتر میکند. ارزش و ماندنی بودن با مدیر محصول است، کاربردپذیری با طراح و شدنی بودن با مهندس، ولی کشف کار هر سه است. مرز مسئله و راهحل یک طیف است، نه یک خط. مدیر محصول هم مدیرعامل کوچک نیست، چون اختیار ندارد و باید با اقناع کار کند.
اگر بخواهم یک پرسش بگذارم: مسئلهای که الان روی آن کار میکنید، در یک جمله نوشته شده که شما و مدیر محصولتان هر دو قبولش داشته باشید؟
منبع
این نوشته «بازنویسی آزاد» است از موضوع What is Product Management? منتشرشده در وبسایت بنیاد طراحی تعامل (Interaction Design Foundation — IxDF؛ بدون نام نویسندهٔ مشخص). مفاهیم پایهٔ برگرفته از این منبع — تعریف مدیریت محصول بهعنوان ترکیب فهم نیاز کاربر، هدف کسبوکار و فناوری، فهرست مسئولیتها از پژوهش تا نقشهٔ راه و پیگیری سنجهها، سنجههای رایج، پنج مرحلهٔ کشف، طراحی، آزمون، ساخت و سنجش، مهارتهای اصلی، و تفاوت مدیر محصول با طراح تجربهٔ کاربری و با مدیر پروژه — از این منبع گرفته شده، اما متن فارسی و توضیحها کاملاً مستقل نوشته شدهاند.
متن مقالهٔ اصلی تحت هیچ لایسنس بازی منتشر نشده است؛ به همین دلیل اینجا ترجمهٔ کلمهبهکلمه ارائه نشده و متن کامل انگلیسی (بههمراه همهٔ تصاویر) در لینک زیر در دسترس است.
ارجاعهای بیرونی: یادداشت «مرد برند» نیل مکالروی در پراکتر اند گمبل (۱۹۳۱)؛ چهار خطر محصول از مارتی کیگن، Inspired (ویرایش دوم، ۲۰۱۷)؛ «سهتای محصول» از ترزا تورس، Continuous Discovery Habits (۲۰۲۱)؛ و یادداشت بن هوروویتز، Good Product Manager/Bad Product Manager.
بخشهای افزودهٔ مترجم: بند آغازین دربارهٔ جلسهٔ بازبینی و دلخوری؛ خاستگاه نقش در یادداشت مکالروی؛ سهدسته کردن مسئولیتها و اشاره به جای آزمون پیش از ساخت؛ مقایسهٔ مهارتهای مدیر محصول با مهارتهای طراح و مسیر شغلی میان آن دو؛ کل بخش «تیم سهنفره و چهار خطر» شامل چارچوب کیگن، صاحب هر خطر و سهتای محصول تورس، با نمودار آن؛ کل بخش «مرز مسئله و راهحل» شامل نمودار طیف و جملهٔ مسئلهٔ مشترک؛ کل بخش «افسانهٔ مدیرعامل کوچک» شامل تعبیر هوروویتز و مسئولیت بیاختیار؛ و کل بخش «در بافت فارسی» شامل آمیختگی با مدیریت پروژه، طراح نیمهمدیر محصول، اولویتبندی بدون داده، صاحب محصول در اسکرام، و روشن کردن اختیار.
تصاویر: چهار تصویر صفحهٔ منبع با عنوان استفادهٔ منصفانه (Fair Use) آمدهاند؛ هیچکدام اینجا بازتولید نشدهاند. هر سه نمودار این صفحه طراحی اختصاصی مترجم است.
مشاهدهٔ مقالهٔ اصلی
مدیریت محصول