تاریخچه مدیریت محصولات دیجیتال - مدیر محصول از کجا آمده و چجوری میتونه اجرا بشه

تاریخچه مدیریت محصولات دیجیتال - مدیر محصول از کجا آمده - مدیریت محصول چیست و چجوری میتونه اجرا بشه!

این متن در ۲۰۲۱/۱۱ نوشته شده است، قسمت‌های آخر آن در ۲۰۲۳/۰۳ ادیت و اصلاح شد.

مقدمه

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

حدودا چهار سال پیش (۲۰۱۷) که این نقش رو دیدم واسم جالب و عجیب بود، سعی کردم درباره حوزه اطلاعات بیشتری بگیرم که بهم گفتن برای یادگیری باید درس مهندسی نرم افزار ۱ رو بخونم و یک تخصصیه که خیلی بک گراند فنی میخواد. و خب من بخاطر محدود بودنش به ساید فنی از حوزه بدم اومد، ولی بعد که بیشتر شناختشم دیدم که کلا مدیریت محصول یه چیز دیگه هست، و به این حوزه علاقمند شدم. ( یکسری منابع رایگان مدیریت محصول رو اینجا معرفی کردم)

ماقبل تاریخ!

اگر بخوایم خیلی قدیمی مفاهیم محصول رو نگاه کنیم میشه اولین مدیر محصول رو به قرن ۹ یا ۱۰ میلادی نسبت داد که توی این مقاله بررسی شده، ولی بخاطر ماهیت بسیار متفاوت از آن چشم پوشی میکنیم.

اولین مدیر محصول ۱۹۳۱

مدیر محصول ابتدا از تولید محصولات فیزیکی شکل گرفت؛ آقای Neil H. McElroy از شرکت Procter & Gamble اولین شرح شغلی یک پوزیشن بنام Brand Man رو نوشت (زیر مجموعه دپارتمان مارکتینگ) که وظایف اون خیلی شبیه مدیر محصول بود، یک شخص خاص که مسئول تمام زوایای برند محصول باشه و مسئولیت شکست یا موفقیت محصول با اون هست.

عکس زیر شرایط شغلی برای اون پوزیشن هست.

طبق این شرح شغلی نقش "Brand Man" مسئول دنبال کردن فروش، مدیریت کردن محصول، تبلیغات و پروموشن‌ها بود. دو نکته‌ی جالب در این آگهی قسمت مسئولیت کامل این شخص نسبت به محصول و شناختن نزدیک بازار (از طریق تحقیقات میدانی) بود.

که بعدها این شرکت یک Associate Brand Man روهم کنار Brand Man استخدام کرد تا بتونه خودش رو با تغییرات سریع بازار همگام کنه.

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

دهه ۱۹۴۰ شرکت HP (Hewlett-Packard)

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

(منبع : لینک یک و لینک دو)

دهه ۱۹۵۰ و ۱۹۶۰ و ۱۹۷۰

دوران پس از جنگ ژاپن، جریان نقدینگی شرکتها رو مجبور کرد تا به just-in-time manufacturing یا just-in-time production روی بیارن؛ تولید در آن زمان و به اندازه کافی و کمینه کردن هدر رفت(waste)تا حد ممکن.

مدل تولید ناب تویوتا TPS در این برهه توسعه پیدا کرد که بر مبنای که دوتا اصل مهم بود و بعدها این اصول به دنیای مدیریت محصول نیز وارد شدند. یکی بهبود مداوم درحین تلاش برای نوآوری

Kaizen — continuously improving the business while driving innovation and evolution.

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

Genchi genbutsu — going back to the source to find the facts and make the right decisions. Genchi genbutsu translates into “go and see for yourself.”

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

همچنین کانبان که امروزه در تیم‌های توسعه نرم‌افزار بسیار محوبه نیز از سیستم مدیریت پروژه شرکت تویوتا برگرفته شده

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

درهه‌ی ۱۹۶۰ عصر تولید کالاهای فیزیکی جدید بود، برندها با یکدیگر رقابت شدیدی بر سر تولید کالای باکیفیت خوب و فروش بیشتر داشتند. در این زمان مشتری‌ها به سادگی میتونستند تفاوت کیفیت کالای خوب و بد رو تشخیص بدن و اگر کالای بی کیفیتی تولید میکردید مشتری‌ها آن را خریداری نمیکردند.

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

(تفاوت شرکتهای نسل Production-Oriented و نسل‌های بعدی در انتهای متن نوشته شده)

در این برهه Brand Manager جزو پوزیشن‌های اثر گذار یک شرکت بود و این شخص وظیفه‌ی مشخص کردن هویت محصول تولید شده و نقطه تمایز آن ار رقبا در بازار (پوزیشنینگ محصول) رو بر عهده داشت. برای اینکار نیاز بود اون بتونه بازار نهایی رو بخوبی بفهمه و بتونه به مشتری ارزش اصلی مناسبی از محصول (به اصطلاح "branded proposition") رو معرفی کنه. به نحوی که مشتری بتونه محصول رو با سایر رقبای بازار مقایسه کنه

