01Product Manager
مدیر محصول
روی چرایی و ارزش کار تمرکز دارد: مسئله کدام کاربر مهم‌تر است، چه چیزی باید اولویت بگیرد و با چه معیاری نتیجه را بسنجیم؟
تصمیم کلیدیچه مسئله‌ای ارزش حل‌کردن دارد؟
PRODUCT THINKING × ENGINEERING
مدیر محصول فنی؛ از مسئله واقعی تا تصمیم قابل دفاع
مدیر محصول خوب قرار نیست برای هر درخواستی فوری یک قابلیت تازه تعریف کند. اول باید بفهمد چه چیزی واقعا مشکل‌ساز شده و چرا حل‌کردنش مهم است. من معین قزلباش هستم؛ مدیر ارشد محصول فنی و در این صفحه از روش فکرکردن، تجربه‌ها و اشتباه‌هایی می‌گویم که در توسعه محصولات دیجیتال اهمیت دارند.
مدیریت محصول B2Bراهبرد و نقشه راهفناوری و داده
یک مسیر، چهار سؤال
۰۱مسئله چیست؟
۰۲کدام راه‌حل؟
۰۳چه چیزی بسازیم؟
۰۴از کجا بفهمیم؟
مسئله، راهکار، نتیجه
قبل از فیچر، مسئله
«این قابلیت را اضافه کنیم» هنوز یک مسئله محصول نیست.
فرض کن فروش یک پلتفرم رزرو پایین آمده و اولین پیشنهاد، بازطراحی صفحه جست‌وجوست. ممکن است مشکل از رابط کاربری باشد؛ اما شاید موجودی نامعتبر است، پاسخ API دیر می‌رسد یا کاربر در آخرین مرحله رزرو منصرف می‌شود. اگر بدون تشخیص علت شروع کنیم، یک فیچر دیگر ساخته‌ایم بدون اینکه مطمئن باشیم مسئله‌ای حل شده است.
برای همین، مدیریت محصول را ترکیبی از شناخت کاربر، فهم کسب‌وکار، تصمیم فنی و سنجش نتیجه می‌دانم؛ نه صرفا مدیریت تسک‌ها.
اول می‌پرسم «چه چیزی برای کاربر درست پیش نمی‌رود؟»؛ بعد می‌رسم به «چه چیزی باید بسازیم؟»
نوشته معین قزلباش؛ مدیر ارشد محصول فنی
تعریف نقش‌ها
مدیر محصول، مدیر محصول فنی و مالک محصول چه تفاوتی دارند؟
این عنوان‌ها در شرکت‌های مختلف گاهی روی هم می‌افتند. تفاوت مهم، نام سمت نیست؛ نوع تصمیم و مسئولیتی است که فرد به عهده دارد.
02Technical Product Manager
مدیر محصول فنی
همان تصمیم‌های محصول را با درک محدودیت‌های API، داده، معماری، یکپارچه‌سازی و پایداری سرویس به تصمیم اجرایی تبدیل می‌کند.
تصمیم کلیدیچه راهی هم ارزشمند است و هم شدنی؟
03Product Owner
مالک محصول
در چارچوب اسکرام مسئول مدیریت اثربخش بک‌لاگ محصول و شفاف‌بودن هدف آن است. این مسئولیت می‌تواند با نقش مدیر محصول در یک نفر جمع شود.
تصمیم کلیدیتیم برای ساخت چه چیزی و با چه ترتیبی آماده است؟
برای آشنایی با تعریف رسمی مسئولیت مالک محصول، راهنمای اسکرام را بخوان.
روشی که با آن کار می‌کنم
از یک سؤال خوب تا یک تصمیم قابل سنجش
هر پروژه شرایط خودش را دارد، اما چهار مرحله زیر کمک می‌کند قبل از هزینه‌کردن منابع، درباره ارزش و ریسک کار روشن‌تر تصمیم بگیریم.
- 01Discovery
کشف مسئله
به جای اینکه فهرست درخواست‌ها را حقیقت فرض کنم، سراغ رفتار واقعی کاربران، داده‌ها و مسیر انجام کار می‌روم. مسئله را طوری می‌نویسم که همه تیم درباره یک چیز صحبت کنند.
- 02Prioritisation
انتخاب و اولویت‌بندی
هر پیشنهاد را کنار ارزش مورد انتظار، پیچیدگی اجرا، وابستگی‌ها و ریسک می‌گذارم. نقشه راه باید روشن کند چرا کاری را حالا انجام می‌دهیم و کاری دیگر را نه.
- 03Delivery
MVP و تحویل تدریجی
به جای ساختن نسخه کامل در قدم اول، کوچک‌ترین راهکاری را انتخاب می‌کنم که بتواند ارزش را نشان دهد. کنار تیم مهندسی، درباره API، تجربه کاربر و آزمون پیش از انتشار تصمیم می‌گیریم.
- 04Measurement
اندازه‌گیری و اصلاح
انتشار پایان کار نیست. بررسی می‌کنم آیا کاربر راحت‌تر به هدفش رسیده، خطای کمتری رخ داده یا عملیات سریع‌تر شده است. اگر نه، فرضیه یا راهکار را اصلاح می‌کنیم.
بخشی از تجربه حرفه‌ای من
این نگاه در دنیای واقعی چه شکلی پیدا می‌کند؟
تجربه محصول همیشه یک نمودار رشد چشمگیر نیست. گاهی ارزش کار در فهمیدن یک وابستگی پنهان، ساده‌کردن فرایند یا جلوگیری از ساختن چیزی است که هنوز به آن نیاز نداریم.
پلتفرم B2B01
چنلید؛ رزرو هتل برای سازمان‌ها
در یک پلتفرم رزرو هتل، زیبایی پنل فقط بخشی از تجربه است. موجودی، قیمت، سرعت پاسخ و قراردادهای API مستقیما روی موفقیت کاربر اثر می‌گذارند. از کار در این فضا یاد گرفته‌ام نیاز مشتری سازمانی را باید کنار واقعیت تامین و عملیات دید.
تصمیم محصولاولویت دادن به قابلیت اطمینان و وضوح فرایند، نه صرفا اضافه‌کردن گزینه‌های بیشتر.
ساخت محصول02
گردش؛ پلتفرم چندرسانه‌ای
در توسعه گردش، انتخاب‌های محصول با مسائل فنی جدی گره خورده‌اند: دسترسی ناشر، انتشار محتوا، محدودیت پلن، هزینه نگهداری فایل و تجربه شنیدن یا تماشاکردن. برای همین از ابتدا درباره قواعد رشد و پایداری سرویس فکر می‌کنم.
چالش اصلیتعادل بین آزادی ناشر، تجربه مخاطب و هزینه واقعی پلتفرم.
کشف محصول03
Farvah Cafe؛ از نرم‌افزار داخلی تا محصول
وقتی ایده تبدیل نرم‌افزار یک کافه به محصولی برای کافه‌های دیگر را بررسی می‌کنیم، پرسش اصلی «چه قابلیت‌هایی اضافه کنیم؟» نیست. باید فهمید آیا فرایند سفارش، صندوق، انبار و نقش کارکنان در کافه‌های دیگر هم همین‌طور کار می‌کند یا نه.
پرسش محصولقبل از توسعه گسترده، کدام فرضیه‌ها را باید با چند کسب‌وکار واقعی آزمود؟
اندازه‌گیری بدون عددسازی
KPI خوب باید به تصمیم بهتر منجر شود
شاخص‌های مدیر محصول برای همه محصولات یکسان نیستند. به جای یک فهرست طولانی از اعداد، سراغ معیارهایی می‌روم که درباره تجربه کاربر یا کیفیت عملیات چیزی بگویند.
- رزرو و تجارت B2Bنرخ تکمیل موفق رزرو، خطای تامین و زمان پاسخ
- نرم‌افزار عملیاتیزمان انجام کار، خطای ثبت و استفاده واقعی از قابلیت
- پلتفرم محتوامصرف واقعی محتوا، بازگشت مخاطب و کیفیت ارائه سرویس
پاسخ‌های کوتاه و کاربردی
سؤال‌هایی که درباره مدیریت محصول زیاد مطرح می‌شوند
مدیر محصول کیست و چه وظایفی دارد؟
مدیر محصول کمک می‌کند تیم روی مسئله درست کار کند. شناخت کاربر، تعریف هدف، اولویت‌بندی فرصت‌ها، هماهنگی ذی‌نفعان، تدوین نقشه راه و ارزیابی نتیجه از مسئولیت‌های رایج این نقش‌اند. انجام همه این کارها به‌تنهایی هدف نیست؛ مهم این است که تصمیم‌ها به ارزش واقعی برای کاربر و کسب‌وکار برسند.
مدیر محصول فنی باید برنامه‌نویسی بلد باشد؟
لازم نیست در هر تیم کدنویس اصلی باشد، اما باید بتواند درباره API، داده، معماری و محدودیت‌های اجرا با مهندسان گفت‌وگو کند. پیش‌زمینه فنی کمک می‌کند دامنه کار، وابستگی‌ها و ریسک‌ها را دقیق‌تر بفهمد.
تفاوت Product Manager و Product Owner چیست؟
Product Manager معمولا روی مسئله بازار، ارزش محصول و جهت حرکت تمرکز می‌کند. Product Owner در اسکرام پاسخ‌گوی ارزش محصول و مدیریت اثربخش بک‌لاگ است. در بعضی سازمان‌ها این دو مسئولیت روی یک نفر قرار می‌گیرند؛ عنوان به‌تنهایی شرح کار را مشخص نمی‌کند.
تفاوت مدیر محصول و مدیر پروژه چیست؟
مدیر پروژه بیشتر مسئول برنامه‌ریزی و هماهنگی اجرای کار در محدوده زمان، منابع و تعهدات مشخص است. مدیر محصول از ابتدا می‌پرسد چرا این کار ارزش ساختن دارد، برای چه کسی و با چه نتیجه‌ای. در یک تیم خوب، این دو نگاه به جای رقابت، مکمل هم هستند.
مهم‌ترین مهارت‌های مدیر محصول کدام‌اند؟
توانایی گوش‌دادن و مصاحبه با کاربر، تحلیل داده، نوشتن مسئله و نیازمندی روشن، اولویت‌بندی، مذاکره، ارتباط با تیم فنی و قضاوت درباره نتیجه از مهم‌ترین مهارت‌ها هستند. ابزارها کمک می‌کنند؛ جای این مهارت‌ها را نمی‌گیرند.
از دفترچه تصمیم‌های محصول
همه یادداشت‌های مدیریت محصول
دو مسئله واقعی برای فکرکردن به محصول
اگر دوست داری ببینی این مدل فکرکردن در یک مسئله طراحی محصول چطور پیش می‌رود، این دو یادداشت را بخوان.
برای همکاری
اگر مسئله محصولت هنوز کاملا روشن نیست، از همان‌جا شروع کنیم.
چه برای توسعه یک پلتفرم B2B باشد، چه بازبینی نقشه راه یا هماهنگ‌کردن محصول و فناوری، ترجیح می‌دهم قبل از پیشنهاد راهکار، مسئله و محدودیت‌هایش را بشنوم.