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