ترجمه و برداشت آزاد از ایده‌های اصلی مقاله، با ارجاع به منبع اصلی.

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

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

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

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

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

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

  1. برگه پیشنهادی آزمایش: اعتراض اولیه، رخداد مشتری، مرحله منتخب، رضایت، معیار مشاهده، زمان تیم، انتخاب مشتری و تصمیم بعدی.
  2. در جلسه پایانی از هر ادعا بپرسید: این را دیدیم، از آن برداشت کردیم یا هنوز باید بررسی کنیم؟
  • یک اعتراض کلی به ایده را به سؤال درباره آخرین تجربه واقعی مشتری تبدیل کنید.
  • برای آزمون نخست، فقط یک مرحله از کار مشتری را انتخاب کنید.
  • رضایت شرکت‌کنندگان و حداقل داده لازم را پیش از اجرای آزمایش مشخص کنید.
  • زمان دخالت دستی تیم را کنار نتیجه مشتری ثبت کنید؛ آن را پنهان نکنید.
  • نبود درخواست، شکست هماهنگی و انتخاب‌نکردن دوباره خدمت را سه نتیجه متفاوت بدانید.
  • پیش از شروع، سقف تلاش و تاریخ جمع‌بندی را تعیین کنید و نتیجه را بیش از دامنه آزمون تعمیم ندهید.

این مقاله چه چیزی را برایت روشن کرد؟

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

با ارسال، برنامه ایمیل دستگاه باز می‌شود.

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