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