ارائه کردن یک brand proposition مناسب میتونه با تغییر بسیار کم روی محصول اصلی، میزان سود زیادی رو در صورت موفقیت محصول به ارمغان بیاره، ولی برای اینکار نیاز بود که قیمت‌گذاری، تبلیغات، بسته بندی و پیام برند (brand messaging) بازآفرینی بشه و این جزو وظایف نقش مدیر برند یا مدیر محصول بود.

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

مدیریت محصول به مرور زمان در اکثر شرکتهای FMCG و تولیدی بیشتری پدیدار میشه و در دهه‌ی ۱۹۷۰ ورود خودش رو هم به دنبای تکنولوژی آغاز میکنه. در دنیای تکنولوژی بیشتر محصولات اولیه بسیار جدید و تقریبا بی‌رقیب بودند، بخاطر همین شرکتها نمیتونستند فقط به بسته‌بندی مناسب و پروموشن برای موفق شدن تکیه کنند. نیاز بود تا علاوه بر فهم نیازهای مخاطب این مورد با چرخه‌ی عمر محصول نیز در یک راستا باشه و به ارتباط توسعه‌ی محصول با سایر قسمتهای ذکر شده توجه بیشتری بشه همین دلیل نقش مدیریت محصول به فرایند توسعه نزدیک‌تر شد.

حتی تا امروز هم مرزهای مارکتینگ و مدیریت محصول همپوشانی بسیاری باهمدیگه دارن، اما دپارتمان مارکتینگ بیشتر روی آگاهی برند و جذب مشتری توجه میکنه و تیم محصول مسئولیت مراقبت از ارزش پیشنهادی و توسعه محصول رو داره.

(البته در مقالات ۲۰۲۱ مارکتینگی کانسپت مدیریت محصول در کانستپ مارکتینگ وجود داره (و نه فنی) به دلیل ریشه در کشف کردن نیاز مخاطب از ذهن مشتری) (نقل قول از صحبت با جناب اقای امیر اعرابی پور)

در دهه‌ی ۱۹۸۰ و ۱۹۹۰ نیز مدیریت محصول شرکتهای تِک از مدیریت محصول در صنایع FMCG و کالاهای فیزیکی بسیار جوان‌تر بود ولی شرکتها به مرور این نقش رو ایجاد کردند تا مشتری محور تر باشند.

در ایران

در سال ۲۰۰۶ شرکت کاله نقش مدیر محصول رو با مشاهده‌ی موفقیت این نقش در خارج ایران به خود اضافه کرد، و مدیر محصول زیر مجموعه‌ی قسمت مارکتینگ بوده.

شرکت ایرانسل سال ۲۰۰۶ نقش CPO و دپارتمان محصول داشته، و مدیر پروژه مدیر مستقیم مدیر محصول بوده و بعد مدیر پروژه نیازمندی‌های محصولی رو از مدیر محصول گرفته و پس از بازبینی و اعمال تغییرات به تیم آی‌تی تحویل میداده. (اون زمان هنوز از اجایل استفاده نمیکردند)

همکاران سیستم هم جزو اولین شرکتهای ایرانی سال ۲۰۰۵ واحد مستقل مديريت محصول رو ايجاد كرد؛ جالبه كه این قسمت زير مجموعه ماركتينگ نبود و بيشتر به سمت مشتری و بازار و ارتباط با توليد و توسعه نرم افزارها بود يعنی دقيقا واحدی بود كه بين مشتريان و كارشناسان مرتبط با مشتريان از يک طرف و از طرف ديگه تيم های توسعه و توليد نرم افزار قرار می گرفت. اما بخشی از فعاليت هاش مرتبط با ماركتينگ بود و در واقع به واحد بازاريابی و فروش خدماتی ارائه می داد و خصوصا در تهيه محتواهايی مثل بروشورها و محتواهای تبليغاتی به بازاريابی كمک میكرد و هنوز از اجایل استفاده نمیشده.
(منبع: گفت و گو با مدیر محصولهای اسبق این دو شرکت - سیامک خرمی اولین مدیر محصول کاله و مدیر محصول اسبق ایرانسل - آقای احمد اصلاح اولین مدیر محصولهای همکاران سیستم)

.
.

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

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

مدل تولید ناب تویوتا در سالهای ۱۹۴۸ تا ۱۹۷۵ نیز مفاهیم و شرح وظایف مدیر محصول رو مقداری تغییر داد. و ریشه‌یابی عمیق مشکلات، مشاهده مستقیم مشتری، و بهبود و نوآوری مداوم رو به مدیریت محصول اضافه کرد.

سال ۱۹۹۰ و ۲۰۰۱ اسکرام

