هماهنگی تیم‌های مارکتینگ و محصول

سوال: به‌ نظر شما در یک ساختار functional (تیم‌های فرانت اند – بک اند – تست – دیزاین – محصول + مارکتینگ) از یکدیگر جدا هستند چگونه می‌توانیم تیم‌های مختلف رو در بحث roadmap و استراتژی با یکدیگر همگام (sync & align) کنیم؟

پ.ن(بله می‌دونم عجیبه ولی یه سری از پانویس‌ها اول متن بیان بهتره): در همین ابتدا عذرخواهی می‌کنم از انگلیسی نوشتن یه سری از واژه‌ها. بعضی کلمات تابِ فراقِ وطن و سفر به دیارِ غربت رو ندارن?

شروعی نسبتاً طوفانی: من ترجیح می‌دم به جای ریخت و پاشِ تجمل‌گرایانه به‌واسطه‌ی حضورِ سنگینِ یه عده کلمه‌ی قُلُمبه سُلُمبه که تو اکثر methodهای امروزی به وُفور دیده میشه، برم سراغ متدولوژی یعنی روش‌های شناخت و آنالیز، و از چرایی متدها حرف بزنم، از اهدافِ پشتِ پرده‌شون، و از همین الان تمرین کنم که من اونی‌ام که (ان‌شاءالله در آینده?) باید دنبال جوابِ سوال‌های چی و چرا باشم. به قول Cole Mercer که میگه:

Product Managers Are Responsible For The What And The Why And Engineers And Designers Are Responsible For The How.

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

ما باید به همه‌ی ذی‌ربط‌هامون آموزش بدیم (می‌گم ذی‌ربط و نه ذی‌نفع تا یادمون نره زندگی سراسر منفعت نیست!) که روش‌های قدیمی برای تعریف نقشه‌ی راه محصول (که لیستی از featureها بودن با تاریخ‌های مشخصِ از قبل تعیین‌شده) در دنیای مدرنِ دیجیتال پُر فراز و نشیبِ امروز کارایی ندارن. به خاطر همینه که تو برنامه‌ریزی به سبک agile، می‌گیم estimation and planning، یعنی توی زمان‌بندیِ پروژه، به جای اینکه دِدلاین‌های دقیقِ دست و پا گیر تعریف کنیم که فقط زمان و انرژی‌مون رو هدر می‌ده، به برآورد کردن بسنده می‌کنیم. اینو میشه تو شیوه‌ی تعیین story pointها به سبک اجایل هم دید. ما حتی در Burndown chartها هم فقط در تلاشیم چیزی که قراره در سیکل بعدی اتفاق بیفته رو پیش‌بینی کنیم، یه پیش‌بینیِ مقرون به صرفه.

بدون تعارف، نقشه‌ی راهی که feature-based باشه جواب نمیده! ما باید هر ماه (یا در بدترین حالت هر فصل) زمانی رو به ارزیابی اهداف و برنامه‌های آینده‌ی‌ شرکت‌مون اختصاص بدیم، ارزیابی با چاشنی نقد و بررسی.

باید حواسمون باشه از چارچوبِ data-driven و customer-centric بودن خارج نشیم و جلسات‌مون تعاملی باشن. همه‌ی ‌افراد باید "فرصت شنیده‌شدن" داشته باشن (البته اگه حرفی برای گفتن دارن!)، نه فقط سخنوریِ یک عده‌ی قلیل و «سر تکان دادنِ» یک عده‌ی کثیر...

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

چرا مردم اینقدر از کارهاشون ناراضی‌ان؟

چند وقت پیش داشتم یکی از ویدیوهای TEDرو می‌دیدم، از آقای Michael C. Bush، در مورد این بود که چرا مردم اینقدر از کارهاشون ناراضی‌ان؟ ایشون می‌گفت اگرچه درآمد بسیار مهمه (بله بله واقعا مهمه و من به‌هیچ عنوان نمی‌خوام مُنکر تاثیر درآمد بر رضایتمندی از زندگی بشم)، اما دلایل دیگه‌ای هم وجود داره که باعث میشه بیشترِ مردم از کارشون ناراضی باشن.

