MVP چیست؟

با اینکه بیش از یک دهه پیش در کتابی با عنوان The Lean Startup که توسط Eric Ries نوشته شده بود اصطلاح Minimum Variable Product یا به اختصار MVP رواج پیدا کرد اما هنوز هم سردرگمی‌هایی درباره‌ی چیستی‌ها و چرایی‌های آن وجود دارد. MVP و موارد دیگری که برای اعتبارسنجی ایده‌ها استفاده می‌شوند، برخی افراد را سردرگم کرده است. برای مثال prototypeها را در نظر بگیرید، دیگران فکر می‌کنند چیزی جدید و نابالغ است و آن را معادل MVP می‌دانند که این کاملا نادرست است. در این مقاله شما با مفهوم MVP آشنا خواهید شد و مقایسه‌ی آن با برخی از روش‌های اعتبارسنجی دیگر را مطالعه خواهید کرد.

در وهله‌ی اول برای درک عمیق MVP و مفهوم آن درباره‌ی چرایی اعتبارسنجی ایده‌ها صحبت خواهیم کرد، سپس سعی داریم برخی روش‌های اعتبارسنجی دیگر مانند Proof of Concept و Prototype را از یکدیگر متمایز کنیم. پس از آن به دلایلی خواهیم پرداخت که پس از گذشت ۱۰ سال هنوز واژه‌ی MVP برای برخی افراد درک نشده باقی مانده است و در ادامه‌ی آن به چند نمونه از رویکردهای مختلف MVP خواهیم پرداخت. همچنین در انتهای مقاله به‌طور مختصر به MLP (Minimum Loveable Product) می‌پردازیم.

روش‌های اعتبارسنجی ایده

طبق گفته‌ی Clayton Christen که استاد تجارت دانشگاه Harvard است، سرانجام حدود ۹۵% از محصول‌هایی که هر ساله به بازار عرضه می‌شوند، خارج شدن از بازار است. این اتفاق به ندرت به دلیل عدم پشتکار، مهارت یا شانس است اما خود محصول و ویژگی‌‌های آن دلایل اصلی در عدم موفقیت یک تجارت هستند:

• در مرحله‌ی اول نیازی به داشتن محصول نبود.
• نیاز مشتریان قبل از ورود محصول به بازار از بین رفته است.
• هزینه و زمان ساخت محصول بیش از پیش‌فرض‌های اولیه بود.
• اگرچه نیاز بازار برآورده شده اما انتظار مشتریان برآورده نشده است.

فرضیه‌ها قاتل اصلی محصول‌های جدید هستند و از همه بدتر این است که تمام ایده‌های ما با فرضیه‌ها شروع می‌شوند. ما فکر می‌کنیم مشتریان به چه چیزی نیاز دارند، ساخت یک محصول جدید چقدر طول می‌کشد، به چه مقدار هزینه‌ی اولیه نیاز دارد، ROI (Return on Investment) یا همان بازگشت سرمایه‌ی اولیه در چه مدت انجام می‌شود و در کل با این فرضیه‌ها تمام محصول در معرض خطر بالایی قرار می‌گیرد.

به همین دلیل باید پیش‌فرض‌هایی را که ارائه می‌دهیم شناسایی و آن‌ها را دائما بررسی کنیم، یعنی از زمان شروع ساخت یک محصول جدید تا اوسط توسعه‌ی آن باید فرضیه‌ها را بررسی و تایید کنیم. سه ابزار معمول برای تایید ایده‌ها، فرضیه‌ها و همچنین جمع‌آوری بازخورد‌ها وجود دارد:

1. Proof of Concept
2. Prototype
3. MVP

این عبارت‌ها به دلیل شباهت‌هایشان باعث گیج شدن افراد می‌شوند زیرا در نگاه اول یک مفهوم را می‌رسانند اما باید عمیق‌تر آن‌ها را بررسی کرد تا بتوانید تفاوت‌های اصلی را بشناسید.

مفهوم PoC (Proof of Concept)

هدف: امکان‌پذیر بودن ایده را از نظر فنی بررسی می‌کند.

هدف اصلی PoC این است که آیا این ایده از نظر فنی امکان‌پذیر است و آیا ارزش پیگیری دارد؟ این درمورد کشف چیزهایی نیست که کاربران از شما می‌خواهند یا به آن نیاز دارند، یا اینکه آیا تقاضایی برای آن وجود دارد یا اگر نیست دنبال کردن این ایده از نظر فنی امکان‌پذیر و ارزشمند است یا خیر؟

