در سال‌هایی که با تیم‌های محصول در اکوسیستم استارتاپی ایران کار کرده‌ام، یک الگو بارها تکرار شده است: بنیان‌گذار هر هفته فهرستی تازه از کارهای «لازم» قبل از لانچ می‌نویسد و هر هفته فهرست بلندتر می‌شود. دکمه‌ای که باید گردتر باشد، صفحه‌ای که باید متن بهتری بگیرد، قابلیتی که «حتماً» باید پیش از معرفی محصول اضافه شود. لانچ از یک تصمیم به یک آرزو تبدیل می‌شود و تاریخ آن هر ماه چند هفته عقب می‌رود. در مقابل، گروهی دیگر هستند که با محصولی نیمه‌کاره و بدون هیچ سنجشی لانچ می‌کنند و یک هفته بعد درمی‌یابند درگاه پرداخت در ساعات شلوغ از کار افتاده است.
به یاد دارم تیمی که یک اپلیکیشن سفارش غذا برای شهرهای کوچک ساخته بود و شش ماه کامل را صرف «آماده‌سازی» کرد. در روز لانچ، ۴۰۰ نفر از فهرست انتظار ثبت‌نام کردند، اما فقط یازده نفر توانستند سفارش را تا مرحله پرداخت ببرند، چون کد تأیید پیامکی با تأخیر چند دقیقه‌ای می‌رسید. آن تیم همه‌چیز را کامل کرده بود جز تنها چیزی که مسیر اصلی کاربر به آن وابسته بود. مشکل آن‌ها کمبود وقت نبود؛ نبودِ معیار بود. وقتی نمی‌دانید «آماده» یعنی چه، یا هرگز آماده نمی‌شوید یا خیلی زود و ناآماده لانچ می‌کنید.
در این مقاله پنج معیار عملی را مرور می‌کنم که از تجربه خودم و تیم‌هایی که از نزدیک دیده‌ام بیرون آمده است. این معیارها به کمال‌گرایی ربطی ندارند و قرار نیست محصول شما بینقص شود؛ هدف فقط این است که تصمیم لانچ را از حس و دلهره به چیزی قابل‌سنجش نزدیک کنید. اگر پیش‌تر درباره خطر کمال‌گرایی نوشته‌های ما را خوانده‌اید، مقاله «چرا کمال‌گرایی قبل از لانچ، قاتل MVP است» زمینه خوبی برای ادامه این بحث است.
معیار اول: مسیر اصلی کاربر را بدون کمک شما طی کنند
هر محصول یک مسیر اصلی دارد؛ همان سه یا چهار قدمی که ارزش وعده‌داده‌شده را به کاربر می‌رساند. برای یک ابزار حسابداری، این مسیر ثبت‌نام، ثبت اولین فاکتور و دیدن اولین گزارش است. برای یک بازار آنلاین، جست‌وجو، انتخاب و پرداخت. معیار نخست ساده و در عین حال سخت است: دستکم پنج نفر که شما را نمی‌شناسند باید این مسیر را از ابتدا تا انتها و بدون هیچ راهنمایی شما طی کنند. نه دوستان نزدیک که از سر مهربانی صبر می‌کنند و نه همکارانی که منطق محصول را می‌دانند، بلکه آدم‌هایی که آن را برای اولین بار می‌بینند.
آزمونش را خودتان می‌توانید اجرا کنید. پنج نفر را دعوت کنید، کنارشان بنشینید و فقط تماشا کنید. هر بار که دهان باز کردید تا چیزی را توضیح بدهید، یک نقطه شکست پیدا کرده‌اید. من در یکی از پروژه‌ها دیدم که کاربری سه دقیقه به صفحه ثبت‌نام خیره ماند، چون نمی‌دانست دکمه «ادامه» همان دکمه «ساخت حساب» است. همین سه دقیقه در روز لانچ، در مقیاس هزار کاربر، به صدها نفر ترک‌شده تبدیل می‌شود. اگر هر پنج نفر بدون کمک به خط پایان رسیدند، معیار اول را گذرانده‌اید؛ اگر حتی یک نفر نرسید، لانچ باید یک هفته دیگر صبر کند، نه یک ماه.
معیار دوم: زیرساخت بار روز لانچ را تحمل کند
محصول در محیط آزمایشی با پنج کاربر رفتار متفاوتی دارد تا در روزی که اعلام لانچ می‌کنید و ناگهان پانصد نفر هم‌زمان وارد می‌شوند. در بازار ایران این موضوع حساس‌تر هم هست، چون وابستگی‌های بیرونی ما شکننده‌تر است: درگاه پرداخت، سرویس پیامک، سرویس نقشه و میزبانی. هر یک از این‌ها می‌تواند در بدترین لحظه کند یا قطع شود. معیار دوم این است که شما برای هر وابستگی حیاتی، یک سناریوی «اگر از کار افتاد» روی کاغذ داشته باشید و دستکم یک بار بار واقعی را روی سیستم آزمایش کرده باشید.
لازم نیست آزمون بار پیچیده‌ای بنویسید. ابزارهای ساده‌ای وجود دارند که در یک بعدازظهر می‌توانند صد یا دویست درخواست هم‌زمان را به صفحه‌های اصلی شما بفرستند و زمان پاسخ را نشان بدهند. هدف دقیق بودن اعداد نیست؛ هدف دیدن نقطه‌ای است که سیستم زانو می‌زند. تیمی را می‌شناسم که با همین آزمون ساده فهمید پایگاه داده‌اش به‌ازای هر بار نمایش صفحه اول بیست پرسش جداگانه اجرا می‌کند. اصلاح آن دو روز کار برد، اما اگر در روز لانچ کشف می‌شد، کل کمپین رسانه‌ای آن تیم را به باد می‌داد. پرسش کلیدی این است: اگر ترافیک ده برابر شد، چه چیزی اول می‌شکند و آیا خودم از قبل جواب را می‌دانم؟
معیار سوم: سنجش و بازخورد از روز اول کار کند
لانچی که قابل‌سنجش نباشد، فقط یک رویداد است، نه یک آزمایش. اگر نتوانید بگویید چند نفر وارد صفحه شدند، چند نفر ثبت‌نام کردند، چند نفر به قدم دوم رسیدند و کجا ریخته‌اند، بعد از لانچ فقط حس و گمان دارید. معیار سوم می‌گوید پیش از لانچ باید سه چیز را برپا کرده باشید: ثبت رویدادهای کلیدی مسیر اصلی، یک کانال مستقیم برای دریافت بازخورد کاربر، و یک داشبورد ساده که هر صبح در کمتر از دو دقیقه وضعیت دیروز را به شما نشان بدهد.
بسیاری از بنیان‌گذاران این مرحله را به «بعد از لانچ» موکول می‌کنند و بعد تعجب می‌کنند چرا بازخوردی نمی‌گیرند. دلیلش معمولاً این است که کاربر راهی برای گفتن حرفش پیدا نکرده است؛ ما درباره این پدیده در مقاله «۶ دلیل حیاتی برای خاموشی فیدبک در لانچ محصول» مفصل نوشته‌ایم. یک دکمه ساده بازخورد، یک شماره پیام‌رسان برای پشتیبانی و یک فرم دو سؤالی بعد از اولین استفاده، برای شروع کافی است. نکته مهم این است که داده‌ای که از روز اول جمع نشود، هرگز برنمی‌گردد؛ نخستین ساعت‌های لانچ ارزشمندترین داده عمر محصول شما هستند.
معیار چهارم: حداقل پنجاه نفر منتظر شما باشند
محصول آماده یعنی محصولی که کسی برای استفاده از آن منتظر است. اگر در روز لانچ تنها مخاطبتان خانواده و دوستان باشند، شما لانچ نکرده‌اید؛ فقط دکمه انتشار را زده‌اید. معیار چهارم این است که پیش از لانچ، فهرستی از دستکم پنجاه نفر داشته باشید که مشکل را دارند، شما را می‌شناسند و موافقت کرده‌اند اولین نسخه را امتحان کنند. این عدد جادویی نیست، ولی در تجربه من، پایین‌تر از آن بازخورد کافی برای تصمیم‌گیری به دست نمی‌آید و بالاتر از آن در مراحل اول از عهده مدیریتش برنمی‌آیید.
ساخت این فهرست کار یک شبه نیست و باید از ماه‌ها قبل شروع شود. جزئیات روش‌های واقعی این کار را در راهنمای ساخت فهرست انتظار موثر قبل از لانچ آورده‌ایم. اما اصل ماجرا ساده است: با آدم‌هایی صحبت کنید که مشکل را واقعاً دارند، از آن‌ها بخواهید نام و راه ارتباطی خود را بگذارند و قول بدهید اولین نسخه را به‌صورت اختصاصی برایشان باز کنید. من مؤسسی را به یاد دارم که با بیست‌وهشت پیام مستقیم در یک شبکه حرفه‌ای شروع کرد و در سه هفته به هفتادودو نفر رسید. آن هفتادودو نفر شد هسته کاربران اولیه‌ای که امروز بیشتر بازخوردهای ارزشمند محصولش را می‌دهند.
معیار پنجم: تیم برای هفته اول آماده باشد
محصول فقط کد نیست؛ تیمی است که در هفته اول پاسخ‌گوی کاربران باشد. معیار پنجم از همه نرم‌تر به نظر می‌رسد و بیشترین لانچ‌ها را از مسیر خارج می‌کند. پرسش‌ها از همین حالا آغاز می‌شود: چه کسی به پیام‌های پشتیبانی پاسخ می‌دهد و در چه بازه‌ای؟ اگر باگی جدی گزارش شد، چه کسی تصمیم می‌گیرد و رفع آن چقدر زمان می‌برد؟ آیا کسی برنامه سفر یا مرخصی دارد؟ تیمی که لانچ را یک پنجشنبه انجام می‌دهد و می‌داند از جمعه تا شنبه هیچ‌کس پاسخ‌گو نیست، عملاً دو روز طلایی را از دست داده است.
پیشنهاد من تهیه یک برنامه یک‌صفحه‌ای برای هفت روز اول است: مسئول پشتیبانی هر روز، مسئول رصد داده‌ها، مسئول تصمیم‌های فوری و یک جلسه کوتاه مرور در پایان هر روز. اگر دنبال چارچوب مفصل‌تری برای همین هفته هستید، چک‌لیست ۷ روز اول بعد از لانچ را بخوانید. و اگر هنوز تصویر کلی فرایند لانچ در ذهنتان روشن نیست، مقاله ۷ مرحله حیاتی لانچ محصول نقطه شروع مناسبی است. آمادگی تیم یعنی روز لانچ هیچ تصمیمی برای اولین بار گرفته نشود.
چطور از این معیارها در عمل استفاده کنیم؟
این پنج معیار قرار نیست به یک نمره صد‌تایی تبدیل شوند. پیشنهاد من این است که آن‌ها را به‌صورت پنج پرسش بله یا خیر روی یک برگه بنویسید و هر هفته به آن‌ها پاسخ بدهید. اگر چهار تا از پنج پرسش «بله» بود و پنجمی هم برنامه مشخص و کوتاه داشت، معمولاً زمان لانچ رسیده است. اگر دو یا بیشتر «خیر» بود، فهرست کارهای بعدی شما روشن است و دیگر نیازی به حدس و دلهره نیست. البته استثناها هم هست؛ برای محصولی که در یک رویداد محدود و تاریخ‌دار معرفی می‌شود، ممکن است معیار چهارم وزن کمتری داشته باشد. ولی در بیشتر موارد، اگر به یکی از این پنج مورد پاسخ منفی می‌دهید، لانچ زودرس برایتان گران تمام می‌شود.
یک نکته آخر درباره دلهره: هیچ بنیان‌گذاری با احساس «کاملاً آماده‌ام» لانچ نمی‌کند. آن احساس هرگز نمی‌آید. چیزی که می‌آید، شواهد است؛ اینکه پنج کاربر ناآشنا مسیر را رفته‌اند، زیرساخت زیر بار نمرده، داده‌ها ثبت می‌شوند، پنجاه نفر منتظرند و تیم روی هفته اول توافق کرده است. وقتی این شواهد را دارید، تردید باقی‌مانده دیگر نشانه ناآمادگی نیست؛ همان ترس عادی هر آغاز است و باید با آن زندگی کرد.
اگر محصولی دارید که به لانچ نزدیک می‌شود، آن را در لانچینو ثبت کنید تا کاربران و بنیان‌گذاران دیگر ببینند، رای بدهند و بازخورد بگذارند. و اگر هنوز در مرحله آماده‌سازی هستید، مقاله چک‌لیست ۱۰ گام حیاتی قبل از لانچ نسخه دوم محصول را هم از دست ندهید.