به مرور شرکتهای زیادی با هدف مشتری-محور شدن نقش مدیریت محصول رو در خودشون جدی‌تر دنبال کردند و پوزیشن مدیر محصول رو ایجاد کردند، شرکت Intuit به صورت جدی این اغدام رو شروع کرد و بعد مایکروسافت و باقی شرکتها نیز اون رو دنبال کردند. (البته مایکروسافت بجای مدیر محصول نقش Program Management رو داره که خیلی شبیه نقش مدیر محصول هست) دلیل اصلی اضافه شدن اینبود که شرکتها فهمیدن مهندس‌ها به تنهایی نمیتونن نیازمندیهای کاربر رو به خوبی متوجه شده و خواسته‌های کاربران رو دلیور کنند، نقش مدیر محصول ایجاد شد تا فضای خالی ارتباطی میان مشتری - مارکیتنگ - فروش و تیم توسعه فنی رو پر کنه.

(ادیت دوم: البته بعد تر فهمیدم نحوه درست اجرا کردن پر کردن این نقش هزاران نکته پنهان داره و جنگ دیرینه تک لید و مدیر محصول و اسکرام مستر و گاهی مارکتینگ از اینجا شروع میشه? )

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

ولی این نقش دچار چند تغییر شد، و جریاناتی مختلف همزمان رخ میدادند، یکبار تغییرات در نقش مدیر محصول پس از استفاده از ایکس‌پی (دهه ۱۹۹۰) و سپس بعداز معرفی شدن اسکرام و بیانیه چابک (مانیفستو اجایل) (سال۲۰۰۱) بود که شرح شغلی‌ها رو مقداری منعطف میکرد.

تا اینجا در تیم‌های نرم‌افزاری اگر مدیر محصول نداشتیم، افرادی نظیر مدیر پروژه در متدولوژی آبشاری - تحلیلگر کسب و کار و برخی اوقات افراد مارکتینگی به صورت پراکنده نقش مدیر محصول رو ایفا میکردند، درواقع نقش مدیر محصول به صورت پراکنده توسط تیمهای مختلف اجرا میشده و همین باعث میشده بینش تصمیم‌گیری ها ضعیف بشه

(توضیحات برای درک بهتر مخاطب مبدتی: یجورایی مثل یک کلاغ چهل کلاغ! نیاز مشتری توی یک فرایند بسیار طولانی این نیازمندی از مارکتینگ و بیزنس و تیم مدیریت و دیزاین و فنی اینقدر جابجا و اصلاح میشده که عملا وقتی به مقام اجرا میرسیده با نیازمندی اصلی مشتری تفاوت بسیاری داشته. و خب گاهی شاید هر دپارتمان هم مسئول موفقیت فرایند بودن هیچکس مسئول موفقیت محصول نبوده. هر کسی فقط واسش مهم بوده قسمت خودش انجام بشه و در نهایت خواسته مشتری کمتر دیده میشده این توی محصولات B2C خیلی ضرر زیادتری میزنه)

به صورت همزمان که مدیریت محصول تکامل پیدا میکرد، پس از بیانیه چابک و استفاده از متدولوژی اسکرام خیلی از تیمهای فنی توسعه نرم افزار به مرور زمان به اسکرام روی آوردن و توی اسکرام نقشی داریم تحت عنوان مالک محصول (Product Owner) که مسئولیت دلیوری و رساندن محصول با وی هست، و خب این مالک محصول با چیزی که مدیر محصول تا اینجا معرفی کردیم فرق‌هایی داره و مسئولیت وی زیر مجموعه کارهای مدیر محصول هست. (لینک منبع)

(ادیت دوم: البته دوتا دیدگاه کلی رو پیدا کردم یکی مالک محصول رو مشابه شکل توصیف میکنند و کارهای اون رو یک لول قبل‌تر از مدیر محصول میبینند و دیدگاه دیگر رو آقای رومان پیچلر به در این لینک انجا توضیح داده. که میگه منظور مالک محصول اشتباه رسونده شده اینکه بگیم مالک محصول کاری به ویژن و رودمپ و استراتژی نداره اشتباه هست و درک اشتباهی بوده که بخاطر شباهت مالک محصول در SAFe ما اومدیم به کل مالک محصولها تعمیم دادیم و ایشون نقش مدیر محصول و مالک محصول رو یکسان میدونه)

البته توی بعضی از دیدگاه‌ ها مثل جناب مارتی کیگان (با کتاب inspired میشناسیمش) میگفتند یک نقش داریم به اسم Product Owner/Manager و برخی دیگر از بزرگان پروداکتی نیز نظرات متفاوتی دارند. (البته اقای کیگن یه پدر کشتگی با Product Owner ها هم داره ?)

در دیدگاهی که این دو نقش جدا باشند، مالک محصول مسئول ۲ یا ۳ دایره‌ی اول هست.