به‌هرحال شما نمی‌خواهید در ایده‌ای غرق شوید که عملیاتی کردن آن چندین برابر سختی و هزینه‌های بیشتری نسبت به آنچه که در ابتدا انتظار می‌رفته است، داشته باشد. یک آزمایش سریع برای توسعه‌ی نسخه‌ی بتا می‌تواند شما را از خطرناک‌ترین فرضیه‌های موجود در فناوری یا تجزیه و تحلیل‌های احتمال‌های فنی نجات ‌دهد. PoC معمولا با کاربران نهایی به اشتراک گذاشته نمی‌شود و به عنوان ابزار داخلی مورد استفاده قرار می‌گیرد.

ویژگی‌های اصلی PoC:

• خطر درگیر شدن با پروژه‌های ناممکن را کاهش می‌دهد.
• برای داشتن MVP و Prototype بهتر، استفاده از PoC توصیه می‌شود.
• گاهی اوقات نیاز است تا PoC پروژه با سرمایه‌گذاران به اشتراک گذاشته شود.
• هزینه‌ی کمتری دارد.
• میزان تقاضا در PoC بررسی و آزمایش نمی‌شود.
• در تخمین زدن هزینه‌های پیاده‌سازی کمک می‌کند.
• کوتاه مدت است.

مفهوم Prototype

هدف: یک روش ارزان قیمت برای جمع‌آوری بازخوردها است.

Prototype به ما نشان می‌دهد که محصول پس از تولید چگونه خواهد بود. درحالی که PoC به موارد مرکزی‌تر تمرکز دارد، Prototype بیشتر به UI/UX مربوط می‌شود. هدف ساخت مدلی ارزان و ساده برای آزمایش ایده و اعتبارسنجی قبل از سرمایه‌گذاری در محصول واقعی است.

تقریبا هرچیزی می‌تواند یک Prototype باشد، از وایرفریم‌های روی کاغذ گرفته تا نسخه‌ی دیجیتالی محصول یا حتی ارائه پاورپوینتی محصول را می‌توانیم Prototype محسوب کنیم. توانایی به‌دست آوردن بازخورد زودهنگام و یافتن مشکل‌های اولیه‌ ایده ممکن است عاملی تعیین کننده در موفقیت محصول باشد.

ویژگی‌های اصلی Prototype:

• کوتاه مدت است.
• بر ایده کلی و قسمت‌های UI/UX متمرکز شده است.
• می‌توان کل محصول یا فقط بخشی از آن را در Prototype قرار دهیم.
• امکان جمع‌آوری بازخورد اولیه را فراهم می‌کند.
• کم هزینه است.
• به میزان زیادی خطر تولید محصول‌های ناخواسته را کاهش می‌دهد.

مفهوم MVP (Minimum Variable Product)

هدف: برای پیاده‌سازی یک محصول ارزان قیمت در سریع‌ترین زمان ممکن و تایید فرضیه‌ها و جمع‌آوری بازخوردهای کاربران می‌توانیم از MVP استفاده کنیم.

MVP یک نسخه‌‌ از محصول جدید است که به تیم امکان می‌دهد حداکثر میزان شناخت از مشتری را با صرف کمترین تلاش، کسب کند.

Eric Ries, The Lean Startup

MVP بیشتر درباره ساخت نسخه‌ای از محصول است که در بازار موجود می‌شود و کاربران واقعی می‌توانند با آن تعامل داشته باشند. ایده اصلی این است که در هنگام ارائه قابلیت‌های پیشنهادی به کاربران نهایی به منظور تامین هرچه بیشتر نیازهای بازار، حتی الامکان برنامه‌ی ما ویژگی‌های کمتری را شامل شود.

MVP حلقه‌‌ای از ساخت یک محصول است، ارزیابی و آزمایش فرضیه‌ها را در نظر بگیرید، بازخوردهای کاربران را دریافت خواهید کرد، آن‌ها را خواهید شناخت، به ندرت محصول خود را بهبود می‌بخشید و این چرخه بارها و بارها تکرار خواهد شد.

تمرکز بر توسعه‌ی نسخه‌ی MVP برنامه به جای توسعه‌ی کامل آن، خطر تولید یک محصول ناخواسته را کاهش می‌دهد و این امکان را در اختیار شما قرار می‌دهد تا با هزینه‌ی کم واکنش بازار نسبت به محصول خود را بسنجید.

