تناسب شرکت
اگر یک مدیر محصول صلاحیتهای اصلی خود را بهخوبی توسعه داده باشد و هوش هیجانی بالایی را نیز به همراه خود یدک بکشد، آیا این به این معنی است که صرفنظر از جایی که او کار میکند، موفقیت او تضمین شده است؟ نه لزوما. درواقع، کسب این مهارتها، ویژگیهای شخصیتی و بهکارگیری آنها در یک شرکت خوب آن چیزی است که درنهایت به موفقیت منجر میشود.
من هنوز یک توصیف شغلی استاندارد برای مدیر محصول سراغ ندارم. زیرا هر نقش درنهایت باید با توجه بهاندازه، نوع محصول، مرحله، صنعت و حتی فرهنگ شرکت تعریف شود. اگر شما از صلاحیتهای لازم ذکر شده برخوردار هستید و هوش هیجانی لازم برای تبدیلشدن به یک مدیر محصول موفق را نیز در خود میبینید، قدم بعدی شما این است که ببینید چه کسی مسئول استخدام است و آنها به دنبال چه هستند.
در اینجا زمینههای کلیدی تفاوت شرکتها در خواستههایشان از یک مدیر محصول ذکر شده است.
مهارتهای فنی: نوع محصول، شخصی که از آن استفاده میکند و نوع شرکت، سطح فنی بودن یک مدیر محصول را تعیین میکند. برای مثال، شرکت گوگل از مدیران محصول میخواهد که صرفنظر از محصولی که شرکت روی آن کار میکند، آزمون مهارتهای فنی را پشت سر بگذارند. یا مثلا اگر شرکت در حال ساخت یک نرمافزار مدیریت ارتباط مشتریان است، آنها ممکن است به دنبال کسی باشند که تجربه بیشتری در مورد چرخه مشتریان در بازار داشته باشد و مهارت داشتن مدیر محصول در ساخت این نرمافزار برایشان مهم نباشد. اما در مقابل، اگر با یک محصول داده محور با الگوریتمهای یادگیری ماشینی و API ها مواجه باشیم، مدیر محصول نهتنها باید درک فنی عمیقی از ساخت محصول داشته باشد، بلکه باید بتواند به نحوی مطمئن با مشتریانی که از آن استفاده میکنند نیز صحبت کند. بهصورت کلی، داشتن درک فنی و آگاهی از ابزارهای لازم برای یک مدیر محصول قطعا برای تصدی چنین نقشی مهم است. اگر به شغل مدیریت محصول علاقه دارید، ولی از مهارتهای فنی لازم آن برخوردار نیستند، میتوانید در کلاسهای آموزشی و یا دورههای آنلاین مرتبط با آن شرکت کنید.
فلسفه شرکت در مورد مدیر محصول: هر شرکت قطعا فلسفه مخصوص به خود را در مورد فرآیند توسعه محصول و جایی که مدیر محصول باید در این فرآیند دخیل باشد را دارد. در ادامه، سه نوع رایج به همراه مزایای و معایب هرکدام ذکر شده است:
مدیران محصول مهندسی را هدایت کنند: این را باید یک رویکرد «پرتاب بالاتر از دیوار» دانست که در آن مدیران محصول باید نیازمندیها را جمعآوری کنند، سندهای موردنیاز محصول را بنویسند و برای مشخص کردن نیازهای فنی آن را به تیم مهندسی ارسال کنند. سازمانهای معاصر میتوانند این روند را به شیوهای چابکتر و هماهنگتر انجام دهند، اما انتظار آن است که مدیران محصول در مورد نیازهای مشتریان و مهندسی لازم اطلاعات بیشتری داشته باشند.
مزایا: مهندسان میتوانند بدون حواسپرتی زیاد روی کد نویسی تمرکز کنند. این رویکرد برای مدل توسعه آبشاری میتواند بسیار موثر باشد.
معایب: مهندسان چشمانداز و حس همدردی با مشتریان را از دست میدهند که درنهایت میتواند به یک تجربه کاربری ضعیف منتهی شود. همچنین اغلب تنشهای زنندهای ممکن است بین تیمهای فنی و سایر اعضای تیم به وجود بیاید.
مهندسان محصول را کنترل و مدیریت کنند: در شرکتهایی که فن و مهارت در آنها حرف اول را میزند (مانند شرکتهای خدمات ابری، بیگ دیتا و شبکهسازی) تمایل بر این است که مهندسان فنی افسار کار را در دست بگیرند. درواقع مهندسان در حال پیشرفت علم در دامنه خود هستند و مدیران محصول نیز راهحلهای معتبر و راههای دسترسی اولیه برای دسترسی به این فناوری جدید را ارزیابی و تایید میکنند. بنابراین یک رابطه همکاری و حلقه بازخورد بین مشتریان، مدیران محصول و مهندسان ایجاد میشود، اما باید گفت که در چنین شرکتهایی، مدیران محصول درواقع زیردست مهندسان هستند.
مزایا: ظهور و بروز فناوری میتواند چیزهایی را به مشتریان ارائه دهد که آنها پیشازاین نمیدانستند که به آنها نیاز دارند. VMotion در VMware خود شاهدی برای تایید این گفته است. یک مهندس میداند که چگونه یک محصول را خلق کند و مدیر محصول نیز میداند که چگونه باید از آن کسب درآمد کرد. نتیجه این همکاری، محصولی برای شرکت است که میلیونها دلار را به ثمر میآورد.
معایب: در شرکتهایی که مهندسان همهکاره هستند، آنها ممکن است به دنبال چیزهایی جدید بروند، راهحل را بیشازحد ساختاربندی کنند یا به دنبال آن بروند و یا ممکن است قبل از دریافت بازخوردهای مشتریان به دنبال کمال باشند. در چنین شرکتهایی، نظرات مدیر محصول در مورد اولویتها نادیده گرفته میشود. نظراتی که گاهی اوقات شامل نیازهای اساسی مشتریان است.
همکاری مدیران محصول و مهندسان: در چنین مواردی، یک ارتباط قوی بین مدیر محصول و تیم مهندسی وجود دارد و آنها با هم به دنبال چیزهای جدید میروند، با هم تصمیم میگیرند و پاسخگویی مشترک نیز دارند.
مهندسان در مصاحبههای مشتریان به مدیران محصول ملحق میشوند و مدیران محصول نیز در جلسات اسپرینت برای مشخص کردن وظایف و شفافسازی نیازمندیها شرکت میکنند. اما وقتیکه یکی از نقشها شروع به کار میکند و دیگری متوقف میشود، آنها به مرزها و حدود یکدیگر احترام میگذارند. مدیران محصول میفهمند که چه چیزی کد نویسی شده است، اما به مهندسان نمیگویند که چگونه کد نویسی کنند، و مهندسان نیز برای نیازهای مشتریان همدردی میکنند، اما اولویتبندی را بر عهده مدیران محصول میگذارند.