ولی مدیر محصول مسئول دایره های ۳ و ۴ و ۵ می‌باشد. (اطلاعات بیشتر درباره تفاوت نقش مالک محصول و مدیر محصول در مقاله‌ی اقای شروین مشایخ https://vrgl.ir/gHI9B و درباره اسکرام و نقش مدیر پروژه در مقاله خانم نیکنام https://vrgl.ir/94KnA )

مالک محصول تمرکز بر Product Delivery (رساندن محصول درست و به موقع) دارد و مدیر محصول تمرکز بر Strategy & Discovery (کشف محصول درست و آینده‌ی محصول) دارد.

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

مفهوم توزیع شدن یک نقش

پس از اجایل در تیمها توسعه نرم افزاری نیز به مرور زمان نگرش و نقشها تغییر کرد برای مثال نقش مدیر پروژه در اسکرام وجود نداره (البته بعضی جاها هنوز مدیر پروژه در سازمان وجود داره و توی این مورد اختلاف نظرهایی وجود داره. در نبود این نقش مسئولیت وی بین تیم توزیع میشه) یا گاهی نقش تحلیلگر کسب و کار (business analyst) از بعضی تیمها حذف شده و کار اون بین باقی رولها توزیع شده یا رول جدید بوجود اومده.

توزیع شده یعنی این نقش رو بجای اینکه یکی انجام بده بین چند نفر تقسیم میشه. بیاید نقش مدیر پروژه رو مثال بزنم و ما این نقش رو حذف کنیم! ولی با حذف کردنش احتمالا دچار مشکل میشیم بخاطر همین باید کارهایی که میکرده (شرح شغلی اش) رو شفاف کنیم و بین اعضای تیم تقسیم کنیم. (جهت سادگی متن بعضی جاها از دقت علمی متن کاسته شده)

برای مثال یکی از کارهای مدیر پروژه نظم دادن به تیم میتونه باشه که اسکرام بجاش اومده خودسازمانده بودن (self-organize) رو در تیم توسعه محصول اسکرام باب کرده. (قبلا مدیریت پروژه نظم یا سازماندهی رو میاورده ولی اسکرام میگه تک تک افراد باید سعی کنند این خودسازمان دهی فردی رو تقویت کنند.)

یک مثال دیگه در فرهنگ سازی ارزشهای اجایل ما مدیر پروژه نداریم ولی بعضی کارهاشو اسکرام مستر انجام میده مثلا اینکه روند سرعت کار رو ببینیم اسکرام مستر انجامش میده (اسکرام مستر به کمک burndown chart) و مدیر پروژه نداریم ولی مدیریت لیست کارها یا مدیریت بکلاگ با مالک محصول هست. باقی قسمتهای شرح شغلی مدیر پروژه نیز به تبع همین مدل بین افراد مختلف پخش میشه (یا ممکنه دیگه بهشون نیازی نداشته باشیم) (این یک مثال از توزیع شدن نقش بود درکل مدل توزیع ممکنه فرق کنه این صرفا یک مثال بود. توی رویکردهای جدید تر گاهی یک نقش حذف میشه و شرح شغلی اون به باقی رولها توزیع میشه! گاهی هم ممکنه برای بهتر انجام شدن یک فرایند یا نتیجه گیری بهتر یک نقش جدید بوجود بیاریم. مثل خود نقش مدیر محصول! یا تحلیلگر محصول یا نگقش Product Ops )

تا اینجا با مفهوم توزیع شدن یک نقش هم اشنا شدیم و دیدیم با تغییر کردن ذهنیت گاهی نیازه نقشهای جدید تغییر کنند یا از بین رفته و بین تیم توزیع بشن.

اما از دید کلان تغییراتی که اسکرام به نقش مدیر محصول اضافه کرد (در سازمانهای نرم افزاریی که قبل از اسکرام نیز مدیر محصول داشتند) بهبود فرایند رساندن محصول (Product Delivery) و وارد کردن مدیر محصول توی دلیوری محصول بود. (اگر مدیر محصول در ارتباط با برنامه نویسها و product delivery درگیر بشه درواقع نقش مالک محصول اسکرام روهم داره ایفا میکنه. اگر ایکس‌پی یا کانبان استفاده کنیم نیز بحث تفاوت دارد.)

بعنوان مثال اگر قبل از ورود اجایل به یک سازمان مدیر محصول یک Product Specification صد صفحه ای مینوشت میداد به واحد بالاسری (مثلا مدیریت پروژه) و بعد مدیر پروژه بعد از بررسی اون رو میداد به واحد توسعه محصول (آی‌تی)، واحد توسعه محصول، زمانی که فیچر توسعه داده میشد یعنی اولین بار مدیر محصول اون رو نوشته بود تا زمانی که مدیر محصول میتونست خروجی اون رو ببینه شاید بین شیش ماه الی دو سال طول میکشد، که بعد بتونه مدیر محصول فیدبک بگیره. ولی بعد از ورود اجایل این زمان به کمتر از یک ماه (یک الی چهار هفته در اسکرام) رسید.

خدمتهای اجایل به مدیریت محصول:

• فیدبک گیری اولیه محصول و تسریع فرایند ولیدیشن
• کاهش زمان ورود محصول به بازار
• تطبیق بهتر محصول با نیاز بازار
• درک بهتر از نیازمندی‌های محصول
• فرایند توسعه شفاف
• افزایش انگیزه (motivate) و تیمهای پربازده‌تر

چالش‌هایی موقع استفاده از اجایل:

• عدم توانمندسازی تیم‌ها (مدیر مصحول و تیم توسعه سطح توانایی و اختیارات شون کم شده)
• نقش‌های گیج کننده (شرح کاری نقش اسکرام مستر و مالک محصول گیج کننده و گاهی مبهم هست)
• عدم تعامل کافی با کاربران
• نبود هیچ دستور العمل و بی توجه‌ای به پروداکت دیسکاوری و پروداکت استراتژی

(منبع مقاله رومان پیچلر)

لین استارتاپ ۲۰۱۰ و Product Discovery و تفکر طراحی

به مرور زمان نقش مدیر محصول تکامل پیدا کرد، و حتی از صنایع FMGC و تولید کالاهای فیزیکی نیز پیشی گرفت، در گذشته یکبار مدل مدیریت محصول از تولید ناب تویوتا الهام گرفته بود، یکبار هم مدیریت محصول با مانیفستو اجایل تغییراتی کرد. اریک ریس با معرفی کتاب نوپای ناب (لین استارتاپ) و سپس جنبش ناب، (که جالب اینه خود اونم از مدل تویوتا الهام گرفته شده بود) یکسری مفاهیم جدید وارد دنیای مدیریت محصول کردند، با افزایش no code tools و افزایش بیشتر اهمیت تجربه کاربری ورود تفکر طراحی به مدیریت محصول نیز تغییراتی روی پروسه کاری برخی از تیمها داد. (قسمت no code توی مدیریت محصول سازمانی تغییرات زیادی نداد ولی تفکر طراحی پروسه‌ی برخی تیمها رو بروزرسانی کرد)

چیزی که لین استارتاپ به مدیریت محصول اضافه کرد نگرش Validation و Learning بود که از اصول این ابزار قوی‌ای مثل A/B testing و ابزارهای دیگه هم وارد مدیریت محصول شد.

تغییری که این نگرش در اجایل داشت اضافه کردن دیسکاوری به اجایل (یا اسکرام) بود، مانند اضافه شردن یک حلقه‌ی یادگیری و معرفی متدولوژی Dual Track Agile، درواقع قبل از اون (یا حتی همین الان در برخی شرکتها در ایران) متدولوژی اسکرام افراطی استفاده میشه ولی به قول ملیسا پری

Agile or Scrum Doesnt have a Brain!

اینکه آیتمهای بکلاگ دقیقا از کجا بیان و قبل از اومدن چه اتفاق هایی باید براشون بیوفته (نظیر ولیدیشن و اومدن از دیسکاوری) چیزی هست که اسکرام درباره اون سکوت کرده.

تغییرات اخیر (کمتر از ۵ سال گذشته تا ۲۰۲۱) در مدیریت محصول اضافه شدن continuous discovery method به فرایند توسعه بود.

و آخرین متدولوژی ای نویسنده متن دیده استفاده بشه ترکیبی از تفکر طراحی همراه ولیدیشن و اندازه گیری لین استارتاپ و سپس اسکرام هست.

(ادیت جدید: البته چیزی که الان دیدم پرکتیس‌های زیادی وجود دارند که متناسب با ذات محصول و سازمان میتونیم به فرایند مون اضافه کنیم و شاید فقط اگر دقت کنیم چند جزء اصلی رعایت بشوند کافی باشه.)

که در این متد ابتدا یکسری ایده‌ها و پیشنهادات توسعه‌های مختلف برای محصول رو داریم که از استکهولدرهای مختلف بعلاوه نظرات مختلف اومده، هر کدوم از این پیشنهادات باید در راستای یک نیاز مشتری (یا هدف بیزنس) باشند. ابتدا فضای مسئله رو درک میکنیم و با مشتری همدلی صورت گرفته (سعی میکنیم درکش کنیم ببینیم مشکلش چیه) و سپس مسئله‌های مشتری رو به صورت واضح تعریف کنیم. احتمالا یکسری راهکار ایده هارو واسشون یک راه حل طراحی میکنیم و سعی میکنیم ساده ترین پروتوتایپ (minimum viable prototype) راه حل رو تست کنیم یا اون رو اعتبار سنجی کنیم، اگر اعتبار سنجی اولیه مثبت بود سعی میکنیم با کمترین میزان بار فنی یک نمونه کوچک از نیاز مشتری رو توسعه بدیم (minimum viable product) و پس از مثبت بودن به صورت iterative نتیجه آزمایش کل فیچر رو توسعه بدیم.

یک مثال از این پروسه

مثلا فرض کنید ما مدیر محصول یک سیستم مدیریت درسی دانشگاهی هستیم که قسمت مدیریت نمرات درس دانشجوها برای اساتید دانشگاه رو داره. و از طرف مدیر عامل شرکتمون اعلام شده کاربر نیاز داره نمرات رو بتونه انلاین ادیت و مرتب سازی کنه چنین فیچری رو توسعه بدید. (این فقط یک پیشنهاده! باید اعتبار سنجی بشه). ابتدا این نیاز رو توی مصاحبه عمیق با کاربر ارزیابی میکنیم، ببینیم غیر مستقیم چنین چیزی میگه یا اصلا حس کرده نیاز داره ادیت یا مرتب بسازی کنه. (یا یکم دقیق تر بگم سعی میکنیم ببینیم این راهکاری که گفتن داره سعی میکنه چه دردی رو حل کنه، آیا اصلا دردی وجود داره؟) اگر جواب مثبت بود. سعی میکنیم راه حل پیدا کنیم. و راه حل مونو با راحت ترین روش ممکن تست کنیم مثلا یه دکمه و قابلیت دانلود خروجی اکسل از نمرات رو توسعه میدیم (که شاید ۳ استوری پوینت بشه و چند ساعته قابل توسعه باشه). سپس سعی میکنیم به نحوی معیار موفقیت فیچر رو اندازه بگیریم مثلا روی دکمه دانلود ایونت ست میکنیم (با پندو /امپلیتود یا تگ منیجیر) و سپس میبینیم کلا چند نفر روی دانلود کلیک کردن! (میتونیم مثلا نسبت افرادی که به صفحه اومدن به نسبت کلیک رو حساب کنیم) و بعد اگر از این فیچر استفاده میشد و با پیش بینی مون منطبق بود میایم باقی اون رو به صورت کامل (که ممکنه چندماه وقت بگیره) مثلا ۴۰۰ استوری پوینت توسعه میدیم. (البته ممکنه ابتدا گزینه دانلود بذاریم - بعد یه حداقل پنل بدیم بعد پنل حرفه ای تر و تعداد iteration هامون بیشتر باشه)

همچنین میشه فرایند اعتبار سنجی رو بسته به بودجه - ظرفیت - حساسیت موضوع و اسکیل تیم یا پروداکت بسیار طولانی تر یا کوتاه تر نمود. ولی کلیت هدف ما اینه که هرچیزی رو توسعه ندیم و مطمئن بشیم چیز درستی توسعه میدیم و معیار موفقیت برای ارزیابی اون داشته باشیم.

اگر بیایم این پروسه رو به صورت یک پایپلاین در بیاریم به شکل زیر میرسیم:

لینک عکس باکیفیت جهت زوم کردن : link

دلیل تکامل یافتن به سوی این فریمورک، بخاطر پیچیدگی بالای محصولات نرم افزاری هست که گاها چیزی توسعه میدیم که کسی استفاده نمیکنه! طبق ریسرچ شرکت پندو روی حدود ۱۵۰۰ محصول آمریکایی با بیش از ۲۲ میلیون کاربر ۸۰ درصد فیچرهایی توسعه داده شده میشوند حتی یکبار هم استفاده نمیشوند یا به ندرت استفاده میشوند، با عدم توسعه این فیچرها میتوانستیم از هدر رفتن مبلغ ۲۹.۵ میلیارد دلار جلوگیری کنیم. به همین دلیل در گذشته فیچرهای بلااستفاده‌ی زیادی توسعه می‌یافتند، و علاوه بر هدر دادن بودجه به دلیل شلوغ شدن محصول کاربردپذیری آن نیز کاهش می‌یافت. اگر مدیر محصول قبل از ارائه‌ی آیتمها به تیم توسعه آنهارا بخوبی اعتبارسنجی کند تیم توسعه با تعداد توسعه‌دهنده کمتر می‌تواند بازدهی بهتری داشته باشد، درواقع هم هزینه‌ی کمتر و هم خروجی بهتر. به نقل از پروداکت اسکول در یک محاسبه سر انگشتی قبلا در دنیا به ازای هر مدیر محصول ده نفر توسعه دهنده داشتیم و الان به ازای هر مدیر محصول پنج نفر توسعه دهنده داریم!

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

(قسمت زرد محدوده تیم محصول - فلش قرمز تعامل داخلی - فلش سفید تعامل خارجی و دپارتمانی)

(لینک باکیفیت‌تر عکس جهت زوم کردن)

یک نکته درباره بازار ایران

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

در بازار کاری ایران در همین لحظه (۲۰۲۱/۱۱) تعداد فرصتهای شغلی برای مالک محصول از مدیر محصول بیشتر می‌باشد! تعداد زیادی شرکت هستند که نقش مالک محصول (یا حتی مدیر محصول رو) همون مدیر پروژه در واترفال میدانند که با مهاجرت از متد آبشاری به چابک (اجایل) که اغلب تیمها اسکرام روهم استفاده میکنند نیاز به یک نفر دارند که ناظر بر فرآیند توسعه محصول (product delivery) باشد و این مورد تنها زیر مجموعه ای از نقش مدیر محصول می‌باشد، و شخصی که در اینگونه پوزیشن مدیر محصولی مشغول به کار هست هم خود رشد نکرده و هم سازمان بسیاری از بازدهی و کارایی نسل جدیدتر توسعه محصول را از دست میدهد.

(ادیت جدید: خوشبختانه در تاریخ ۲۰۲۳/۰۳ اوضاع بهتر شده :) ولی کارجویان گرامی مراقب باشید شرکتی دیدید که بجای مدیر محصول، یک مدیر پروژه میخواستند سمتش نرفته و فرار کنید!)

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