آزمایش محصول در بازار واقعی مسئله‌ی مهمی است، حتی ممکن است تایید شدن Prototype شما به این دلیل باشد که مردم عمدتا نمی‌دانند چه می‌خواهند اما فکر می‌کنند که می‌دانند.

ویژگی‌های اصلی MVP:

• این نسخه از برنامه مدت زمان قابل توجهی در بازار حضور خواهد داشت.
• هزینه‌ی متوسط (گران‌تر از Prototype و ارزان‌تر از پیاده‌سازی کامل محصول).
• محصولی واقعی که در بازار قرار داده می‌شود.
• ساخت نسخه‌ی MVP اجازه می‌دهد تا فرضیه‌ها را بدون ساخت کامل محصول تایید و بررسی کنید.

انواع MVP

ممکن است ایده‌ی MVP مانند نسخه‌ای از محصول به نظر برسد که از بیشتر ویژگی‌ها محروم شده است. گرچه این مورد در هسته‌ی اصلی برنامه درست است اما روش‌های مختلفی وجود دارد و برای راه‌اندازی نسخه‌ی MVP، پیاده‌سازی نکردن ویژگی‌ها تنها راه موجود نیست. بیایید به چند نوع MVP نگاهی بیندازیم تا نحوه‌ی کار آن‌ها را درک کنیم:

روش Wizard of Oz

گاهی اوقات پیاده‌سازی ایده‌های جدید نیاز به تلاش بسیار زیادی دارد. علاوه‌بر اینکه نیمی از بودجه را باید برای توسعه‌ی ویژگی‌های اصلی صرف کنیم، داستان آنجا ترسناک می‌شود که باید برنامه را مجددا از نو بسازیم. راه حل این است که ابتدا کارها را به صورت دستی انجام دهید، بدون اینکه کاربر از آن مطلع باشد و بر اساس آن تصمیم بگیرید که آیا تقاضا وجود دارد یا خیر؟

برای مثال تصور کنید که می‌خواهید برنامه‌ای بسازید که صاحبان حیوانات را با کسانی که شغلشان گردش سگ‌ها است آشنا می‌کند. شما مطمئن نیستید که آیا تقاضا وجود دارد یا خیر، بنابراین به جای سرمایه‌گذاری در توسعه‌ی الگوریتم‌های منطبق‌سازی، سیستم‌های پرداخت و دیتابیس، با ساخت یک وبسایت ساده موارد را به صورت دستی انجام دهید. تاریخ‌ها را بررسی کنید، پیام‌های کوتاه برای تایید کاربران ارسال کنید و ورودی‌ها را در سیستم تغییر دهید. ایده این است که کاربر نهایی نباید بداند که این کارها توسط انسان به‌جای ماشین انجام می‌شود.

اگر رمان خوانده باشید می‌دانید چرا این اسم را برای این نوع MVP در نظر گرفته‌اند و اگر نخوانده‌اید باید گفت که wizard of oz یک کماندار قدیمی است که همیشه به دور از جنگ فقط کمان خود را می‌کشد و تیر را به دشمن پرتاب می‌کند. دقیقا مانند موردی که ما در این برنامه پیاده‌سازی کردیم. این روشی عالی برای جمع‌آوری بازخورد و تایید ایده‌ها است که باید قبل از سرمایه‌گذاری در یک نرم‌افزار گران قیمت انجام دهید.

روش Concierge

این روش با یک تفاوت اساسی شبیه Wizard of Oz است. تفاوت هم در این است که کاربر نهایی می‌داند از یک انسان در حال سرویس گرفتن است. در این شرایط شما مانند یک دربان هتل به میهمانان خود سرویس می‌دهید. در اصل خود شما محصول هستید.

وقتی ارزش‌های پیشنهادی ایده اصلی را در ذهن خود داشته باشید و هنوز درباره جزئیات مطمئن نیستید، این مورد می‌تواند روش خوبی باشد. داشتن توانایی تعامل با مشتریان ممکن است ورودی‌های زیادی به شما بدهد. food on the table یکی از سرویس‌هایی است که می‌تواند یک مثال برجسته برای این بخش باشد. بنیان‌گذار شرکت می‌خواست سرویسی ایجاد کند که مدل غذایی افراد را جمع‌آوری کند و لیست‌های پیشنهادی را به همراه کوپن تخفیف برای مشتریان ارسال کند.

