مدیرمحصول یا مدیر پروژه یا مالک‌محصول یا مستر اسکرام؟
مرکز نوآوری آو: نیکو نیکنام – مدیر محصول
یکی از اتفاق‌هایی که در چند سال اخیر در ایران رخ داده پر کاربرد شدن عناوین شغلی جدیدی‌ست که برای خیلی از افراد ناآشنا و غریب است. ناآشنا و غریب از چه لحاظ؟ از لحاظ اینکه نمی‌دانند فرق مدیر محصول (product manager) - مدیر پروژه (project manager)، مالک محصول (product owner) و اسکرام مستر (Scrum Master) در چیست. آیا اصولا این عناوین شغلی با هم فرقی دارند و یا اینکه صرفا عناوین جدیدی برای یک کار هستند؟ اگر شما هم این سوالات را دارید باید بدانید که این سوال افراد زیادی‌ست و شما به هیچ وجه تنها نیستید. حتی میشود یک گام فراتر رفت و گفت اگر کسی به واسطه‌ی کار خود با افرادی با عناوین شغلی بالا برای مثال مدیر محصول همکار بوده است و به این وسیله با شرح شغلی عنوان مدیر محصول آشنا است، ممکن است وارد شرکت جدیدی شود و ببیند که مدیر محصول شرکت جدید کاری کاملا متفاوت از مدیر محصول شرکت قبل انجام میدهد! و دوباره این سوال برایش ایجاد شود که بلاخره مدیر محصول چه کاری انجام میدهد؟
قبل از خواندن این متن در یاد داشته باشیم که اختلاف عقاید زیادی در رابطه با تعاریف این عناوین شغلی وجود دارد و نوشته‌ی زیر ترکیبی از تعاریف راهنمای اسکرام و اجایل، بخش آموزشی لینکدین، منابع دیگر و تجربیات خودم می‌باشد.
اسکرام چیست و چه ربطی به این نوشته دارد؟
برای پاسخ به سوالات بالا و توضیح هر کدام از این عناوین شغلی، باید ابتدا یک چهارچوبی به نام اسکرام را خلاصه توضیح دهیم. چرا؟ چون ۲ تا از این عناوین شغلی بالا مستقیم به اسکرام ربط دارند.
اسکرام چیست؟
اسکرام (اسم خاص): چارچوبی است که در آن افراد می‌توانند درحالیکه به شکلی پربار و خلاقانه محصولاتی با بالاترین ارزش ممکن ارائه می‌دهند، مشکلات پیچیده سازگار پذیر را نیز حل کنند. (موسسه‌ی اسکرام ایران)
تیم اسکرام
در تیم اسکرام همانند روشها و متدلوژی‌های رایج، نقش مدیر پروژه Project Manager به صورت یک نقش مستقل در این چهارچوب تعریف نمی‌شود. چرا در این چهارچوب این نقش را نداریم؟ چون تیمهای اسکرام خودسازمانده و فراوظیفهای هستند. تیمهای خودسازمانده بجای اینکه توسط فرد دیگری از خارج تیم، مدیریت شوند، خودشان بهترین روش انجام کار را انتخاب میکنند. تیمهای فراوظیفهای تمام شایستگی لازم برای انجام کار را بدون وابستگی به خارج تیم دارند.
از همین جهت برابر قراردادن Project Manager با اسکرام مستر یا مالک محصول در چهارچوب اسکرام اشتباه است،
وظایفProject Manager در چهارچوب اسکرام توسط ۳ نقش اصلی موجود در تیم اسکرام پوشش داده و تقسیم شده است. (یادمان باشد که این نافی نقش مهم و پررنگ مدیر پروژه نیست، تنها باید این موضوع را بدانیم که در چهارچوب اسکرام، نقشی به عنوان مدیر پروژه وجود ندارد)
- مالک محصول (Product Owner)
- مستر اسکرام (Scrum Master)
- تیم توسعه (Development Team) – این نقش تا حد زیادی واضح است و من در این پست به توضیح این نقش از دید اسکرام، نمی‌پردازم.
۱- مالک محصول (Product Owner)
اولین نکته‌ی مهم این است که بدانیم مالک محصول PO برخلاف تصور عمومی، یک عنوان شغلی است. (برای بررسی این مورد می‌تواند صدها آگهی product owner را در وبسایت‌های معتبر کاریابی بین‌المللی مشاهده کنید.) مالک محصول، مسئول به حداکثر رساندن ارزش محصولی است که از کار تیم توسعه حاصل میشود. ممکن است سوال بپرسید: به حداکثر رساندن ارزش محصول یعنی چی؟ به طور خلاصه این جمله به این معنا است که مالک محصول به دو روش، کمک میکند تیم توسعه محصول اشتباهی را نسازد.
سوال: آیا ممکن است که تیم توسعه محصول اشتباهی را بسازد؟ بله.
سوال: چطور ممکن است تیم توسعه محصول اشتباهی بسازد؟ به دو طریق:
روش اول – تسک‌های اشتباه: بسیار پیش آمده است که تیم توسعه درست متوجه تسک‌ها نشده و برداشت خودش را از تسک داشته است و بنا بر برداشت خودش، تسک را کد زده‌است و وقتی تسک دان شده است، تازه PO متوجه میشود که ای بابا، تسک به شکل دیگه‌ای که مد نظر مدیر محصول نبوده، دولوپ شده است. یا مالک محصول، در جلسات نوشتن تسک‌های اسپرینت منظور مدیر محصول را به درستی متوجه نشده است و بر اساس سو‌تفاهم پیش‌آمده، تسک‌های اشتباهی را نوشته است و خب واضح است که محصول نهایی توسعه‌یافته، اشتباه و مغایر با خواسته‌های سهامداران بوده است.
روش دوم – تسک‌های درست در زمان اشتباه: در نظر بگیرید که تیم توسعه یک تسک دارد به نام ورود کاربر. این تسک، تسک درست و ضروری است. اما اگر مالک محصول تصمیم بگیرد که تسک ورود کاربر به پنل کاربری به جای اسپرنت‌های اول، در اسپرینت ۱۰ ام توسعه‌دهد، چه اتفاقی می‌افتد؟ اتفاقی که می‌افتد این است که ما هیچ محصولی را نمی‌توانیم به سهامداران تا انتهای اسپرینت ۱۰ برای تست تحویل بدهیم، چون به سادگی کاربر نمی‌تواند در سرویس ما لاگین کند! بنابراین اگر زمان‌بندی تسک‌ها درست نباشد، تیم توسعه در حال انجام کار بر روی موارد اشتباهی است و این با به حداکثر رساندن ارزش محصول خروجی هر اسپرینت، در تضاد است.
- مالک محصول –> build the right thing – what is the right thing to do? when is the right time
- تیم توسعه –> build the thing right
- اسکرام مستر –> buidl it fast
سوال: تسک‌ها را مدیر محصول به PO می دهد و یا خودش می‌نویسید؟
اگر ما مدیر محصول داریم، دوتایی با هم می‌نویسند. مدیر محصول خواسته‌های خودش را توضیح میدهد و PO بعد از اطمینان از فهم درست خواسته‌ها، آنها را در بکلاگ تسک میکند. نقش مالک محصول اینجا این است که اگر مدیر محصول خواسته‌های نادرست و غیر واقعی داشته باشد، با توضیح و مشورت، از ورود تسک‌های غیر‌ضروری و اشتباه به بکلاگ جلوگیری کند.
اگر مدیر محصول نداریم، مالک محصول خودش بر اساس خواسته‌های سهامداران و داکیومنت محصول تسک‌ها را در بکلاگ می‌نویسد.
در واقع داشتن توانایی build the right thing – what is the right thing to do? when is the right time برای PO و مدیر محصول، ضروری است. (جلوتر خواهیم دید که تعاریف مالک محصول و مدیر محصول باهم شباهت زیادی دارند.)
مالک محصول می‌تواند در شرکت‌های مختلف، در جایگاه‌های زیر ایفای نقش کند:
- رابط تیم توسعه و مشتری
- رابط تیم توسعه و مدیر محصول
- رابط تیم توسعه و بخش فروش و مارکتینگ
سوال: آیا مالک محصول فقط در این جایگاه‌ها می‌تواند قرار بگیرد؟ خیر. اینها گزینه‌های مرسوم‌تر جامعه هستند وگرنه تنها ارتباط مهم و ضروری، ارتباط مالک محصول با تیم توسعه است و بسته به سازمان، مالک محصول می‌تواند در کنار تیم توسعه با تیم های مختلف ارتباط داشته باشد که البته معروف‌ترین ترکیب، ترکیب مالک محصول به عنوان رابط تیم توسعه و مدیر محصول است.
مالک محصول بر خلاف نام شبهه برانگیز آن تهیه کننده (اسپانسر) پروژه، مالک کسب و کار و یا فرد صاحب ایده نیست و یک نفر از اعضای تیم محصول است. مالک محصول، مالک بکلاگ است و کلمه‌ی مالک به مالکیت بکلاگ اشاره دارد نه مالکیت محصول.
مالک محصول ۲ تا وظیفه‌ی عمده و جدی دارد:
۱- مسئولیت مدیریت بکلاگ محصول را دارد. بکلاگ محصول در حقیقت قلب اسکرام است. هر اقدامی برای توسعه از طرف تیم توسعه باید با تغییر آیتم های موجود در بکلاگ محصول صورت پذیرد و تنها مالک محصول مجاز به ایجاد تغییر در بکلاگ است. (مدیریت بکلاگ مهمترین و اصلی‌ترین وظیفه‌ی مالک محصول است که برای انجام آن باید به صورت مدام با همه‌ی افراد درگیر در محصول در ارتباط باشد.)
۲- با همه‌ی اعضای تیم و یا تیم‌ها در ارتباط است. در چهارچوب اسکرام به روابط بین فردی بیش از مستندات بها داده میشود، از همین جهت نقش مالک محصول به عنوان رابط تمامی افراد درگیر پروژه بسیار مهم است.
مدیریت بکلاگ محصول شامل موارد زیر میشود:
- توضیح کامل موارد بکلاگ محصول بهصورت شفاف (تیم توسعه باید دقیق بداند که قرار است چه مواردی را در چه مدت زمانی توسعه دهد و اینکه چرا این کار را میکند.)
- اطمینان از اینکه بکلاگ محصول برای همه شفاف و واضح بوده و تیم توسعه به درکی کافی و لازم از موارد بکلاگ محصول رسیده است. (مالک محصول همیشه باید از شفافیت و درک درست بکلاگ مطمئن باشد.)
- اطمینان از دسترسی هم‌ی اعضای تیم به بکلاگ (مالک محصول باید همیشه از دسترسی همه‌ی افراد تیم به بکلاگ مطمئن باشد.)
- الویت‌بندی موارد موجود در بکلاگ محصول و تخمین زمانی هر کدام از موارد (با مشورت تیم فنی)
- دریافت موارد پیاده‌سازی شده‌ی (Done) بکلاگ (یوزر استوری‌ها) از تیم فنی و اطمینان از کامل انجام شدن آنها (تست توسط خودش و یا توسط تیم تست)
- تصمیم گیری درباره‌ی ادامه و یا لغو یک اسپرینت (در موارد بسیار نادر با تغییر شرایط نیازمندی‌های محصول، مواجه با موارد پیش‌بینی نشده و یا برای حل مشکلات بسیار مهم PO می‌تواند یک اسپرینت را همراه با تمامی موارد بکلاگ لغو کند و دستور به توقف کار توسعه بدهد.)
موارد بالا را ممکن است مالک محصول خودش انجام دهد و یا تیم توسعه اقدام به انجام آنها کند. درهرصورت مالک محصول همچنان مسئول و پاسخگو باقی میماند. برای مثال ممکن است بخشی از تسک‌های بکلاگ تا حد زیادی فنی باشند، در این صورت مالک محصول، نوشتن و مدیریت این تسک‌ها را می‌تواند به تیم فنی بسپارد. البته اگر به هر شکل مشکلی در رابطه با این تسک‌ها به وجود بیاید، مالک محصول پاسخگو است. مالک محصول بیان‌کننده‌ی خواسته‌های سهامداران و مالکین کسبوکار در قالب بکلاگ محصول است و افرادی که مایل به تغییر اولویتِ اقلام بکلاگ محصول هستند باید مالک محصول را مخاطب خود قرار دهند و مستقیم با تیم فنی در تماس نباشند. برای موفقیت مالک محصول، کل سازمان باید به تصمیمات او احترام بگذارد. تصمیمات مالک محصول در قالبِ محتوا و الویت‌بندی موارد بکلاگ محصول اجرا خواهند شد (تصویر پایین) و هیچکس نباید تیم توسعه را مجبور به کار بر روی یک سری نیازمندی دیگر کند که در بکلاگ تیم قرار داده نشده است. همچنین این نکته بسیار مهم است که بدانیم مالک محصول به صورت متداول یک نفر است. (البته در بسیاری از زمان‌ها در محصولات بزرگ ما تیمی از مالکین محصول داریم. اینکه product ownership team به چه شکل کار میکند، خودش یک بحث دیگری است که در این پست نمی‌گنجد).
سوال: مالک محصول بر اساس چه اصولی برای تسک‌های بکلاگ تصمیم می‌گیرد؟
بر اساس نگرش agile مالک محصول بر اساس اصول زیر تصمیم می‌گیرد و رفتار میکند:
۱-۱ ارزش ها value
۱-۲ تصمیم گیری decision making
۱-۳ رابطه engagement
بدون این ۳ تا ویژگی مهم، تیم نمی‌تواند به درستی کار خودش را انجام دهد و روند توسعه‌ی محصول با مشکلات زیر روبرو خواهد شد.
تیم سریع محصول را می سازد ولی به احتمال زیاد محصول ساخته شده برای مشتری، مفید و کارا نیست.
روند ساحت محصول خیلی کند پیش می رود و تیم تسک‌های لازم را در هر sprint تمام نمی‌کند.
تیم تسک‌های نادرستی را در هر اسپرینت پیش می‌برد و به این شکل، کار ساخت محصول در مسیر درست پیش نمی‌رود.
۱-۱ ارزش‌ها
در هر مرحله از ساخت محصول، مالک محصول باید اطمینان داشته باشد که بودجه و هزینه‌ای که صرف ساخت محصول میشود در راستای برآورده کردن خواسته‌های مدیر محصول، سهامداران و مالک کسبوکار است. برای انجام درست این کار، مالک محصول (درصورت نبود مدیر محصول) باید مرتب با مالکین کسبوکار، سهامداران و مشتری نهایی و یا نماینده مشتریان در تماس باشد تا تسک‌های بکلاگ به درستی بر اساس ارزشهای تعریف شده‌ی محصول چیده شوند و خروجی هر اسپرینت همسو با نظرات مشتری باشد. (اگر فردی به عنوان مدیر محصول در تیم ما است، وظیفه‌ی گفتگو با سرمایه‌گذاران فعلی و احتمالی و سهامداران درباره‌ی شرایط محصول، بر عهده‌ی مدیر محصول است و PO، نظرات سهامداران را از مدیر محصول دریافت میکند و با اعمال نظرات آنها در بکلاگ محصول، پروسه‌ی توسعه‌ی محصول را با تیم فنی پیش می‌برد.)
۱-۲ تصمیم گیری
در بسیاری از موارد، بین تیم توسعه، تیم مارکتینگ، نظرات سهامداران و باقی تیم‌ها اختلاف نظر پیش می‌آید. تیم توسعه اصرار بر اجرایی شدن یک سری از تسک‌ها دارند و سهامداران نظرشان بر اجرای یک کار دیگر است. (در نظر داشته باشیم اگر در تیم ما نقش مدیر محصول وجود دارد، به احتمال زیاد مالک محصول مستقیما با سهامداران در ارتباط نیست. البته بحث نیاز به تصمیم گیری بر سر جای خود باقی میماند چون در آن حالت اختلاف نظر به جای سهامداران با مدیر محصول پیش خواهد آمد.)
مالک محصول کسی است که باید تصمیم بگیرد که در اسپرینت پیش رو و یا در یک شرایط خاص کدام فیچر و کدام ویژگی develop شود. در واقع مالک محصول به علت تسلط بر خواسته‌ی مدیر محصول و یا سهامداران، نوع کسب و کار محصول در حال توسعه، نظرات مشتری نهایی مصرف کننده و محدودیت‌های تیمهای توسعه، توانایی تصمیم‌گیری درست را دارد.
۱-۳ رابطه‌ی پیوسته با تیم و محصول
در بالاتر اشاره کردیم که در چهارچوب اسکرام به روابط بین فردی بیش از مستندات بها داده می شود، از همین جهت نقش مالک محصول به عنوان رابط تمامی افراد درگیر پروژه بسیار مهم است. مالک محصول باید در جریان کارهای روزمره تیم توسعه دهنده‌ی محصول باشد. باید خیلی دقیق بداند که تیم در حال حاضر بر روی توسعه‌ی چه مواردی کار میکند تا اگر سوالی از سمت تیم توسعه پیش آمد بتواند به درستی پاسخ دهد. اگر مالک محصول اشراف درستی بر روی کار تیم توسعه نداشته باشد، خیلی زود تیم توسعه در بخش‌هایی که دچار سوال میشود،چون پاسخ مناسبی از مالک محصول نمی‌گیرد، بنابر صلاحدید خودش تسک به بکلاگ اضافه و کم میکند و این شروع پروسه‌ای خواهد شد که روند توسعه‌ی محصول از ارزشهای business دورخواهد شد. البته اگر در یک تیم نقش اسکرام مستر وجود داشته باشد (یک اسکرام مستر تمام وقت، نه یک developer که در کنار باقی کارها اسکرام مستر ما نیز هست)، مالک محصول می‌تواند تا حد کمی در ارتباط روزانه‌ی پیوسته با تیم فنی نباشد اما اگر اسکرام مستر تمام‌وقت در تیم وجود ندارد، بسیار مهم است که رابطه با تیم توسعه (رابطه‌ی حضوری و یا دورکاری) از سمت مالک محصول به صورت پیوسته برقرار باشد.
چه کسانی می‌توانند مالک محصول باشند؟ (Product owner’s typical background)
این سوال خیلی از افراد است که چگونه ما میتوانیم مالک محصول باشیم. واقعیت این است که رشته‌ای دانشگاهی و یا کلاس آموزشی تحت عنوان دوره‌های مالکیت محصول نداریم و این عنوان شغلی نیز، یک شغل entry-level نیست که شما بدون تجربه‌ی کاری بتوانید در آن استخدام شوید.
مالکین محصول ممکن است با بک گراند‌های متفاوتی به این عنوان شغلی دست پیدا کرده باشند. در واقع تجربیات شغلی مالک محصول تا حد زیادی بستگی به نوع محصولی دارد، که ما در حال ساخت آن هستیم.
۱– بک گراند business، مدیر پروژه، business analysts
اگر تیم مشغول ساخت یک محصولی برای استفاده درون سازمانی (internal users of the organization) است، مالک محصول می‌تواند یک مدیر پروسه، سرپرست تیم و یا مدیر پروژه شاغل در سازمان شما باشد. اما باید حتما در خاطر داشته باشیم تنها وقتی یک مدیر پروژه می‌تواند نقش مالک محصول را بر عهده بگیرد که توانایی تصمیم گیری سریع، موثر و درست درباره functions, features, and priorities داشته باشد. در غیر این صورت تیم حتما دچار مشکل خواهد شد و فیچرهای نادرستی را توسعه خواهد داد.
۲- بک گراند مدیر محصول و یا بخش‌های مرتبط با مشتری
اگر تیم مشغول ساخت یک محصول برای استفاده مشتریان خارج از سازمان (external, customer-facing) است. مالک محصول خوب است که در اولین انتخاب از بک گراند مدیریت محصول بیاید. در انتخاب‌های بعدی، افرادی با سابقه‌ی مدیریت در بخش‌های مرتبط با مشتری نیز می‌توانند مالک محصول شوند.
۳- بک گراند تکنولوژی
از جایی‌که یکی از مهمترین وظایف مدیر محصول حفظ ارزشهای business محصول از جمله کارایی و کاربری ساده محصول از دید مشتری، امکانات درآمدزایی و تحویل به موقع محصول در زمان معین است، داشتن بکگراند تکنولوژی ریسک ایجاد مشکل و تصمیم گیری‌های نادرست را از سمت مالک محصول در حوزه‌ی business بالا می‌برد. به این شکل که مالک محصول بر روی ویژگی‌های فنی محصول و خواسته‌های تیم توسعه بیشتر تمرکز میکند تا نظرات مشتری و توانایی‌های درآمدزایی محصول. در این شرایط خوب است که در کنار مالک محصول یک مدیر محصول قرار داشته باشد که عملکرد و نحوه‌ی پیشرفت پروژه را مانیتور کند که مبادا وزن بخش تکلنولوژی محصول از باقی بخش‌ها سنگین‌تر شود. البته در این بخش یک استثنا هم وجود دارد: اگر مخاطب و مشتری نهایی محصول که ساخته میشود، تیم های توسعه (developers) و تیمهای فنی باشند وجود یک مالک محصول با بکگراند تکنولوژی، یعنی فردی از جنس بیزنس و مشتری‌های آینده و این بهترین انتخاب است.
خارج از تعاریف رسمی و بر اساس تجربه:
مالک محصول (Product Owner) می‌تواند یکی از نقش های هم زمان مدیر محصول (Product Manager) نیز باشد. در واقع در زمانی که ما فردی را به عنوان مالک محصول در تیم خود نداریم، مدیر محصول می‌تواند وظایف این نقش را نیز بر عهده بگیرد اما این به طور قطع از کیفیت عملکرد محصول شما خواهد کاست.
در تیمهای کوچک مدیر محصول، مدیریت بکلاگ و وظایف افراد را نیز برعهده می‌گیرد. اما باید این موضوع یادمان نرود که مدیر محصول تنها به علت کوچکی تیم می‌تواند این کار را انجام دهد و اگر تیم فنی شما فقط کمی بزرگ شود و یا بخواهید تیم فنی در ارتباط موثری با تیم مارکتینگ و فروش باشد، شما حتما به یک مالک محصول خوب نیاز دارید. همچنین این نکته را در ارتباط با تیمهای کوچک از یاد نبرید که اگر احیانا مدیر محصول همزمان مدیر پروژه، مدیرعامل و یا مدیر اجرایی کسب و کار باشد، از پس وظایف مدیریت بکلاگ حتی یک تیم بسیار کوچک فنی نیز برنخواهد آمد. مدیر محصول وظایف دیگری هم دارد که در بخش‌های بعدی مفصل آن را توضیح داده خواهد شد.
۲- اسکرام مستر (Scrum Master)
نکته‌ی مهمی که درباره‌ی عنوان اسکرام مستر باید بدانید این است که اسکرام مستر می‌تواند یک عنوان شغلی کامل تمام وقت و یا تنها یک نقش سازمانی برای یکی از افراد تیم باشد. اسکرام مستر به صورت خلاصه چهار نقش جدی دارد:
مدیر و مالک پروسه‌ی اسکرام است و در واقع او تصمیم می‌گیرد که کدام یک از scrum event ها و به چه شکلی در سازمان اجرایی شوند. اسکرام یک چهارچوب برای راحتی و بازدهی بیشتر عملکرد تیم توسعه است. بنابراین اگر اسکرام مستر به این نتیجه رسید که برگزاری برخی از ایونت‌ها از بازدهی تیم کم میکند، این اختیار را دارد تا این موارد را حذف کند.
رابط (متعادل کننده) بین تیم توسعه(بخش تکنولوژی) و مالک محصول(بخش ارزشهای بیزنس و درآمدزایی) است. چرا تیم توسعه به این رابط نیاز دارد؟ چون در بسیاری از موارد مالک محصول با فشار بر روی تیم توسعه سعی دارد که تعداد تسک هر اسپرینت را بالا ببرد تا کارها زودتر جلو برود. اگر یادتان باشد، مالک محصول، در بسیاری از موارد با بک گراند تکنولوژی نبود و همین باعث میشود که متوجه دغدغه‌ها و مشکلات تیم توسعه نشود.
اسکرام مستر، یک نقش سازمانی بسیار مهم است چون اسکرام مستر به تیم توسعه، مدیر محصول، مالک محصول و سازمان کمک میکند تا درک کنند که کدامیک از رفتارها و تعاملاتشان با تیم اسکرام، مفید بوده و کدامیک نبوده است. این کمک میکند تا اگر برخی کارها باعث ایجاد حاشیه و مشکلات برای تیم فنی کرده است، بشود سریع برطرف کرد.
همچنین وظیفه‌ی آموزش سازمان، تیم‌ها و افراد و اجرای پروسه‌ی اسکرام بر عهده‌ی اسکرام مستر است.
هر اسکرام مستر معمولا رهبری یک تیم ۳ تا ۷ نفر را بر عهده دارد. هرچه قدر گروه اسکرام بزرگ تر شود از چابکی آن کاسته میشود زیرا تعامل افراد گروه با هم و با اسکرام مستر کمتر میشود.
به سادگی می‌توان ارتباط نقش‌های سازمانی اسکرام را توضیح داد:
- اسکرام مستر با تیم توسعه و مالک محصول PO ارتباط دارد.
- تیم توسعه با اسکرام مستر و مالک محصول PO ارتباط دارد.
- مالک محصول PO (درصورت نبود مدیر محصول) با سهامداران، اسکرام مستر و تیم توسعه ارتباط دارد.
راهنمای رسمی اسکرام، اسکرام مستر را به این شکل تعریف میکند:
اسکرام مستر مسئولیت ترویج و حمایت از اسکرام به‌گونه‌ای که در راهنمای اسکرام تعریف‌شده است را بر عهده دارد. اسکرام مستر این کار را از طریق کمک به دیگران برای درک مبانی نظری، روشها، قوانین و ارزشهای اسکرام انجام میدهد. اسکرام مستر یک رهبر خدمتگزار (serving leader) برای تیم اسکرام است.
در بالاتر اشاره کردیم که اسکرام مستر یک رهبر خدمگزار است. به زبان ساده، رهبر خدمت گزار یعنی در عین حال که اسکرام مستر تیم را رهبری میکند اما همزمان مسئول حل مشکلات و نیازهای تیم است تا تیم توسعه بتواند به حد عالی کار خود را انجام بدهد.
اکنون بررسی می‌کنیم که اسکرام مستر به چه شکلی و در چه مواردی به چه کسانی کمک میکند.
ارتباط اسکرام مستر با مالک محصول (PO)
اسکرام مستر به مالک محصول کمک میکند که اهداف و چشم‌انداز محصول که PO بر اساس درخواست سهامداران، محدودیت‌های تیم توسعه و نیازهای مشتری نهایی تعیین کرده‌است برای تیم توسعه (فنی) و باقی تیمهای درگیر و مرتبط با محصول، کاملا مشخص و روشن باشند.
بررسی روش‌های مدیریت بکلاگ محصول و پیداکردن موثر‌ترین روش بروز نگه داشتن بکلاگ
حصول اطمینان از اینکه مالک محصول میداند به‌منظور بیشینه‌سازی ارزش، چگونه بکلاگ محصول را مرتب کند. (آموزش و راهنمایی مالک محصول در ارتباط با شرایط و توانایی‌های تیم)
ارتباط اسکرام مستر با تیم توسعه
- برگزاری و تسهیل جلسات اسکرام
- آموزش و تمرین چابکی Agile (برنامه های آموزشی مرتبط با مفهوم چابکی در سطح تیم)
- مربیگری تیم توسعه در مسیر خودسازمانده و فراوظیفهای شدن
- کمک به تیم توسعه برای خلق محصولات باارزش (محصولاتی هم راستا با اهداف و چشم‌انداز PO)
- درک و شناسایی موانع و مشکلات بازدارنده پیش روی تیم توسعه محصول و پیگیری وارجاع مشکلات به مدیران بالادستی در صورت نیاز (تلاش برای حذف موانع و مشکلات تیم توسعه)
- آموزش و مربیگری تیم‌ها در سازمانی‌هایی که اسکرام بهصورت کامل در آنها پذیرفته یا درک نشده است
ارتباط اسکرام مستر با سازمان
- آموزش و مربیگری سازمان در مسیر پذیرش اسکرام / طرح ریزیِ پیاده‌سازیهای اسکرام در سازمان
- کمک به کارمندان و ذینفعان برای درک و برگزاری عملی اسکرام و توسعه تجربی محصول؛
- همکاری با اسکرام مسترهای دیگر برای افزایش سودمندیِ کاربرد اسکرام در سازمان.
خارج از تعاریف رسمی و بر اساس تجربه:
در ابتدای این بخش توضیح داده شد که اسکرام مستر می‌تواند به عنوان یک نقش سازمانی و نه یک شغل تمام‌وقت نقش سازمانی یکی از اعضای تیم باشد. بهترین فردی که می‌تواند این نقش را در کنار وظایف خودش بر عهده بگیرد، یکی از developer های ارشد تیم است که بر مفاهیم اسکرام مسلط است. در شرایطی که ما یک تیم محصول رو به رشد هستیم اما هنوز آن قدر بزرگ نشدیم که نیاز به یک اسکرام مستر تمام وقت داشته باشیم، یکی از developer های ارشد تیم می‌تواند در کنار انجام تسک‌های روزانه‌اش، مدیریت تیم فنی و پروسه‌ی اسکرام را نیز بر عهده بگیرد و همچنین بخشی از زمان روزانه‌ی خود را به برگزاری جلسات اسکرام، آموزش اسکرام و مفاهیم مرتبط با چابکی به تیمهای مختلف درگیر در توسعه‌ی محصول بپردازد.
البته باید در نظر داشت که اسکرام مستر به عنوان یک شغل تمام‌وقت برای تیم های فنی بزرگ نیاز است. تیم‌هایی که از چند جهت با تیم فروش و مارکتینگ و تحقیق و توسعه درگیر هستند، نیازمند برگزاری چندین جلسه‌ی روزانه‌ی اسکرام با هر کدام از تیم ها و جلسات هفتگی بین تیمی هستند که این حجم از کار از عهده‌ی یکی از developer های ارشد تیم توسعه به عنوان یک کار جنبی، خارج است. همچنین یادداشت تسک های تعهدد داده شده، ورود آنها در بکلاگ، بررسی تسک‌های قبلی در جلسات اسکرام روزانه می‌تواند از کارهای اسکرام مستر باشد. اسکرام مستر در جلسات اسکرام روزانه می‌تواند به تنش‌ها و تضادهای درون تیمی نیز، پی برده و این موارد را با مالک محصول در میان بگذارد.
خوب من تا به اینجا با توضیح چهارچوب اسکرام، دو عنوان مالک محصول و اسکرام مستر را توضیح دادم. الان زمان خوبی است که عناوین بعدی: مدیر محصول و ارتباط‌اش با مدیر پروژه را نیز توضیح بدهم.
۳- مدیر محصول (در حوزه‌ی تکنولوژی) – Product Manager
در ابتدای این پست، تعریف چهارچوب اسکرام را بررسی کردیم اما خیلی روی این چهارچوب دقیق نشدیم. اما اینجا برای توضیح نقش مدیر محصول یک کم باید درباره تاریخ شکل‌گیری اسکرام و اجایل صحبت کنیم. در دهه‌ی ۱۹۹۰ سه تا چهارچوب معروف برای انجام پروژه‌های تکنولوژی محور شکل گرفتند:
در مقطعی موسسین این ۳ تا چهارچوب متوجه شدند که پیوسته برای کسب محبوبیت بشتر و جایگاه بالاتر در میان تیمهای فنی، باهم مشغول رقابت هستند. بنابراین با توجه به اینکه هدف اصلی همه‌ی آنها توسعه‌ی سریعتر و موثرتر محصولات بود، با هم یک قرار گذاشتند که درباره‌ی وضعیت و آینده‌ی ۳ تا چهارچوب صحبت کنند. از درون این جلسات، اصول و فصل مشترک هر ۳ چهارچوب تحت یک بیانیه به نام اجایل، مکتوب شد. از آن زمان به بعد کاربرد بیانیه‌ی اجایل در پروسه‌های توسعه‌ی محصولات تکنولوژی هر روز گسترش پیدا کرده است. سوال: این موضوع چه ربطی به مدیر محصول دارد؟
حقیقت اینجا‌است که عنوان شغلی مدیر محصول در سال‌های خیلی قبل‌تر از دهه‌ی ۱۹۹۰ ایجاد شده بود اما موسسین اسکرام در زمان تعاریف نقش‌های سازمانی اسکرام، به جای استفاده از عنوان شغلی مدیر محصول، نقش جدیدی به نام مالک محصول را ایجاد کردند که در عمل بسیار شبیه مدیر محصول بود اما شرح شغلی سبک‌تری نسبت به مدیر محصول داشت و تمرکز اصلی کارش روی ارتباط بین تیم فنی،مشتری و سهامداران بود. افراد زیادی عقیده‌دارند که مالک محصول + مدیر پروژه = مدیر محصول از همین جهت شرح شغلی عمومی مالک محصول و مدیر محصول (می‌دانیم که مدیر محصول شرح شغلی مرجع و استانداردی ندارد) بسیار به هم شبیه است. بنابراین اگر در توضیح نقش سازمانی مدیر محصول شباهت‌های زیادی با مالک محصول پیدا کردید، تعجب نکنید.
مدیر محصول چه کار میکند؟
همانطور که اسم مدیر محصول مشخص است، مدیر محصول مسئول موفقیت محصول است. چه چیزی محصول حساب میشود؟ یک اپلیکیشن، وبسایت و یا یک نرم‌افزار که مشتریان عمومی از آن می‌توانند استفاده کنند و یا یک نرم‌افزار درون سازمانی برای استفاده‌ی افراد یک سازمان و یا فیچر‌ها و توانایی‌های جدید برای یک محصولی که وجود دارد، همگی می‌توانند تعریف یک محصول باشند که نیاز به مدیر محصول دارد. وقتی می‌گوییم که مدیر محصول مسئول موفقیت محصول است، مشخص میکند که مدیر محصول نقش مهمی در سازمان دارد.
سوال: آیا این تعریف با تعریف مالک محصول (مسئولیت به حداکثر رساندن ارزش محصولی است که از کار تیم توسعه حاصل میشود) شباهت دارد؟ بله. تعریف هر دو عنوان شغلی بسیار شبیه است اما یک تفاوت ریز و مهم وجود دارد. در صورت وجود مدیر محصول، مالک محصول PO مسئول موفقیت محصول در سطح تیم توسعه است اما مدیر محصول، مسئول موفقیت محصول در تمامی سطوح است. اگر بازاریابی محصول، مارکتینگ و یا فروش محصول دچار مشکل شود، موفقیت محصول به خطر افتاده است و مسئول این ناکامی، مدیر محصول است و نه مالک محصول.
سوال: این حرف درست است که مدیر محصول بیشتر روی business کار تمرکز دارد و مالک محصول بیشتر روی بخش فنی؟ بله درست است. حتی در بسیاری از موارد توصیه میشود مدیر محصول از بکگراند بیزنس مرتبط با محصول آمده باشد اما دانش UX داشته باشد و با Tech آشنا باشد.
برای اینکه یک محصول موفق شود، از ابتدای مسیر تا بازنشستگی محصول (مرگ احتمالی محصول) چرخه‌ای به نام چرخه‌ی زندگی محصول (product Life cycle) تعریف شده است و به بیان ساده مدیر محصول مسئول اجرای درست مراحل مختلف این چرخه است. هرکدام از این مراحل به اشتباه اجرا شوند، رشد و توسعه‌ی محصول به درستی پیش نخواهد رفت. در این چرخه بخشی از کار در ارتباط با تیم توسعه است و بخش‌های دیگری نیز وجود دارد که به فروش، درآمدزایی محصول، قراردادها، مارکتینگ، توسعه و چشم انداز آینده‌ی محصول در ارتباط است که همه‌ی اینها وظایفی است که مدیر محصول دارد (در شرایط حضور یک مدیر محصول در شرکت، مالک محصول هیچ کدام از این وظایف را ندارد).
در زیر لیستی از وظایف اصلی یک مدیر محصول را که ستون‌های اصلی توسعه و تولید یک محصول است را می‌بینیم. سوال: آیا مدیر محصول وظایف دیگری نیز دارد؟ بله. هر مدیر محصول وظایف دیگری می‌تواند داشته باشد که بسته به سازمان و محصول، فرق میکند.
وظایف اصلی مدیر محصول:
مدیر محصول در ابتدای مسیر ایجاد یک محصول جدید، مسئولیت مرحله‌ی Research از چرخه‌ی زندگی محصول را بر عهده دارد. Research
=> Audio-size, Personaity, Possible Problems, Valu Added باید در نظر داشت که وقتی از تحقیق درباره یک ایده صحبت می‌کنیم و اینکه آیا این ایده شدنی هست یا خیر، به جز بررسی توانایی فنی، باقی موارد مرحله‌ی تحقیق، بخشی از کارهای مدیر محصول هستند که با شرح وظایف یک مدیر پروژه مشترک است.
مرحله‌ی بعد از تحقیقات اولیه، (Roadmap) برنامه ریزی Plan است. برنامه ریزی اینکه توسعه‌ی محصول چقدر زمان می‌خواهد، قرار است در مراحل اولیه روی چه فیچرهایی کار کنیم و این محصول قرار است در پایان اسپرینت‌‌های اول برنامه‌نویسی چه آوردی داشته باشد؟ (پاسخ سوالات چه چیزهایی – چه طور و چه زمانی) مرحله‌ی Plan نیز بخشی از کارهای مدیر محصول هستند که با شرح وظایف یک مدیر پروژه و یک مالک محصول مشترک است. در بالاتر توضیح دادم که build the right thing هم برای مدیر محصول و هم PO مشترک است. اگر در نظر داشته باشیم، بهتر است مرحله‌ی برنامه‌ریزی با مشورت و نظر مالک محصول (درصورت وجود) جلو رود.
مرحله‌ی بعد build و شروع ساختن مححصول است. اینجا،جایی است که مدیر محصول پیوسته با مالک محصول در ارتباط است. در واقع در صورت وجود مالک محصول،مدیر محصول مستقیم به تیم فنی تسک نمی‌دهد و خواسته‌ها و نظراتش را به مالک محصول می‌گوید تا او در بکلاگ اثر دهد. این مرحله شامل تست و اطمینان حاصل کردن از done شدن تسک‌ها نیز می‌باشد. (قبل‌تر اشاره کردم که وظیفه PO است)
مرحله‌ی چهارم لانچ و یا Release محصول است. این مرحله از آن جهت مهم هست که مشتری نهایی می‌تواند تغییرات و فیچرهای جدید را ببیند و از آنها استفاده کند. برای لانچ، مدیر محصول باید به سوالات مهمی مرتبط پاسخ دهد. سوالاتی مثل: آیا برای لانچ محصول استراتژی میخواهیم؟ چطور میخواهیم به مشتریان بلاقوه خود بگوییم که محصول جدید ما آماده است؟ از چه مدت قبل از لانچ خود را برای تبلیغات آماده کنیم؟ و از کدام روش‌های تبلیغاتی استفاده کنیم؟
مرحله‌ی پنجم Evaluate و ارزیابی موفقیت محصول تولید شده است. آیا مشتری به راحتی با آن ارتباط برقرار کرد؟ آیا تیم توسعه‌کار خودش را به درستی انجام داده است؟ یادمان باشد که وظیفه‌ی اصلی مدیر محصول، اطمینان از موفقیت محصول است و وقتی میتوانیم بگوییم یک محصول موفق شده است که مشتری از آن به راحتی استفاده کند و یا برای آن پول پرداخت کند.این مرحله نیز بخشی از کارهای مدیر محصول هستند که با شرح وظایف یک مدیر پروژه مشترک است.
مذاکره با سرمایه‌گذار و سهامداران: وظیفه‌ی مهم گفتگو با سرمایه‌گذاران فعلی و احتمالی و سهامداران در مورد وضعیت فعلی و آینده محصول بر عهده‌ی مدیر محصول است.
بررسی قوانین و مقررات اجرایی مرتبط به محصول: مدیر محصول باید حواسش باشد که اگر قواعد و استاندارهای مرتبط به دولت و یا سازمان‌های نظارت کننده بر محصول عوض شوند، شرایط توسعه و رشد محصول در آینده تغییر خواهد کرد. بنابراین همیشه باید تغییرات این موارد را در نظر داشته باشد. این مرحله نیز بخشی از کارهای مدیر محصول هستند که با شرح وظایف یک مدیر پروژه مشترک است.
هماهنگی بین تیمهای درگیر با محصول: مدیر محصول مستقیم با تیم UX، مالک محصول، سرپرست تیم فنی، مارکتینگ، فروش، business development، روابط عمومی، حقوقی، مدیران ارشد سازمان (سهامداران)، سرمایه‌گذاران و از همه مهمتر مشتری نهایی در ارتباط است. بنابراین توانایی گفتگو و ارتباط برقرار کردن برای مدیر محصول بسیار مهم است. در یک سازمان کوچک یک مدیر محصول به تنهایی می‌تواند همه‌ی ارتباطات لازم را مدیریت کند اما مدیریت یک محصول بزرگ به این سادگی نیست و گاهی لازم است برای ارتباط با هر کدام از این بخش‌های سازمان که با محصول مرتبط و درگیر هستند، یک مدیر محصول جداگانه‌ای اختصاص یابد (برای مثال marketing product manager). البته همانطور که بارها اشاره کردم این موارد بسته به شرایط محصول و بزرگی سازمان، متفاوت هستند.
آیا مدیر محصول یک مدیر ارشد سازمانی‌است؟
پاسخ این سوال بله است. اما باید در نظر داشته باشیم که با اینکه مدیر محصول کلمه‌ی مدیر را در عنوان شغلی خود دارد، تا حد زیادی نقش یک مدیر را که دیگران به او به عنوان مدیر ارشد، گزارش می‌دهند را بر عهده ندارد و یک Team Leader است. اشتباه برداشت نکنید: مدیر محصول مدیر ارشد محصول است. او رده‌ی سازمانی بالایی دارد ولی نوع کار او به شکلی است که با دستور دادن به افراد، پروسه‌ی توسعه‌ی محصول (حداقل یک محصول خوب) را نمی‌تواند جلو ببرد بلکه باید با مالک محصول (در صورت نبود مالک محصول مستقیم با خود تیم) در ارتباط باشد و با گفتگو با مالک محصول با درنظر گرفتن همه‌ی شرایط تصمیمات لازم را اتخاذ کند. اگر بخواهیم جایگاه مدیرمحصول را بر اساس چارت سازمانی بررسی کنیم، میتوانیم بگوییم در یک سازمان که همزمان یک مدیر محصول، مالک محصول PO، اسکرام مستر و مدیر پروژه بر روی یک پروژه کار میکنند، مدیر محصول نقش ارشد سازمانی آن محصول است.
شباهتها و تفاوت‌های مدیر محصول و مالک محصول
حقیقت اینجا است که همانطور که در بالا اشاره کردم این دو نقش سازمانی بسیار به هم شبیه هستند. در یک تیم کوچک یک مدیر محصول ( که هیچ نقش دیگری جز مدیر محصول بودن، نداشته باشد) می‌تواند علاوه بر وظایف مدیریت چرخه‌ی محصول، نقش مالک محصول (مدیریت بکلاگ) را نیز بر عهده داشته باشد. اینکه مرز هر عنوان شغلی کجا است، در دنیای واقعی در هر شرکتی متفاوت است. البته مرجع رسمی نیز به عنوان مرجع تعاریف دقیق مرز هر عنوان شغلی وجود ندارد. تنها در مورد مالک محصول به دلیل نقش سازمانی اسکرام ما تعاریف رسمی و دقیقی داریم. اما اگر در یک سازمان هم مدیر محصول و هم مالک محصول و یا هم مدیر پروژه و هم مدیر محصول داشته باشیم،دیگر تعریف رسمی مبنی بر مرز دقیق این نقش‌ها موجود نیست و نسبت به رویه و عملکرد سازمان می‌تواند مرزهای کاری و شرح شغلی عناوین بالا متفاوت باشند.
تفاوت‌ها
مدیر محصول یک Team Leader است. اما مالک محصول بر اساس تعریف استاندارد اسکرام، تیم را مستقیم مدیریت نمی‌کند و اسکرام مستر نقش Team Leader را دارد.
مالک محصول لازم نیست توانایی مذاکره و رهبری تیمهای مارکتینگ، فروش، business development، حقوقی و … را داشته باشد. در واقع تنها تیمی که مالک محصول به طور جدی با آنها در تماس است، تیمهای فنی و UX وسهام‌داران پروژه (در نبود مدیر محصول) است.
شباهتها
مالک محصول و مدیر محصول هر دو به نحوی مسئول موفقیت محصول هستند و در پروژه‌های کوچک میتوانیم تنها یا یک مالک محصول و یا یک مدیر محصول داشته باشیم.
در بسیاری از موارد هم مالک محصول و هم مدیر محصول با تیم فنی کار میکنند و در ارتباط مدام هستند. (البته درست این است که مدیر محصول هیچ وقت به طور مستقیم با تیم فنی در ارتباط نباشد، اما خوب گاهی روند‌ها به این شکل جلو نمی‌رود.) باید در نظر داشته باشیم که اگر راجع به یک سازمان بزرگ صحبت می‌کنیم،به احتمال زیاد مدیر محصول بیشتر مسئول استراتژی رشد محصول و ارتباط با همه‌ی تیمهای درگیر محصول مثل فروش، مارکتینگ، تحقیقات بازار، UX و … است. در حالیکه PO مدیریت بکلاگ و تیم فنی را دارد.
در تیمهای کوچک در صورت نبود مالک محصول در سازمان، مدیر محصول می‌تواند با بکلاگ کار کند و مدیریت بکلاگ را بر عهده بگیرد.
خارج از تعاریف رسمی و بر اساس تجربه:
ترکیب مالک محصول و مدیر محصول ترکیب خوبی است و در بسیاری از موارد به خوبی جواب داده است. خوب است که مدیریت بکلاگ و تیم توسعه را به مالک محصول بسپارید تا مدیر محصول زمان کافی برای مدیریت بیزنس و بخش‌های مختلف چرخه‌ی محصول داشته باشد.
شباهتها و تفاوت‌های مدیر محصول و مدیر پروژه
اما اگر به طور کلی بخواهیم تفاوت‌های این عناوین شغلی را بنویسم میتوانیم جدول زیر را به عنوان تفاوت‌های کلی مدیر محصول و مدیر پروژه بیان کنیم. در بالا توضیح دادم که مدیر محصول مسئول محصول است. اینکه محصول به درستی توسعه پیدا کند و مشتری نهایی از محصول راضی باشد. اما مدیر پروژه مسئول برنامه‌ریزی‌ها، منابع مالی، زمان‌بندی و گزارشات سازمانی است. اینکه محصول تا کجا توسعه یافته است، چقدر زمان باقی مانده است، کجای راه هستیم و چند درصد پروژه جلو رفته و چند درصد مانده است. اما واقعیت این است که در بسیاری از موارد در بخش بزرگی از سازمان‌ها مدیر محصول کار مدیر پروژه را نیز برعهده داره و تمامی برنامه‌ریزی‌ها و گزارش‌های سازمانی را همزمان با کنترل روند پیشرفت توسعه‌ی محصول، انجام میدهد.
به صورت تجربی در بسیاری از مواقع دیده‌ام که در بیشتر سازمان‌های حوزه‌ی تکنولوژی، ما نقش مدیر پروژه را نداریم و به جای آن مدیر محصول نقش مدیر پروژه را نیز بازی میکند. ممکن است بسته به بزرگی سازمان، یک مدیر محصول و یا تیمی از مدیران محصول داشته باشیم که مسئولیت بخش های مختلف محصول را بر عهده می‌گیرند. وقتی مدیر محصول عملا مدیر پروژه هم هست، مسئولیت‌های زیر را بر عهده دارد: تعریف محصول از ابتدا، تعریف roadmap، استراتژی لانچ، توسعه و رشد محصول و بررسی میزان پیشرفت پروژه.
شباهت‌های مدیر محصول و مدیر پروژه بسیار زیاد است و در بخش وظایف اصلی یک مدیر محصول به آن اشاره کرده‌ام بنابراین اینجا مجدد به آن نمی‌پردازم.
تفاوت‌ها
شاید مهمترین تفاوتی که بین این دو عنوان شغلی وجود دارد، بحث چرخه (cycle) بودن پروسه تولید محصول و خطی بودن مسیر یک پروژه است. در بسیاری از موارد پروسه‌ی توسعه‌ی یک محصول نرم‌افزاری، یک پروسه‌ی ادامه دار است که تا زمان رسیدن مرحله‌ی بازنشستگی محصول (مرگ محصول) در هیچ مقطع زمانی نمی‌توان گفت که دیگر تمام شده است. اما یک پروژه در یک زمان معین شروع و به پایان می‌رسد و یک پروسه‌ی ادامه دار نیست.
چگونه مدیر محصول شویم؟ (Product Manager’s typical background)
مهمترین سوالی که من درباره مدیر محصول بودن شنیدم این است که از کجا شروع کنم؟ و یا بهتر چگونه میشود یک مدیر محصول شد؟
بر خلاف بسیاری مشاغل، مانند عنوان شغلی مالک محصول، برای رسیدن به این شغل نیز تحصیلات آکادمیک خاص و یا مدرکی وجود ندارد و اگر خاطرتان باشد در مقدمه‌ی همین پست گفتم که ممکن است یک مدیر محصول در یک شرکت یک شرح وظایفی داشته باشد و در یک شرکت دیگر یک شرح وظایف دیگری. بنابراین گزینه‌ای به عنوان مهارت‌های مورد نیاز و یا شرح شغلی ثابت یک مدیر محصول در همه‌ی شرایط وجود ندارد. شما در یک شرکت به عنوان مدیر محصول نیاز دارید که تا حد خوبی به تکنولوژی‌های روز و زبان‌های برنامه‌نویسی تسلط داشته باشید و در یک شرکت دیگر با وجود یک مدیر محصول فنی (Technical Product Manager) اصلا از شما انتظار دانش فنی نمی‌رود ولی در عوض شما وقت بسیاری بین سهامداران و تیمهای فروش و مارکتینگ و تحقیقات سپری خواهید کرد.
آیا یک مدیر پروژه می‌تواند یک مدیر محصول شود؟ پاسخ این سوال، بله است. خبر خوب این است که شما به عنوان یک مدیر پروژه بخشی از تجربیات و دانش لازم (business) برای یک مدیر محصول بودن را دارید. اما باید بخش دیگری از دانش را که مرتبط به UX و خود فرایند توسعه و رشد محصول است را یاد بگیرید. بر اساس همه‌ی این مواردی که گفتم تنها راه حل ممکن که خودم نیز از همین راه مدیر محصول شدم، شروع کار در کسب و کارهای کوچک و کسب وتجربه در حوزه‌های بیزنس سرویس‌های آنلاین، UX و تا حدی Tech است. راه کوتاه‌تر و میان‌بری وجود ندارد.