تغییرات جهت‌گیری شرکتها

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

جهت گیری سازمانها تا الان چهار نسل رو مشاهده کرده است به ترتیب:

Production-Oriented, Sales-Oriented, Marketing-Oriented, Customer-Oriented

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

در نسل بعدی تیم فروش اهمیت بیشتری پیدا کرده و فروختن محصولات اهمیت پیدا میکرد، برای مثال در مدل سازمانی و B2B ابتدا سازمانها سعی میکردن یک محصول رو بفروشن! و بعد اون رو تولید میکردند.

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

و در اخرین مدل مفهوم رو میریم از ذهن مشتری پیدا میکنیم چیزهایی که الان در ذهنش میگذره یا حتی الان هم بهش فکر نمیکنه و در آینده ممکنه بهش نیاز پیدا کنه رو کشف کنیم. بازارش رو خلق کنیم و بعد تولید کنیم. (یا بفروشیم و سپس تولید کنیم)

برای مثال اگر دهه های قبل تر رو به یاد بیاریم برای یک کالا مثل کفش، تولید مشکل اصلی بود. کمبود مواد اولیه، غیر بهینه بودن خط تولید و در نهایت با کمبود کالا، پدر بزرگهای ما یک مدل کفش رو به سایز بزرگتر از اندازه فعلی میخریدن و بعد پشت اون پارچه میذاشتیم تا بتونیم توی پا استفاده کنیم! یک کالا به مقدار محدود تولید میشد و چالش اصلی بهینه سازی خط تولید و تولیدات بیشتر بود. کالاها مدل های مختلفی نداشتن چند مدل محدود مدل کفش یا کلاه داشتیم، (نسل اول) ولی اگر همین الان نگاه کنیم کفش فوتبال، کفش دویدن، کفش مهمونی، کفش مهمونی پاشنه بند، کفش مجلسی، کفشی با قابلیت افزایش و کاهش سایز و غیره متناسب و سفارشی سازی شده با استفاده و نیاز تخصصی که از نشانه‌های نسل سوم، تخصصی شدن نیاز هست.