در واقع نکته‌ی اصلی اینه که برای کارکنان بسیار مهمه که leaderها و همکارانشون چطور با اونها رفتار می‌کنن؟ کارکنان در یک سازمان به اعتماد و احترام، انصاف و عدالت، و در نهایت شنیده‌شدن نیاز دارن، به اونها باید فرصت تصمیم‌گیرنده بودن داده بشه، به این ترتیب اونها احساس قابل‌اعتماد و اطمینان بودن می‌کنند، شنیده‌شدن اینجا به‌معنای این نیست که وقتی حرف می‌زنن active-listener خوبی باشیم، شنیده‌شدن یعنی در مقابل حرف‌ها و ایده‌هاشون متواضع باشیم و ایده‌های اونها رو موقع تصمیم‌گیری در نظر بگیریم.

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

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

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

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

فرضِ اینکه مدیر محصول یا تیم مدیریت تنها کسانی هستن که می‌تونن نماینده مشتری باشن و در مورد چیزایی که مهمه نظرات و بازخورد ارائه بدن اشتباهیه که خیلی از مدیران محصول تازه‌کار مرتکب می‌شن و محصولاتشون هم به همین خاطر آسیب می‌بینن. دلیل اصلی اینکه ما می‌خوایم نقشه راه محصول برای همه‌ی افراد سازمان قابل مشاهده باشه اینه که roadmap نشان‌دهنده‌ی برنامه‌ی اجرایی در برابر vision و استراتژی شرکته.

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

ما باید یک پروسه و برنامه‌ی شفاف و منعطف داشته باشیم، به‌طور منظم کارهایی که می‌کنیم رو بررسی و review کنیم و خودمونو آپدیت نگه‌داریم تا بتونیم به یه نتیجه‌‎ی شفاف و مطلوب برسیم. (و تو پرانتز بگم که باید توی این مسیر تمرین کنیم که به جای outputگرا بودن، outcomeگرا باشیم و عوضِ اینکه فقط کمیتِ خروجی‌های تیم برامون مهم باشه، کیفیت نتیجه‌ها رو جدی بگیریم تا بتونیم یه محصول desirable به دست مشتری برسونیم- راهبرد "فشار حداکثری" به اعضا، هر جا جواب بده، اینجا جواب نمی‌ده!)

چرا roadmap meeting برگزار کنیم؟ اصلا این همه جلسه برای چیه؟

در واقع دلیل اینکه توی متدولوژی اجایل باید roadmap meeting برگزار کنیم همینه که کل تیم در مورد چشم‌انداز یک محصول جدید باهم صحبت کنن و به بررسی استراتژی محصول و مراحلی که برای اجرای برنامه‌ی استراتژیکِ تیم لازمه بپردازن.

هدف اصلی این نوع جلسات، جلب مشارکتِ stakeholderها در جهت استراتژی ماست نه اینکه دنبال این باشیم که برای اهداف یا دستاوردهایِ از دست رفته بقیه رو متهم کنیم. roadmap meeting فرصتیه برای تأیید اهداف و اولویت‌بندی تلاش‌ها (قصه‌ی prioritizingسرِ واقعا درازی داره).

ما باید اهداف‌مون رو بشناسیم و حواسمون باشه که از مسیر منحرف نشیم. اگر به عنوان مدیر محصول از بقیه می‌خوایم با چیزایی که ما پیشنهاد می‌کنیم موافقت کنن، این وظیفه ماست که مشخص کنیم چرا این کارها را انجام می‌دیم، چه جوری به نتیجه می‌رسیم و چه چیزی ما را به سمت اون نتیجه سوق می‌ده و همیشه حواسمون باشه که همه‌چیز حولِ محورِ مشتری و مارکت بگرده که اگه نگرده product/market fit از دست رفته...

ما نمی‌تونیم آهنگِ توی سر یه نفر دیگه رو بشنویم!

آقای Alex Cowan (استاد دانشگاه ویرجینیا) توی کورس مدیریت محصولی که تدریس کردن به یه نکته خیلی خیلی جالبِ ‌توجه اشاره می‌کنه:

People understand a lot less of what we tell them or what we write for them than we think!

در کتاب Made to Stick نوشته‌ی آقایان Chip & Dan Heath به پژوهش جالبی اشاره شده:

طی یک مطالعه تحت عنوان بازی"tapper and listeners" پژوهشگرا از یه سری از افراد خواستن که ریتم یک آهنگ رو (قاعدتا یه آهنگ معروف) با ضربه زدن با انگشت روی میز نشون بدن و در مقابل یه عده اسم اون آهنگ رو حدس بزنن. طی این آزمایش در اغلبِ موارد شنونده در شناسایی آهنگ شکست خورده! (نتیجه‌ی کار درست برخلاف پیش‌بینی اونایی که tapper بودن شده) اتفاقی که اینجا افتاده چیه؟ قضیه اینه که کسی‌که آهنگ رو می‌زنه اون آهنگ داره توی سرش پِلی میشه و به همین خاطر فکر می‌کنه که ریتم مناسبی داره، اما فردی که ضربه‌ها را می‌شنوه قاعدتا نمی‌تونه آهنگِ توی سر یه نفر دیگه رو بشنوه! و بنابراین نمی‌تونه تشخیص بده این ریتم برای کدوم آهنگه؟!

مشکل اصلی در اینجا نوعی سوگیری و خطای ذهنیه تحت عنوان Curse of Knowledge یا همون "نفرین دانش". به سبب این خطای شناختی شخصی که ایده رو به اشتراک می‌ذاره انواع اطلاعاتی رو داره که بقیه ندارن ولی اون شخص تصور می‌کنه که دیگران هم در زمینه‌ی مورد بحث به اندازه لازم آگاهی دارن و متوجه مطلب شدن (ولی در واقع نشدن و روشون نمیشه بگن!).

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

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

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

دلیل اینکه سازمان‌ها جلسات daily-standup یا همون standup meetings توی فریم‌وُرک scrum رو برگزار می‌کنن هم همینه: رسیدن به یه درک روشن از روند کار برای گرفتن تصمیمات هوشمندانه‌تر در کنار همدیگه.

دلیل اینکه باید storyboard بسازیم و“story map” داشته باشیم هم همینه. به‌علاوه واقعا مهمه که به عنوان یک PM داستان‌های کاربر رو به صورت اشتراکی با تیم بنویسیم؛ حتی اگر خروجیِ کار تفاوتی نداشته باشه، درکی که دِولوپرها در این همفکری بهش می‌رسن حتی تا 10 برابر ممکنه بیش‌تر از حالت غیرتعاملی باشه.Information Asymmetry بزرگتر از اون چیزیه که فکرش رو می‌کنین ("عدم تقارن اطلاعاتی" یه پدیده‌ایه در علم اقتصاد، اگه دوست داشتین برید راجع‌بش بخونین.)

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

کار کردن در یک اتاق پروژه، یا به قول خارجی‌ها "information radiator" هم راه خوبی برای همگام‌سازی و به قولی syncکردن اعضای تیمه.

نقش مدیر محصول در ایجاد هماهنگی بین تیم‌ها

توی یه مصاحبه Cole Mercer (یهPM کار کُشته) از Daniel Demetri (که قبلا تو گوگل PM بوده و الان کسب و کارِ خفن خودش رو داره) می‌پرسه اگه بخوای خیلی مختصر نقش مدیر محصول رو بگی چی میگی؟ اون در جواب میگه:

filling the gaps between the cross-functional roles.

حالا سوالی که مطرحه اینه که چطور این گَپ رو پُر کنیم؟

یه vision یا هدف مشترک ساده‌ترین راه برای کنار هم نگه‌داشتن اعضای تیمه. تعریف اهداف مشترک برای دو تیمِ پروداکت و مارکتینگ، دلیلی برای همکاری بهشون میده و اونها رو با انگیزه نگه می‌داره.

سوالی که تو مرحله بعد مطرح میشه اینه که چطور برای این نقش‌های cross-functional اهدافِ مشترک تعیین کنیم؟