او برای پیاده‌سازی مدل MVP تصمیم گرفت که خودش با هر مشتری صحبت کند، درمورد مغازه‌ها، کوپن‌ها تحقیق و آن‌ها را برای مشتریان ارسال کند. انجام دستی این کار به او بازخوردهای مهمی داد و توانست ایده خود را بررسی و تایید کند. آن‌ها متوجه شدند اکثر مشتریان بر اساس موقعیت مکانی خود از مغازه‌های مختلف بازدید می‌کنند و برندهای خاصی را در اولویت خود قرار می‌دهند. پس قبل از سرمایه‌گذاری در نرم‌افزاری که پس از تایید ایده مجددا نیاز به بازسازی داشت، ایده را خودشان پیاده‌سازی کردند.

مقایسه روش‌های Wizard of Oz و Concierge

این دو نوع MVP بسیار شبیه یکدیگر هستند اما در عین حال تفاوت دارند. هر دو آن‌ها روش‌های جالبی هستند اما باید مرزی برای هرکدام مشخص کنیم زیرا بسیاری افراد آن‌ها را با هم اشتباه می‌گیرند که یک اشتباه بزرگ است.

به بیان ساده شما برای آزمایش فرضیه‌ها از Wizard of Oz استفاده می‌کنید درحالی که با Concierge تلاش می‌کنید ایده‌های جدیدی به‌دست آورید. اگر شما یک ایده برای آزمایش دارید می‌توانید از Wizard of Oz استفاده کنید، اگر این کار به خوبی انجام شود کاربر نمی‌تواند تفاوتی میان محصول نهایی و MVP آن احساس کند. البته جدا از این واقعیت که انجام کارها به صورت دستی زمان بیشتری نسبت به کامپیوتر از شما خواهد گرفت.

حال اگر نیاز به بازخوردهای زیادی دارید می‌توانید روش Concierge را امتحان کنید. برقراری تعامل واقعی با مشتریان راهی بسیار عالی برای شناخت مشتریان و نیازهای آن‌ها است.

بااین‌حال به یاد داشته باشید که در روش Concierge به دلیل تعامل با مشتریان خود، ارزش بالاتری همراه با محصول نهایی ارائه می‌دهید. حتی ممکن است مردم ترجیح دهند که با شما درمورد غذاهایی که دوست دارند صحبت کنند و لیست غذاهای پیشنهادی را از شما بگیرند، این لزوما به این معنی نیست که مشتریان تعامل با نرم‌افزار را دوست دارند. به همین دلیل حتی اگر ایده شما عالی باشد نباید از Concierge برای آزمایش فرضیه نهایی خود استفاده کنید زیرا ممکن است بازخوردها آن چیزی نباشد که ممکن است در نرم‌افزار دریافت کنید.

روش Piecemeal

حتی اگر نرم‌افزار سفارشی‌سازی شده ایده بهتری باشد اما برای تایید یک فرضیه و جمع‌آوری بازخورد زودهنگام، استفاده از راه‌های موجود یک تصمیم عاقلانه است. نمادین‌ترین نمونه برای Piecemeal را می‌توانیم فروشگاه Groupon بدانیم.

شرکتی که امروزه می‌شناسیم یک اکوسیستم عظیم با سیستم‌های پرداخت‌ یکپارچه، سیستم‌‌های پستی، تولید کوپن تخفیف و بسیاری از قابلیت‌های دیگر است اما آن‌ها از ابتدا به این شکل نبودند. آن‌ها از راه حل‌های موجود استفاده کردند و آن راه حل‌ها را به مرور زمان کنار هم قرار دادند تا به تصمیم نهایی برسند.

آن‌ها از WordPress برای مدیریت سایت خود استفاده کردند و پست‌های این CMS برای آن‌ها نقش پیشنهاد به مشتری را داشت. کوپن‌ها توسط FileMaker تولید می‌شدند و ارسال خودکار ایمیل‌ها توسط Apple Mail مدیریت می‌شد. حتی با اینکه کنار هم قرار دادن راه حل‌های مختلف یک راه حل مقیاس‌پذیر و طولانی مدت نیست اما برای جذب مشتری‌های اولیه و جمع‌آوری بازخورد از مشتریان کافی بود.

روش Smoke-test/Landing Page

