۵ چیزی که کشف کردن را برای مدیران محصول دشوار می‌کند

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

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

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

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

تعریف کشف کردن و تحویل دادن

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

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

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

دشواری‌های کشف کردن 

۱. ما در قالب راه‌حل‌ها می‌اندیشیم

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

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

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

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

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

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

۳. فکر و ذکر برخی از توسعه‌دهندگان درگیر تحویل است

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

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

۴. تحویل، خروجی ملموس دارد

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

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

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

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

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

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


منتشر شده

در

توسط

دیدگاه‌ها

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *