درون محصول دیجیتال - چرا اکثر محصولات دیجیتال شکست میخورند؟ (مقاله ۲)
چند سال پیش، به یک استارتاپ ۱۵ نفره بعنوان مشاور ملحق شدم. بودجه خوبی داشتند. تیم باهوش، مدیرعامل با انگیزه، شش ماه روی محصولشان کار کرده بودند.
اولین جلسه، محصول را بررسی کردیم. یک پلتفرم فروشگاهی با قابلیت چت که بر اساس موقعیت جغرافیایی نزدیکترین فروشگاههای مورد نیاز کاربر را نمایش میداد و کاربر میتوانست با ارسال پیام نیاز خود را به فروشگاههای مورد نظر ارسال کند سپس بر اساس پاسخ فروشگاهها و مقایسه آنها کالای مورد نظر را از فروشگاه منتخب سفارش میداد. بعلاوه کلی فیچرهای جذاب دیگر هم در حال توسعه بودند.
پرسیدم: “چند کاربر دارید؟”
“گفتند: هنوز لانچ نکردیم. میخواهیم اول کامل بشود.”
این جمله را خیلی شنیدهام. و هر بار، میدانم چه اتفاقی میافتد.
اکثر محصولات از همینجا شروع به شکست میخورند — نه وقتی لانچ میشوند، بلکه وقتی تصمیم میگیرند چه بسازند.
آنها شش ماه مشغول کد نویسی و توسعه محصول بود. اما هیچوقت با کاربران واقعی صحبت نکرده بودند. فرض کرده بودند میدانند مشکل چیست.
فرض کردن راحت است. صحبت کردن و البته «درست صحبت کردن» سخت.
هنگامی که در حال طراحی یک اپلیکیشن سفارش آنلاین غذا بودیم. مهمترین خواسته کاربر را “تسریع در ارسال غذا” فرض کرده بودیم.
رفتیم با مردم صحبت کنیم. متوجه شدیم مشکل اصلی سرعت نیست. مشکل این است که نمیدانند چه بخورند. هر بار که میخواهند سفارش بدهند، ده دقیقه وقت میگذارند تا تصمیم بگیرند.
اگر ما بدون صحبت با کاربران شروع به ساختن میکردیم، احتمالاً زمان و هزینه زیادی را میبایست صرف بخشهای عملیاتی، لاجستیک و قابلیتهای سیستمی مرتبط میکردیم. ولی سریعترین ارسال چیزی نبود که مردم میخواستند و فقط کافی بود به تعهد زمان ارسال مقید باشیم. قابلیت مهمتری که کاربران میخواستند کمک به تسریع تصمیمگیری در انتخاب غذا بود.
درس اول: محصول خوب با فهمیدن شروع میشود، نه با ساختن.
یک پدیده عجیب وجود دارد: وقتی تیمی شروع به ساختن چیزی میکند، عاشق آن میشود. حتی اگر کار نکند.
در یک اپلیکیشن مدیریت پروژه، یک فیچر داشت که روی آن خیلی وقت گذاشته بودند: “نمودار وابستگی وظایف سهبعدی.”
پرسیدم: “کسی این را خواسته؟”
“گفتند نه، اما فکر میکنیم خیلی جالب است.”
این جمله خطرناک است: “فکر میکنیم.”
وقتی تیمی عاشق ایدهاش میشود، دیگر نمیتواند ببیند که کار نمیکند. هر بازخورد منفی را نادیده میگیرد. هر نشانه شکست را توجیه میکند.
من خودم این اشتباه را کردهام. چند سال پیش، روی یک فیچر کار کردم که فکر میکردم انقلابی است. پنج ماه طراحی و پیاده سازی آن طول کشید. این قابلیت به تولید کنندگان محتوای سفر این امکان را میداد که یک برنامه سفر با جزئیات کامل مانند تصویر، متن، نقشه، تخمین هزینه و ... طراحی کنند و آنرا به اشتراک بگذارند یا حتی بفروشند. وقتی لانچ کردیم، فقط یک نفر از آن استفاده کرد و تا ماهها بعد دنبال کاربرانی مانند آن نفر بودیم ولی پیدا نشد.
چرا؟ چون من عاشق راهحل بودم، نه مشکل. فراموش کرده بودم بپرسم: “آیا کاربر واقعاً این را میخواهد؟”
درس دوم: عاشق مشکل باش، نه راهحل. راهحلها میتوانند تغییر کنند.
« هروقت کسی به شما گفت که محصول ما برای همه است! یعنی آن محصول برای هیچکس نیست. »
وقتی میخواهید برای همه بسازید، نمیتوانید برای هیچکس، خوب بسازید. چون نیازهای آنها با هم متفاوت است. بعبارتی وقتی بخواهید همه را راضی کنید، یک محصول بیهویت ساخته میشود.
بهترین محصولات برای یک گروه خاص ساخته میشوند. آنقدر خاص که آن گروه حس کند این محصول فقط برای آنها ساخته شده.
یک مثال: چند سال پیش با جمعی از دوستان نویسندهام ملاقات کردم و متوجه شدم همه از یک اپلیکیشن یادداشتبرداری خاص استفاده میکنند، وقتی آنرا بررسی کردم دیدم بسیار ساده است و هیچ امکان خاصی ندارد. در واقع آن اپلیکیشن فقط برای نویسندهها ساخته شده بود، نه دانشجوها و نه مدیران. همین باعث شده بود که نویسندهها عاشقش باشند. به نظرم طراحان ویراستار «ویرگول» هم با چنین درکی این محیط ویراستاری ساده را طراحی کردهاند.
درس سوم: بهتر است ۱۰۰ نفر عاشق محصول شما باشند تا ۱۰,۰۰۰ نفر بیتفاوت.
یک الگوی تکراری: تیم رقیب یک فیچر به محصولش اضافه میکند. مدیران میبینند و میگویند ما هم باید آن فیچر را داشته باشیم.
یک الگوی تکراری دیگر: در نظرسنجیهایی که از کاربران درباره محصول میشود، بعضیها میگویند: “کاش فلان فیچر را داشتید.”
تیم محصول بدون بررسی دقیق، مشخص کردن شاخصهای کلیدی و ... فیچر اول، بعد دوم، بعد سوم و ... را اضافه میکند.
یک سال بعد، محصول کلی فیچر دارد که استفاده نمیشوند ولی باعث ایجاد پیچیدگی در تجربه کاربری، توسعه و نگهداری فنی محصول شدهاند.
این اتفاق برای خیلی از محصولات دیجیتال میافتد و وقتی ریشهیابی میکنم متوجه میشوم که آنها تلاش کردهاند نیازهای همه کاربران مختلف و درخواستهای مدیران را برطرف کنند!
محصول خوب مثل یک چاقوی تیز است — یک کار را عالی انجام میدهد. محصول بد مثل یک چاقوی سوئیسی است — همه کار میکند، اما هیچکدام را خوب انجام نمیدهد.
درس چهارم: قدرت در سادگی است و یک محصول خوب حاصل انتخاب نکردنها است.
آخرین اشتباه، خطرناکترین است: «فراموش کردن هدف اصلی»
تیمها با یک مشکل واقعی شروع میکنند. اما در مسیر، گم میشوند. شروع میکنند به فکر کردن درباره رقبا، درباره سرمایهگذاران، درباره متریکها.
و یک روز، متوجه میشوند دارند چیزی میسازند که خودشان هم نمیخواهند.
چقدر برای شما پیش آمده که متوجه شدهاید که همکارانتان برای نیازی که قرار است محصول شما برطرف کند از اپلیکیشنها و پلتفرمهای دیگر استفاده میکنند.
اگر خودتان یا کارکنانتان از محصولتان استفاده نمیکنید، چرا انتظار دارید دیگران استفاده کنند؟
درس پنجم: اگر محصول شما مشکل شما را حل نمیکند، احتمالاً مشکل کس دیگری را هم حل نمیکند.
این اشتباهات را همه میکنیم. من هم کردهام. تیمهای بزرگ هم میکنند.
اما تفاوت بین محصول موفق و شکستخورده این است: سرعت یادگیری.
تیمهایی که موفق میشوند، زودتر متوجه اشتباهاتشان میشوند. زودتر تغییر میکنند. زودتر میپذیرند که اشتباه کردهاند.
روی هر مورد تعمق کنید:
آیا قبل از شروع ساخت، با حداقل ۱۰ کاربر بالقوه صحبت کردهاید؟
آیا میتوانید در یک جمله بگویید برای چه کسی میسازید؟ (نه “همه”)
آیا خودتان از محصولتان استفاده میکنید یا محصولات مشابه را ترجیح میدهید؟
آیا هنگامیکه فیچری به محصولتان اضافه کردید دلایلتان کافی بود؟
آیا میتوانید بگویید چرا این محصول را میسازید؟ (بدون اینکه به رقبا اشاره کنید)
اگر به بیش از دو سوال “نه” گفتید، وقت آن رسیده که یک قدم به عقب برگردید و دوباره فکر کنید.
آخرین باری که روی محصولی کار کردی و بعد متوجه شدی کسی نمیخواهد، کی بود؟ چه چیزی باعث شد متوجه شوی؟
در مقاله بعدی، درباره چیزی صحبت میکنیم که اکثر تیمها فراموش میکنند: تفاوت بین ساختن محصول و حل کردن مشکل.
