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