در این روش یک محصول کاربردی ارائه نمی‌شود. ایده ایجاد یک وبسایت ساده است. این وبسایت ساده که اغلبا Landing Page است، ارزش‌های پیشنهادی محصول را توصیف می‌کند و دارای یک دکمه‌ی CTA (Call To Action) برای خرید سرویس است.

کاربر پس از کلیک بر روی دکمه‌ی CTA یک پیغام دریافت می‌کند که محصول هنوز در دسترس نیست اما می‌توانید ایمیل خود را وارد یا حتی محصول را پیش‌خرید کنید تا زمانی که موجود شد به او اطلاع دهند. با این روش می‌توانیم مشتریان بالقوه را ارزیابی کنیم و فرضیه‌ی نیاز به این محصول در بازار را بررسی خواهیم کرد.

برخی بحث‌ها در رابطه با این روش وجود دارد زیرا شما محصولی ندارید و زیاد شبیه MVP نیست. بااین‌حال معیارهایی که به ما اجازه می‌دهند مشتریان یک محصول جدید را بشناسیم، جمع‌آوری می‌کند.

جمع‌بندی انواع MVP

شما در این مقاله با چهار روش مختلف برای تایید فرضیه‌های خود به کمک MVP آشنا شدید. این‌ها تمام روش‌های موجود MVP نیستند و برعکس این تعداد محدود، امکانات بی‌شماری برای آزمایش محصول‌هایتان تا زمانی که بتوانید با کمترین تلاش به حداکثر میزان شناخت از مشتریان خود برسید، وجود دارد.

چگونه MVP خود را پیاده‌سازی کنیم؟

اگر شما متوجه شده باشید که MVP چیست، چه ویژگی‌هایی را در اختیار شما قرار می‌دهد، تفاوت آن با سایر روش‌های اعتبارسنجی را بدانید و حال تصمیم گرفته‌ باشید از آن استفاده کنید، این سوال برای شما به‌وجود می‌آید که چگونه شروع کنید؟

شما قبل از اینکه تصمیم بگیرید یک چیز کوچک بسازید، به یک روش تفکر دقیق نیاز دارید. با رویکرد غلط به MVP ممکن است همه‌ی مزایای مورد نظر را به دست بیاورید اما فقط پول و وقت خود را هدف می‌دهید.

شما هنگام برنامه‌ریزی برای محصول اغلبا ده‌ها ایده در ذهن خود دارید که احتمالا بسیاری از آن‌ها را دقیقا نمی‌دانید که چه هستند. یکی از ساده‌ترین رویکردهای اولیه در پیاده‌سازی MVP پرسیدن سوال‌های اصلی از خودتان است:

• پرخطرترین چیزی که فرض می‌کنید، چیست؟ این معمولا ارزش اصلی شما است که می‌توانید با آن بازی را به نفع خودتان تغییر دهید. اگر این کار به خوبی انجام شود، شما در بازار موفق می‌شوید و اگر این چنین نشد، کل محصول بی‌ارزش است. اگر قبلا این کار را انجام نداده‌اید، بهتر است ایده‌های خوب خود را در یک جایی بنویسید تا بعدا آن‌ها را ارزیابی و بررسی کنید.
• کوچک‌ترین تجربه‌ای که می‌توانیم مورد آزمایش قرار دهیم چیست؟ حال به این سوال پاسخ بدهید که چگونه می‌توانید بدون سرمایه‌گذاری طولانی مدت و میلیون‌ها دلار هزینه، ایده خود را تایید کنید؟ به یاد داشته باشید که شما فقط می‌خواهید خطرناک‌ترین و مهم‌ترین فرضیه‌های خود را تایید کنید و سپس بر مبنای آن‌ها، ایده خود را توسعه دهید. بنابراین اگر فرض شما این است که مردم توانایی پرداخت برای گردش حیوانات‌شان را دارند پس نیازی به نقشه، سیستم ردیابی و ویژگی‌های فانتزی نخواهید داشت. حتی شاید تا زمانی که ایده را تایید نکنید، به برنامه هم نیازی نداشته باشید.

همانطور که می‌خواهید MVP ایده‌تان را بسازید، اجازه دهید این قانون ساده کافی باشد: هر ویژگی، فرایند یا تلاشی را که مستقیما به شناخت شما کمک نمی‌کند، حذف کنید.

 Eric Ries, Lean Startup

