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