قبل از ساختن بپرس: مشتری هدف اصلیت کیه؟
خلاصهٔ کامل‌تر
این مطلب بخشی از سری Tech Team Talk تو خبرنامه‌ی Thriving in Engineering هست و این بار نویسنده‌ش Skipper Chong Warson هست که بیش از ۱۵ سال تو حوزه‌ی محصول و طراحی کار کرده. اون به تیم‌های نوپا کمک می‌کنه قبل از یه تصمیم بزرگ ساخت یا ورود به بازار بفهمن کدوم مشتری و کدوم مشکل ارزش شرط بعدی‌شون رو داره. روش اصلیش یه فرضیه‌ی یه‌جمله‌ای درباره‌ی Bullseye Customer یا همون بهترین مشتری تیمه.
به گفته‌ی نویسنده، این one-liner پنج چیز رو مشخص می‌کنه: نقش دقیق آدم، نوع یا اندازه‌ی شرکتش، چیزی که وادارش می‌کنه دست به کار بشه، راه‌حل ناکافی‌ای که الان استفاده می‌کنه، و نتیجه‌ای که لازم داره. دلیلش اینه که هر نقش تو تیم ناخودآگاه یه مشتری متفاوت تو ذهنش داره: مهندس به محدودیت‌های فنی integration فکر می‌کنه، مدیر محصول به workflow و بنیان‌گذار به خریدار. هر سه جواب منطقیه، ولی مشکل از جایی شروع میشه که با این نقطه‌شروع‌های متفاوت درباره‌ی roadmap تصمیم می‌گیرن.
نمونه‌ش یه تیم devtools بود که فکر می‌کرد مدیرهای عملیات از ابزارهای پراکنده و کارهای دستی تکراری خسته‌ن و ساخت اپ‌های ساده‌ی CRUD (یعنی ایجاد، خوندن، ویرایش و حذف داده) با کمک AI به دردشون می‌خوره. پنج مصاحبه‌ی اول این دردها رو تأیید کرد، ولی یه نقص تو فرضیه رو هم نشون داد: درد به‌اندازه‌ی کافی فشار برای تغییر ایجاد نمی‌کرد. یه مدیر عملیات از تورنتو گفته بود ترجیح می‌ده با ناکارآمدی‌ای که می‌شناسه کنار بیاد تا اینکه ریسک کنه و چیزی رو اشتباه تنظیم کنه. یعنی خطر تنظیم اشتباه از خود ناکارآمدی ترسناک‌تر بود.
نویسنده پیشنهاد می‌کنه ۲۰ تا ۳۰ تا one-liner اولیه بنویسید، از روی داده‌ی مشتری، حدس یا حتی رقبا. معیارش اینه که بشه جمله رو راحت به یه screener برای جذب مصاحبه‌شونده تبدیل کرد. مثلاً «مدیرهای عملیاتی که اتوماسیون بهتر می‌خوان» رد میشه، چون هیچ معیار مشخصی برای اینکه کی رو بیاری و کی رو نیاری بهت نمی‌ده. اگه نتونی معیار حذف ازش دربیاری، هنوز خیلی کلیه. تو همون تیم devtools، بعد از پنج چرخه‌ی دیگه و نزدیک ۵۰ مصاحبه، فرضیه به سمت آدم‌هایی رفت که قبلاً یه چیز واقعی با ریسک مالی ساخته بودن و وقتی خراب شد گیر کرده بودن.
نکته‌ی دیگه اینه که کشف مشتری با دمو فرق داره. نویسنده می‌گه تیم‌های فنی و فروش معمولاً با نشون دادن محصولشون شروع می‌کنن و این‌جوری فقط واکنش آدم‌ها به پیاده‌سازی خودشون رو جمع می‌کنن. شواهد قوی‌تر از رفتار فعلی آدم‌ها میاد: آخرین بار که این مشکل پیش اومد چی شد، چی کار کردن، از چه ابزاری استفاده کردن و چرا همون روش رو ادامه دادن. جمله‌هایی مثل «عاشقشم» یا «حتماً استفاده می‌کنم» سیگنال ضعیفی هستن.
در کل، Bullseye یه فرضیه‌ی در حال کاره: یکی رو انتخاب کن، تصمیم بگیر چه شواهدی ضعیفش می‌کنه و برو دنبال همون شواهد.
نکات کلیدی:
- one-liner پنج بخش داره: نقش، نوع یا اندازه‌ی شرکت، محرک، راه‌حل فعلی ناکافی و نتیجه‌ی مورد نیاز
- پیشنهاد نویسنده نوشتن ۲۰ تا ۳۰ one-liner اولیه‌ست
- معیار دقت: باید بشه ازش معیار ورود و حذف برای جذب مصاحبه‌شونده درآورد
- تو مثال devtools، پنج چرخه و نزدیک ۵۰ مصاحبه فرضیه رو کاملاً دقیق‌تر کرد
- ریسک تنظیم اشتباه می‌تونه از ناکارآمدی فعلی برای مشتری مهم‌تر باشه
- تعریف و تمجید و قول‌های فرضی مشتری سیگنال ضعیفه؛ داستان رفتار گذشته سیگنال قوی