هنگامی که روند پیاده‌سازی MVP را شروع می‌کنید، ممکن است متوجه شوید که این کار دشوارتر از آن که است که در ابتدا انتظارش را داشته‌اید. ساخت MVP را می‌توان یکی از مواردی دانست که درک آن آسان است اما تسلط بر آن دشواری‌های خود را دارد، به همین دلیل کمک گرفتن از متخصصان عاقلانه به‌نظر می‌رسد.

چرا MVP به یک اصطلاح معروف تبدیل شده و چرا باید یک نسخه‌ی MVP از برنامه بسازیم؟

اگر شما در حال توسعه‌ی محصولی هستید احتمالا بیش از هزاران دفعه اصطلاح MVP را شنیده‌اید. به نظر می‌رسد اخیرا مشتریان، سهام‌ داران، طراحان، صاحبان محصول و … با این اصطلاح دیوانه شده‌اند. این اتفاق کاملا قابل درک است زیرا شما با دنبال کردن هدف‌های MVP به مزایای بسیار زیادی دست پیدا خواهید کرد:

زمان حضور در بازار

زمان حضور در بازار یکی از مهم‌ترین عوامل تعیین کننده موفقیت یا عدم موفقیت محصول است. زمان تولید بلند مدت، یکی از بزرگترین موانعی است که در هنگام تولید و سوددهی یک محصول جدید باید آن را در نظر داشته باشید (منبع: BCG نظرسنجی جهانی نوآوری در سال ۲۰۱۵).

به این فکر کنید که بازار به‌طور پویایی در حال تغییر است، روزانه ده‌ها محصول جدید به بازار عرضه می‌شود و روند تغییر می‌کند. ممکن است چیزی که امروزه موضوع هیجان‌انگیزی به‌نظر می‌رسد در عرض یک سال کاملا از بازار کنار برود، با این وجود برخی اوقات مردم تصمیم می‌گیرند سال‌ها برای ساخت یک محصول تجربی زمان صرف کنند فقط برای اینکه در آخر متوجه شوند دیگر نیازی به آن محصول نیست.

اگرچه ساخت یک محصول کاملا جدید ممکن است به سال‌ها زمان نیاز داشته باشد اما ساخت یک نسخه‌ی MVP معمولا چند هفته الی چند ماه بیشتر زمان نخواهد برد و به شما امکان می‌دهد قبل از از بین رفتن موج نیازهای بازار، نیاز فعلی مشتریان را برآورده کنید.

ساخت چرخه‌ی اعتبارسنجی، اندازه‌گیری و یادگیری

تجربه‌ی کاربری (UX) اهمیت بالایی دارد. ساخت سریع یک MVP به شما امکان می‌دهد که به سرعت بازخوردهای واقعی کاربران را دریافت کنید. می‌توانید ببینید که آن‌ها چه کار می‌کنند و چه چیزی از همان ابتدا بی‌فایده است. به‌هرحال شما در حال ساخت محصول برای کاربران نهایی خود هستید، آیا راهی بهتر از اینکه آن‌ها را در تولید محصول از همان ابتدا درگیر کنید و مطمئن شوید که محصول شما انتظارهای آن‌ها را برآورده کرده است، وجود دارد؟

علاوه براین همان‌طور که قبلا گفتیم، مردم تمایل ندارند که بدانند دقیقا چه می‌خواهند بلکه فقط باور دارند که می‌دانند چه چیزی را می‌خواهند. راه‌اندازی یک نسخه‌ی MVP به شما امکان می‌دهد تا ایده‌های خود و نیازهای کاربران را سریع‌تر ارزیابی کنید.

ریسک و هزینه‌ی کمتر

تمرکز بر مهم‌ترین ارزش‌هایی که تولید می‌شوند و کاهش زمان ورود به بازار نه تنها شانس موفقیت را تا حد زیادی افزایش می‌دهد بلکه باعث کاهش هزینه‌های کل توسعه و خطرهای پروژه نیز می‌شود. راه‌اندازی نسخه‌ی MVP به اندازه‌ی ۵ الی ۱۰ درصد از هزینه‌ی مورد نیاز برای ساخت یک محصول کامل را نیاز دارد و می‌تواند از روز اول شروع به درآمدزایی کند.

شما خطر اینکه شاید مشتری را به اشتباه شناخته باشید، کاهش می‌دهید و اگر نیازهای مشتری را اشتباه حدس زده باشید، سریعا می‌توانید موضع خود را تغییر دهید. امکان تولید کالا در عرض چند هفته خطر تغییرهای بازار را نیز کاهش می‌دهد.

