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