اینجا باید حواستون باشه که اهدافی که تعیین می‌کنین با معیارهای روش S.M.A.R.T مطابقت داشته باشن. می‌پرسید چرا؟ چون S.M.A.R.T یه کلمه‌ی مخففه و از کنار هم قرار دادنِ حروف اول پنج تا کلمه ساخته شده و خارجی‌ها کلا از acronymها خوششون میاد و واسه هر چیزی یه acronymمی‌سازن و خیلی هم باهاش حال می‌کنن و به‌خاطرش کلی هم جایزه می‌گیرن? پس منطقی‌تر اینه که اینجا دیگه به جای "چرا"، بپرسید "چه جوری"؟ اینجوری:

• مشخص specific: نتیجه نهایی باید برای همه واضح و شفاف و مشخص باشه (ترجیجا اینجا به ضرب‌المثل "آنچه عیان است چه حاجت به بیان است" اعتنایی نکنید و بیان کنید.)
• قابل اندازه‌گیری measurable: نتیجه‌ی نهایی یا پیشرفت باید قابل اندازه‌گیری باشه.
• دست یافتنی attainable: دستیابی به هدف با تیم فعلی و منابع موجود نباید غیرممکن باشه (گاهی اوقات جملات انگیزشی از قبیل the only impossible journey is the one you never begin رو باید بذارید کنار و یه ذره هم که شده واقع‌گرا باشید!)
• مرتبط relevant: هدف باید با جهت‌گیری سازمان همسو باشه. (همون داستانِ vision و big picture و این چیزا)
• زمان ​​محدود time-bound: هدف باید یک جدول زمانی مشخص، دیتا و ددلاین داشته باشه (بله بله ددلاینِ سفت و سختِ دست و پا گیر نه، ولی متُدِ " علی برکت الله" هم مثل "فشار حداکثری" می‌مونه، جواب نمیده!)

زبان مشترک برای تعامل بهتر

در کنار همه موارد بالا استفاده از یه زبان مشترک و استاندارد کردن اصطلاحاتی که موقع اشاره به محصول، فیچر‌ها و مشتری‌ها ازشون استفاده می‌کنیم می‌تونه به رفع اصطکاک و افزایش همکاری بین تیم‌ها کمک کنه و سردرگمیِ افراد رو موقع تصمیم‌گیری کاهش بده و ارتباطات اعضای تیم رو هم بهتر کنه. به قول یکی از اساتید مدیریت پروژه‌ام: استانداردها بوجود اومدن تا یه زبان مشترک بین‌المللی وجود داشته باشه (البته جمله‌ی ایشون قشنگ‌تر بود، من الان دقیقش رو یادم نیست شرمنده، ولی کُنهِ مطلب همین بود!). با وجود یه زبان مشترکِ راحتُ‌الفَهم همه چیز شفاف‌تر میشه و سرِ DOD یا definition of done هم راحت‌تر باهم به توافق می‌رسیم.

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

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

پ.ن: این سوال رو آقای nihiL توی فرم درخواست برای موقعیت شغلیِ دستیار محصول گذاشته بودن، منم شروع کردم به نوشتنِ جوابِ این سوال و شد یه مقاله‌ی نسبتاً بلند بالا و انصافاً پُر محتوا؛ یه‌جورایی چکیده‌ای از کورس‌هایی که توی این مدت دیدم(از یودمی و کورسرا) و مقاله‌هایی که خوندم. با آغوش باز (نسبتاً باز?) پذیرای انتقادات و پیشنهاداتتون هستم. قبول دارم خیلی از چیزایی که گفتم شبیه حل کردن مسائل فیزیک توی محیط ایزوله با صرف نظر از نیروی اصطکاک و مقاومت هواست و در یک محیط پویا با وجود تأثیر و تاثّر عوامل محیطی گاهی ساده‌ترین قوانین به‌راحتی نقض میشن... ولی خب هیچ‌چیزی به جز وحیِ مُنزَل، وحی منزل نیست و طبیعیه که گاهی مصداق نداشته باشه و نقض بشه...