در بدترین حالت ممکن اگر کالای شما متناسب با بازار و نیازهای مشتری نباشد، به‌جای هزینه‌ی سال‌ها تولید محصول فقط ۵ الی ۱۰ درصد از هزینه‌ی ساخت یک محصول کامل را از دست می‌دهید.

از بین بردن ایده‌هایی که به نظر خوب می‌رسند

یکی از شناخته شده‌ ترین تله‌های توسعه‌ی محصول، وابستگی بیش از حد شما به محصول است. اگر سال‌ها برای توسعه‌ی ایده‌ی خود زمان صرف می‌کنید، این احتمال وجود دارد که حتی اگر ۹۰% از بازخوردهای کاربران منفی باشد باز هم شما به این باور داشته باشید که محصول شما به تغییرهای زیادی نیاز ندارد.

پس از همه‌ی این‌ها، وقت، پول، انرژی و احساسات زیادی برای تولید محصول خود صرف کرده‌اید. حال این سوال پیش می‌آید که چگونه می‌توانید ایده خود را تغییر دهید؟ با ساخت یک نسخه‌ی MVP از محصول می‌توانید ایده‌ها را به سرعت قبل از رویارویی با مشکل‌ها اعتبارسنجی کنید.

اگر تعداد کمی از منابع را برای نسخه‌ی MVP خود سرمایه‌گذاری کرده باشید، در صورت عدم موفقیت تمایل بیشتری به انتخاب درست پیدا می‌کنید. هرچه بیشتر بر روی محصول خود کار می‌کنید، وابستگی بیشتری به آن پیدا می‌کنید بنابراین تصمیم‌های احساسی بیشتری می‌گیرید که معمولا اشتباه هستند.

شانس راه‌اندازی محصول با هزینه‌ی کم

توسعه‌ی نرم‌افزار آسان نیست اما نباید مانع از تغییر جهان و به چالش کشیدن وضعیت موجود مبتکران شود. از آنجا که ساخت نسخه‌ی MVP از محصول، خطرهای عمومی ساخت و تولید یک محصول جدید را کاهش می‌دهد، باعث ایحاد جذابیت بیشتری برای سرمایه‌گذاران بالقوه نیز می‌شود.

برای شروع به مقدار کمی پول نیاز دارید، بنابراین جمع‌آوری سرمایه برای ساخت نسخه‌ی MVP در مقایسه با جمع‌آوری سرمایه برای توسعه‌ی کل محصول مانند یک قطعه کیک درمقابل کل کیک است. همچنین پس از راه‌اندازی نسخه‌ی MVP می‌توانید سریعا به درآمدزایی برسید.

محصول موجود است، گرچه که هنوز همه‌ی ویژگی‌‌های برنامه‌ریزی شده را ندارد اما در حال حاضر ارزش‌های مورد نیاز را به مشتریان ارائه می‌دهد، ارزشی که مشتریان برای آن هزینه می‌کنند. اکنون چه راه حلی برای یافتن شرکا و سرمایه‌گذاران آسان‌تر است؟ به نظر شما سرمایه‌گذاران بر روی Business plan که نیاز به بودجه کامل دارد سرمایه‌گذاری می‌کنند یا بر روی محصولی که در بازار فعال است و فقط نیاز به بهبود دارد؟ MVP به ما امکان می‌دهد ایده‌های بزرگ را با بودجه‌ی کم محقق کنیم.

چگونه MVP یکی از پرسو‌تفاهم‌ترین کلمه‌ها در تولید محصول است؟

MVP یک کلید واژه کاملا مشهور است و مسئله اینجاست که بسیاری از مردم به هرکاری که انجام می‌دهند برچسبی با عنوان MVP می‌زنند زیرا احساس مد روز بودن به آن‌ها دست می‌دهد. حتی برخی افراد یک برنامه‌ی چند ساله برای توسعه‌ی محصول خود در نظر دارند اما هنوز هم در کنار محصول خود از اصطلاح MVP استفاده می‌کنند. به نظر می‌رسد که MVP در حال تبدیل شدن به یک کلمه‌ی جدید برای یک محصول جدید است که فقط سردرگمی بیشتری ایجاد کرده است.