البته معنی این نسل جهت‌گیری‌ها این نیست که اگر نسل چهارم باشیم حالت مطلوبی هست، در برخی سازمان‌ها فعالیت به گونه‌ی دیگری هست. برای مثال یک کارخانه‌ی تولید گوشت بدنبال بیشتر کردن تولیداتش هست (نسل اول)، یک شرکت تولید کاغذ که خط تولیدی بهینه دارد مسئله‌ی اصلی برای وی در فروختن بیشتر هست (نسل دوم)، سازمانی که محصولاتش با تغییر سلیقه‌ی مخاطب تغییر میکنند یا بازار جدیدی را هدف گرفته مانند یک شرکت حوزه صرافی ارز رمز نیاز به تمرکز روی مارکتینگ دارد(نسل سوم)، و شرکت نرم‌افزاری‌ای که در بازار به شدت رقابتی برای آینده خلق میکند نیاز به نسل آخر دارد، مانند فیسبوک و تسلا.

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

از دلایل تغییر در جهت گیری شرکتها میتوان به disruptive technology اشاره کرد، در گذشته قدرت سمت شرکتها بوده و شرکتها تقریبا هر کالایی که تولید میکردند مردم مجبور به استفاده بودند. با کاهش هزینه‌ی کارآفرینی و تغییر تکنولوژی‌های جدید، قدرتی که دست شرکتهای بزرگ بوده با شرکتهای کوچکتر توزیع شده و این باعث شکل گیری تنوع در بازار و تغییر قدرت به سمت مشتری شده است.

