دسته‌ها
الفبای محصول

نقشه راه محصول و بک لاگ محصول – شباهت ها و تفاوت ها

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

نقشه راه محصول در مقابل بک‎لاگ

نقشه راه محصول و بک‎لاگ محصول دو ابزار مهم مدیریت محصول هستند. هریک از این دو ابزار نقاط قوت و ضعف خود را دارد: نقشه راه عبارت است از ابزار راهبردی برنامه‎ریزی که نحوه رشد احتمالی محصول در چندین انتشار اصلی را نشان می‌دهد، باعث تداوم هدف می‎شود، همکاری ذی‎نفعان را تسهیل، به دستیبابی به تأمین سرمایه کمک، و شرایط را به منظور همکاری برای توسعه و آغاز فروش محصول آسان می‏کند.

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

نقشه راه محصول و بک لاگ محصول
نقشه راه محصول و بک لاگ محصول

این دو ابزار، در صورتی که به‎طور صحیح به‌کار روند، به خوبی مکمل یکدیگر هستند. نقشه راه محصول چتری را برای بک‌لاگ محصول ایجاد می‌کند و مطالب بیش‌تری در مورد رشد احتمالی محصول دارد، درحالی‌که بک‎لاگ شامل جزئیاتی است که برای ایجاد محصول ضروری‏‌اند.

استخراج بک‎لاگ محصول از نقشه راه محصول

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

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

تمرکز بک لاگ محصول بر انتشار بعدی
تمرکز بک لاگ محصول بر انتشار بعدی

بیشتر بخوانید: استراتژی محصول خوب چگونه است؟ + نمونه موردی اسنپ

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

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

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

پیکربندی نقشه راه محصول و بک‌لاگ محصول را حفظ کنید

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

برای مطالعه دیگر مطالب در زمینه الفبای مدیریت محصول از این لینک استفاده کنید.

منبع: نوشته ای از بلاگ تخصصی رومن پیچلر مشاور مدیریت محصول

دسته‌ها
الفبای محصول

وارونه کار کردن : چطور با حداقل نیازهای تکنولوژی به چیزی برسیم که ما را به اهدافمان می‌رساند

در آمازون سرویس‌هایی که استفاده می‌کنیم قرار نیست فقط به وب سایت و نرم افزار ارائه شوند آن‌ها ساختارهای سازمانی را هم تحت تاثیر قرار می‌دهند.

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

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

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

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

کارکردن‌های وارونه محصول درباره مفهوم و دستیابی به نظم و ترتیب فکری درباره ساخت و ارائه محصول است و ۴ قدم دارد:

۱- یک بیانیه انتشار (Press Release) برای محصول بنویسید

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

۲- سوالات رایج درباره محصول را بنویسید

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

۳- تجربه مشتری را تعریف کنید

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

۴- دستورالعمل استفاده از محصول بنویسید

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

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

دسته‌ها
الفبای محصول

مدیر محصول خوب و مدیر محصول بد را بشناسید


احتمالا در ذهن شما هم مسئله مدیر محصول هنوز به خوبی جا نیفتاده است. شاید هنوز نمی‌دانید کار یک مدیر محصول چیست! احتمالا مقایسه یک مدیر محصول خوب و یک مدیر محصول بد بتواند به شما در شفاف شدن نقش این افراد کمک کند.

‫اخطار: این مقاله ۱۵ سال پیش نوشته شده و ممکن است به مدیران محصول امروز مربوط نشود اما یک مثال خوب از یک داکیومنت آموزشی مفید است.

‫مدیران محصول خوب بازار، محصول و خط تولید محصول را می‌شناسند و از دانش پایه‌ای و اطمینان خوبی برخوردار هستند.

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

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

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

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

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

بیشتر بخوانید:استراتژی لیست انجام کار نیست!

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

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

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

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

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

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

مدیران محصول خوب به سمت شفافیت و توضیحات گویا لغزش می‌کنند. مدیران محصول بد هرگز آشکارا توضیح نمی‌دهند.

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

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

منبع: Good Product Manager/Bad Product Manager