اگر در حال ساخت یک نسخه‌ی حداقلی از محصول خود هستید تا فرضیه‌ها را تایید کنید و سپس بر اساس شناخت خود مراحل بعدی را تعیین کنید، این MVP است. اگر قبلا یک محصول تعریف شده‌ای دارید که انعطاف کمی برای هرگونه تغییر دارد، این فقط یک نسخه‌ی اولیه نیست و به عنوان اولین نسخه‌ی برنامه‌ی اصلی شما شناخته می‌شود.

MLP (Minimum Lovable Product) چیست؟

آیا MLP را می‌توان سطح بعدی MVP دانست؟ درحالی که تا چند سال پیش MVP برای توسعه‌ی محصول در حال پیشرفت کافی بود اما امروزه اعتقاد بر این است که این رویکرد برای محصول کافی نیست.

زمانی که یک برند جدید در بازار نوآورانه سال ۲۰۲۰ وارد می‌شود، با بیش از ۱۰۰ هزار برنامه‌ی جدید که هر ماه در Google Play عرضه می‌شوند، در رقابتی بسیار سنگین است و احتمال موفقیت در این بازار بسیار کم است. شرکت‌ها اغلب تصمیم می‌گیرند که ایده موجود را با نوعی مزیت رقابتی بهبود ببخشند و آن را تغییر دهند که ممکن است راه‌اندازی نسخه‌ی MVP گزینه‌ی مورد توجه آن‌ها نباشد. آیا می‌توانید از Spotify یک نسخه‌ی حداقلی بسازید؟ آیا می‌توانید بسیاری از ویژگی‌های UX را پیاده‌سازی نکنید؟ احتمالا جواب شما خیر است.

در چنین شرایطی ممکن است یک محصول MLP مفید باشد. در اینجا هدف فقط تایید برنامه نیست بلکه باعث می‌شود مشتریان شما این محصول را دوست داشته باشند. شما با تمرکز بر روی مجموعه‌ای از مهم‌ترین ویژگی‌ها، عملکرد و همچنین UI و UX، به این نسخه‌ دست پیدا می‌کنید و آن‌ها را تقریبا به کمال می‌رسانید.

اگرچه هنوز نسخه‌ی کامل محصول با تمام ویژگی‌ها در نظر گرفته نشده است اما کافی است تا نسخه‌ی اول برنامه‌ی شما میان هزاران برنامه‌ی موجود در بازار، مشتریان را به خود جذب کند.

جمع‌بندی

همان‌طور که مشاهده می‌کنید، روش‌های مختلفی برای اعتبارسنجی انواع مختلف فرضیه‌ها وجود دارد و موارد ذکر شده در این مقاله فقط برخی از آن‌ روش‌ها هستند. کلاسیک‌ترین‌ها را می‌توانیم PoC برای تایید امکان‌سنجی، Prototypeها را برای جمع‌آوری سریع اطلاعات و MVP را برای سنجش میزان استقبال بازار از محصول و تایید نیاز واقعی مشتریان بدانیم.

هدف نهایی همیشه یکسان است، شما می‌خواهید فرضیه‌ها را در اسرع وقت با کمترین هزینه و زمان تایید کنید. بدون روش‌های اعتبارسنجی مناسب، شما در معرض خطر بسیار بالایی قرار خواهید گرفت که می‌تواند منابع و سرمایه شما را از بین ببرد و نمی‌توانید به درستی در بازار قرار بگیرید.

توسعه‌ی MVP یکی از شناخته شده ترین روش‌ها برای تحویل برنامه‌های موبایلی و وب است که این امکان را برای شما فراهم می‌کند تا سریعا بتوانید با هزینه و ریسک کم از پتانسیل بازار استفاده کنید و اگر به درستی اعتبارسنجی خود را انجام دهید، یک تجربه‌ی باورنکردنی از شناخت بازار و مشتریان به دست خواهید آورد.

در حالی که روش‌های مختلفی برای ساخت نسخه‌ی MVP وجود دارد اما مهم است که تشخیص دهیم نباید برای همه‌ی محصولات جدید از اصطلاح MVP استفاده کنیم. اگر در حال ساخت نسخه‌ی MVP محصول خود هستید ممکن است در این فرایند چندین بار تعریف Eric را از MVP مرور کنید:

MVP یک نسخه از محصول جدید است که حداکثر میزان شناخت معتبر از مشتری را با کمترین تلاش جمع‌آوری می‌کند

منبع: https://tsh.io/blog/mvp-app-and-the-other-validation-methods