مهارت‌های مدیر محصول ۲۰۲۰

تا اینجا با گذشته و تغییرات نقش مدیر محصول دیجیتال آشنا شدیم! بعنوان حسن ختام مهارت‌های مورد نیاز یک مدیر محصول رو باهم مرور میکنیم.

طبق فریمورک آقای Ravi Mehta (مدیر اسبق ارشد محصول تیندر و فیسبوک) مهارت های مدیر محصول رو میشه چهار قسمت کرد.

مهارت‌های دلیوری مدیر محصول (آشنایی با فریمورک‌های توسعه نرم‌افزار نظیر اسکرام و کانبان - آشنایی با تست کارایی و کنترل کیفیت نرم‌افزار - توانایی تفکر سیستمی و درآوردن دیتل فیچرها)

مهارت‌های نرم و اثر گذاری محیطی یک مدیر محصول (تعامل مناسب با استکهولدرها - رهبری تیم همراه با حفظ انگیزه - کمک به رشد و لول آپ تیم و فشار آوردن کافی و درست به مدیر ارشد برای رسیدن به هدفها)

مهارت‌های بینشی مدیر محصول (توانایی کار با داده و تحلیل اون - شناخت عمیق از نیاز مخاطب و مهارت یوزر ریسرچ - آشنایی با پروسه طراحی تجربه‌کاربری محصول برای تعامل با دیزاینر)

مهارت‌های استراتژی مدیر محصول (توانایی رسوندن تیم به هدف های معنادار - توانایی قراردادن هدف مناسب برای محصول و ساخت رودمپ بر اساس اولویت‌های کلان - شناخت از اثرگذار استراتژیک فیچرهای محصول )

لینک مقاله‌ی کامل

درد و دل

امیدوارم این متن واستون مفید بوده باشه، جمع‌آوری اطلاعات مختلف، ترجمه، خلاصه سازی و در نهایت نوشتن و ویرایش این مقاله‌ی ۱۸ دقیقه ای حدود ۱۸ ساعت از من زمان برد!

هدف اصلی از نوشتن این متن اینبود که هم اکنون در خیلی از شرکت‌های نرم‌افزاری ایران، دپارتمان محصول وجود ندارد و مدیر محصول زیر مجموعه دپارتمان فنی بوده و CTO مدیر ارشد وی محسوب می‌گردد، معمولا در این ساختارها انتظارات از یک مدیر محصول، خیلی شبیه شرح کارهای یک مدیر پروژه برای تیم فنی هست، (بدونه توجه به ولیدیشن و حتی نتایج فیچرها) و خب توی این متاسفانه هم مدیرمحصولهای جوان شرکت درجا میزنن و اگر شرکت در بازار رقابتی فعالیت کند که محصول به تغییرات بازار حساس باشد احتمال عقب موندن از رقبا را دارد. درواقع شرکت کلی هزینه صرف توسعه‌ی چیزهایی می‌کند که قرار نیست توسط کاربران استفاده شوند! امیدوارم این متن بعنوان گام کوچکی برای آگاه سازی مدیران ارشد سازمان و مدیران منابع انسانی و افراد جوان در حوزه محصول درباره نقش مدیر محصول، البته این مشکل فقط مخصوص ایران نیست و در بیزنس‌های آمریکایی نیز وجود دارد، به امید اینکه رویای یک مدیر محصول جوان دیگر در یک مسیر اشبتاهی تلف نگردد. و از طرفی بعنوان سازمان سرمایه رو روی ساخت محصولات اشتباهی هدر ندهیم.

بزودی یک مقاله دیگه در رابطه با معرفی منابع مدیریت محصول خواهم نوشت اگر میخواهید اونو از دست ندید پیشنهاد میکنم لینکدین من روهم دنبال کنید. www.linkedin.com/in/nihilof

>>> دوست داشتید مقاله روهم لطفا لایک کنید یا کامنت و یا توی گروه های واتساپی/ تلگرامی تون به اشتراک بذارید. من از این طریق فیدبک میگیرم میفهمم خونده شده و مفید بوده! و خب مقالات بیشتری میگذارم!

تشکر و منابع

لازمه تشکر کنم از آقای دانیال معظم و احمد صلاح عزیز بابت بازبینی علمی متن

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

منابع:
گفت و گو با سیامک خرمی (مدیر محصول اسبق کاله و ایرانسل و مدیر محصول سنیور آمازون) - گفت و گو با احمد اصلاح (رهبر ارشد محصول در همکاران سیستم) - آقای امیر اعرابی پور (COO شاتل و مدیر ارشد اسبق همکاران سیستم) - سایت toolkit4pm - مقاله رومان پیچلر و مقالات زیر

• https://medium.com/agileinsider/the-history-and-evolution-of-product-management-part-1-23cb7a858f05 (three parts)
• https://productfolio.com/history-of-product-management/
• https://www.mvpfactory.co/blog/a-short-history-of-product-management
• https://productschool.com/blog/product-management-2/product-management-90s-vs-2020/
• https://www.encyclopedia.com/economics/encyclopedias-almanacs-transcripts-and-maps/product-management
• https://www.oreilly.com/radar/the-evolving-role-of-product-management/
• https://www.ravi-mehta.com/product-manager-roles/