چطور از یک MVP تا سرویس‌دهی به ۱۸۰۰۰ کسب و کار در ماه رسیدیم

اگر تا به حال درگیر شروع یک استارتاپ بوده‌اید یا سعی کرده‌اید محصول جدیدی در یک استارتاپ بسازید، بعید است که در مورد MVP یا «حداقل محصول پذیرفتنی» (ترجمه‌ی Minimum Viable Product) نشنیده باشید و با آن سر و کله نزده باشید. به طور ساده، شما باید محصول خود را با کمترین امکانات اصلی که برای مشتریانتان ارزشمند است عرضه کنید. این روش به شما کمک می‌کند که با گرفتن بازخوردهای سریع از بازار و مشتریان بتوانید برای آینده محصول تصمیم‌گیری کنید. این به شما کمک می‌کند که با کمترین زمان و هزینه ممکن، در مورد افزودن امکانات جدید به محصول، تغیری رویکرد محصول، یا حتی کنار گذاشتن آن تصمیم بگیرید.مشکل کجاست؟ایجاد یک MVP مناسب اکثر اوقات برای بنیان‌گذاران استارتاپ‌ها و مدیران محصول هدفی سخت و پیچیده است. انتخاب امکانات درست برای قرار دادن در MVP و گذاشتن زمان و هزینه کافی (و نه بیش از حد) روی آن، نیاز به تعادل بالایی دارد. اگر امکانات مهیا شده کمتر از حد قابل قبول باشد،‌ یا امکانات درستی برای قرار دادن در MVP انتخاب نشده باشد،‌ شما نمی‌تواندی مشکل مشتریان احتمالیتان را حل کنید و عملا در جذب آن‌ها ناموفق می‌مانید. این باعث می‌شود که در غیاب حداقل تعداد کاربرهای لازم،‌ نتوانید بازخورد لازم را بگیرید تا برای آینده محصول تصمیم‌گیری صحیح کنید. از طرف دیگر، افزودن امکانات بیش از حد هم باعث می‌شود که از حالت MVP خارج شوید و محصول نسبتا بزرگ و پیچیده‌ای را عرضه کنید که بیشتر سرمایه (و مهمتر از آن) زمان با ارزش شما را گرفته،‌ و حتی ممکن است مطلوب مشتریان احتمالی هم نباشد. اگر برای ورود به بازار بیش از حد زمان صرف کنید،‌ محکوم به شکستید!جمله معروفی از رید هافمن (کارآفرین، سرمایه‌گذار، و هم‌بنیان‌گزار لینکد‌این) هست که می‌گوید: «اگر از نسخه اولیه محصول خود خجالت‌زده نیستید، بیش از حد برای انتشار آن صبر کرده‌اید!» در مدت فعالیت در استارتاپ استدیو ایده‌ران، استارتاپ‌های زیادی از این دست دیدم که با هدف انتشار یک محصول کامل و بی‌نقص، انقدر از انتشار محصول موجودشان را عقب انداخته‌اند تا در نهایت شکست خورده‌اند، گاها حتی پیش از این که کسی اسمشان را بشنود. متاسفانه این تیم‌ها منابع خود را برای افزودن امکانات اغلب نالازم به محصولشان خرج می‌کردند. در نتیجه خیلی از آن‌ها یا پیش از انتشار محصول شکست می‌خوردند و یا محصول «کامل»ی را منتشر می‌کردند که کسی نیازی به آن نداشت. بسیاری از این تیم‌ها ایده‌های خوب با پتانسیل بالا داشتند اما نتوانستند یک MVP‌ مناسب بسازند و به خاطر همین، حتی پیش از این که وارد بازار بشوند، محکوم به شکست بودند.یکی از استارتاپ‌هایی که با آن‌ها کار کردیم، در حال تولید محصولی برای مدیریت رزرو زمان مدرسان توسط دانش‌آموزانشان بود. آن‌ها راهکار مناسبی برای حل مشکل داشتند و تیم مناسبی را نیز تشکیل داده بودند. اما هر قدر از آن‌ها خواستیم که محصول خود را منتشر کردند، آن‌ها این کار را به تعویق می‌انداختند، زیرا محصولشان هنوز بعضی سناریو‌های خیلی خاص و نادر را پشتیبانی نمی‌کرد، یا یک دکمه خاص در یکی از صفحات، کد رنگ درستی نداشت (این مثال اصلا اغراق شده نیست!). نتیجه؟ پیش از این که حتی موفق شوند محصول خود را به بازار عرضه کنند، بودجه مالی آن‌ها تمام شد و تیمشان از هم پاشید.مورد دیگر،‌ استارتاپی بود که برای دو ماه از انتشار محصولش سر باز می‌زد،‌ چون صفحه معرفی محصول در وبسایتشان طراحی ایده‌آل را نداشت. البته در نهایت مشتریان زیادی هم موفق به دیدن این صفحه و طراحی آن نشدند، چون این استارتاپ هم پیش از این که بتواند مشتریانش را جذب کند شکست خورد.از سوی دیگر، یکی از مشتریان ما که یک موسسه آموزش موفق و بزرگ است، تصمیم گرفت محصول جدیدشان در زمینه آموزش آنلاین را در حالی که تنها مراحل خیلی ابتدایی آن آماده بود منتشر کند. در این مرحله کاربران تنها می‌توانستند در سیستم ثبت‌نام کنند، لیستی از رویدادها ببینند، و رویداد مورد نظرشان را بخرند. این تنها ۵٪ از برنامه‌ای بود که برای ساخت محصول پیش‌بینی شده بود. با این وجود، با این که محصول مشخصا ناقص بود و حتی مشکلات زیادی از نظر رابط کاربری و... داشت، موفق شد تنها در همان ماه اول چند هزار کاربر جذب کند. آن‌ها موفق شدند با استفاده از بازخوردهای همین کاربرها برنامه‌های خود برای توسعه محصول را بهبود دهند و در نهایت وقتی محصول به مراحل اصلی رسید، نتایج حتی از تخمین‌های اولیه خودشان نیز بسیار موفقیت‌آمیزتر بود.با این صحبت‌ها، چطور می‌توانیم یک MVP مناسب طراحی کنیم که به ما برای ساخت یک محصول موفق کمک کند؟ مثل خیلی جاهای دیگر، اینجا هم راه سخت برای یادگیری، تجربه است و راه راحت‌تر‌، استفاده از تجربیات دیگران. برای همین من سعی می‌کنم که از تجربیات خودمان در فرمالو و این که چطور توانستیم شرکت خود را بر پایه یک MVP مناسب بسازیم برای شما بگویم.فرمالو یک پلتفرم جمع‌آوری و تحلیل اطلاعات مشتریان است که تا به حال اطلاعات (در زمان نوشتن این مطلب) ۳ میلیون کاربر یکتا را تحلیل کرده و ماهانه ۱۸۰۰۰ کسب و کار از امکانات مختلف آن برای جمع‌آوری، تحلیل، و ارایه اطلاعات مشتریانشان استفاده می‌کنند. فرمالو امکانات زیادی از جمله فرم‌ساز و پلتفرم اطلاعات مشتریان، لیست بلندی از امکانات (که مدام در حال بیشتر شدن هستند)، و افزونه‌های مختلفی را برای مشتریانش فراهم می‌کند. اما کار بسیار کوچکتر از این حرف‌ها شروع کرد.فرمالو ۰.۱اولین نسخه فرمالو در واقع به عنوان یک پروژه جانبی و کوچک کار خود را شروع کرد. ما یک نیاز در بازار و بین گروهی از مشتریان احتمالی حس کردیم، و تصمیم گرفتیم که با استفاده از یک فرم‌ساز ساده آن را بررسی کنیم. بعد یک تحقیق بازار ساده، ما ساده‌ترین راهکار برای حل مشکل را طراحی کردیم. حتی برای انتخاب راهکار فنی محصول نیز زمان زیادی صرف نکردیم و سعی کردیم با امکانات در دستمان و فناوری‌هایی که فعلا به آن مسلط بودیم محصول را بسازیم. تشخیص ما این بود که اگر نسخه اولیه محصول موفق بود و توانست کاربرهای کافی جذب کند، می‌توانیم پروژه رو کامل بازنویسی کنیم.بعد از طراحی اولیه محصول و تعریف امکانات مورد نظر برای MVP،‌ ما تنها در سه هفته نسخه اولیه محصول را ساختیم. به همین سادگی، ما MVPمان را آماده کردیم. با ساده‌ترین امکانات و بدون سخت‌گیری در زیرساخت فنی اولیه.نسخه اولیه فرمالو ساده‌ترین فرم‌سازی بود که می‌توانست به کاربران کمک کندفرمالو ۰.۱ یک فرم‌ساز بسیار ساده بود که تنها از فیلدها و عملکردهای خیلی پایه‌ای پشتیبانی می‌کرد و لیست امکاناتی که به کاربر می‌داد بسیار کوتاه بود. اما ما یک امکان اصلی مورد نیاز مشتریان را در آن قرار دادیم: مشتریان ما می‌توانستند به آسانی و بدون دردسر فرم ساخته شده را در وبسایت خود قرار دهند و ظاهر آن را شخصی سازی. این امکان اصلی بود که مشتریان اولیه ما به آن نیاز داشتند. البته امکانات خیلی بیشتری بود که ما می‌توانستیم در اختیار مشتریان قرار دهیم (کاری که بعدا گام به گام انجام دادیم)، می‌توانستیم محصول کامل‌تری بسازیم، و طراحی ظاهری زیباتری برای آن داشته باشیم. اما هر انجام هر کدام از این‌ها، پیش از این که بدانیم نیازهای اصلی درست تشخیص داده شده‌اند یا نه، صرفا اتلاف وقت و هزینه بود.حتی از بعد فنی محصول، برای ما روشن بود که راهکار و کد فعلی ما، بعد از جذب چند هزار کسب و کار، عملا کارایی خود را از دست خواهند داد و باید جایگزین شود. اما این مساله برای ما خیلی مهم نبود. چطور می‌توانستیم نگران چند هزار کسب و کار باشیم، قبل از این که بتوانیم حتی چند ده کسب و کار را جذب کنیم؟ما کارمان را با یک MVP شروع کردیم تا ببینیم که کاربرانمان چه نیازهایی دارند تا بتوانیم محصول را با استفاده از بازخوردهای آن‌ها کامل‌تر کنیم. این راهکار در عمل بسیار کارا و بهینه بود. زمان زیادی طول نکشید که چندین کسب و کار شروع به استفاده از فرمالو کردند تا فرم‌بسازند و آن را در وبسایتشان قرار دهند. این به ما نشان داد که مشکل اولیه‌ای که تشخیص داده‌ایم درست است، و ما می‌توانیم کارمان را با تمرکز به آن ادامه دهیم. ما یک چرخه بازخورد برای ادامه کار ساختیم. مشتریانمان در مورد امکانات مورد نیازشان به ما بازخورد می‌دادند و ما لیستی از امکانات و تغییرات را تهیه کردیم که در آینده بر اساس اولویتشان به آن‌ها بپردازیم: چه تعدادی از مشتریان به آن نیاز داشتند،‌ ارزشی که برای مشتریان تولید می‌کردند، و نقشی که در چشم‌انداز مورد نظر ما برای محصول داشتند.بعد از گذشت چند وقت و با افزودن تعداد زیادی امکانات به محصول اولیه، ما توانسته بودیم که چند هزار کاربر و چندصد کسب و کار جذب کنیم. حالا ما محصولی کامل‌تر داشتیم. اما مهمتر از آن این بود که ما درک بهتری از بازار هدفمان، مشتریان احتمالی، و نیازهای آن‌ها داشتیم. حالا وقت آن بود با فرمالو ۱.۰ یک جهش رو به جلو داشته باشیم.کارهایی که ما در مرحله اول انجام دادیمتشخیص یک مساله صحیح برای حل کردن.انجام تحقیق بازار کافی.ساختن ساده‌ترین راهکار ممکن برای مساله.ورود به بازار با سرعت بالا.دریافت بازخورد از مشتریان اولیه و ساخت محصول بر اساس آن‌ها.ایجاد یک برنامه هدف با استفاده از بازخوردهای دریافت شده و تحقیقات بازار بیشتر.کارهایی که در مرحله اول انجام ندادیمساخت یک محصول بیش از حد پیچیده.صرف زمان برای ساخت نیازمندی‌هایی که کمتر لازم بود.ادامه کار بدون بازخورد و تحقیق کافی.نگرانی بیش از حد برای مسائل فنی که ممکن بود در آینده دور به آن‌ها بربخوریم.فرمالو ۱.۰حالا که MVP ما با موفقیت عمل کرده بود، ما مشتریان اولیه خود را داشتیم، و به شناخت مناسبی از محصول و بازار رسیده بودیم، وقت آن بود که یه گام بزرگ رو به جلو برداریم. در کسب و کار نمی‌شود همیشه در دایره امن ماند و وقت آن بود که ما یک ریسک حساب شده کنیم. MVP ما کارش را کرده بود (هر چند با امکاناتی که به آن اضافه کرده بودیم دیگر دقیقا MVP حساب نمی‌شد) ولی حالا وقتش بود که با یک به روز رسانی، محصولی کامل‌تر و کاراتر منتشر کنیم تا بتوانیم رشد خوبی داشته باشیم. حالا که ما مشتریان اولیه را داشتیم، و شناخت خوبی از مشتریان احتمالی و بازار هدفمان به دست آورده بودیم، دیگر نوبت نسخه ۱.۰ محصول شده بود.بسیاری از تیم‌ها سعی می‌کنند که کارشان رو از این نقطه شروع کنند. با نسخه ۱.۰. به جای بازخورد مشتریان اولیه، آنها به تحقیقات و نظرسنجی‌ها و فرضیات شخصی خود درباره خواسته‌های مشتریان تکیه می‌کنند. به جای این که ایده‌های خود را با کمترین هزینه ممکنه تست کنند تا ببینند که ارزش سرمایه (زمانی و هزینه‌ای) بیشتر را دارد یا نه، سعی می‌کنند که ایده را با «قدت» وارد بازار کنند. اما واقعیت این است که بازار همیشه برای نادیده گرفتن ایده‌های نامناسب قوی‌تر است.فرمالو ۱.۰ با بازنویسی MVPمان شروع شد. حالا که ما مشتریان اولیه را داشتیم و به شناخت مناسبی از محصول رسیده بودیم، وقتش شده بود که کار را اصولی‌تر انجام دهیم. مشتریان می‌توانند جذب «حداقل»ها بشوند، اما این برای نگه‌ داشتنشان در بلند مدت اصلا کافی نیست. محصول ما طراحی رابط کاربری جدید می‌خواست، امکانات تایید شده‌ی زیادی بودند که باید به آن اضافه می‌شدند، بهبودهای مختلفی در نظر داشتیم، و حتی از نظر فنی هم، حالا که برای رشد بالا برنامه می‌ریختیم، نیاز به بازنگری داشتیم. در نهایت، ما معماری محصول را تغییر دادیم، زبان و فریمورک‌های جدید برای آن انتخاب کردیم، و همه چیز را بازنویسی کردیم.ساخت نسخه ۱.۰ زمان و انرژی خیلی بیشتری از MVPمان لازم داشت، اما حالا این ریسک معقول‌تری بود که می‌توانستیم بپذیریم، چون محصولمان را قبلا آزمایش کرده بودیم. کاربران ما تغییرات جدید را بسیار دوست داشتند، چون چیزهایی که از MVP می‌خواستند را حفظ کرده بودیم و امکانات جدیدی که به آن نیاز داشتند به آن افزوده بودیم. با انتشار محصول جدید، کم کم تعداد کاربران جدید زیادی جذب کردیم و رشد خوبی هم داشتیم.یکی از بزرگترین محاسن جذب تعداد کاربران زیاد به سیستم، قوی‌تر شدن حلقه بازخورد است. کاربرهای جدید بازخوردهای بیشتری به سیستم می‌آورند و ایده‌های جذاب جدیدی هم به شما می‌دهند. چه از طریق درخواست‌هایی که برای امکانات جدید می‌دهند،‌ چه از طریق رفتارشان در سیستم و استفاده‌هایی که از آن می‌کنند. گاها، استفاده خلاقانه کاربران از سیستم ما، حتی خود ما را هم شگفت‌زده می‌کند و ایده‌های جدیدی به ما می‌دهد که قبلا فکرش را هم نمی‌کردیم. این مسائل به ما کمک کرد تا هر روز بیشتر از قبل مشتریان خود را بشناسیم و بتوانیم محصول را در راستای نیازهای آن‌ها گسترش بدهیم.فرمالو ۲.۰ و بعد از آنبعد از انتشار نسخه ۱.۰ ما هیچگاه دست از به روزرسانی سیستم نکشیدیم، و تلاش کردیم هر روز، با شناخت بیشتر مشتریان و نیازهای آن‌ها امکانات جدید را به سیستم اضافه کنیم. این یک چرخه همیشگی است که به ما کمک می‌کند بتوانیم محصول خود را راستای نیازهای مشتری پیش ببریم. ما همیشه لیستی از امکاناتی داریم که بر اساس تحلیل رفتار مشتریان و نیازها و درخواست‌های آن‌ها تهیه شده، مدام بررسی می‌شود (چه از طریق تست کوتاه محصول و چه از طریق تحقیق بازار)، به روز می‌شود، و در نهایت از طریق محصولات و امکانات جدید در اختیار مشتری‌ها قرار می‌گیرد.نگرش MVP اما چیزی نبوده که تنها در مرحله شروع کار از آن استفاده کرده باشیم. حتی امروز، تقریبا تمام امکانات بزرگ سیستم ما از این طریق اضافه می‌شوند. برای تمام امکاناتی که قرار است به سیستم اضافه شود، ما سقف مشخصی از زمان لازم تعیین کرده‌ایم (دو اسپرینت دو هفته‌ای)، و هر ویژگی که قرار است تولید شود باید در این محدوده زمانی به دست مشتری برسد. اگر امکانات یا سیستمی داشته باشیم که در این بازه نتواند پروسه تولید تا رسیدن به مشتری را طی کند، باید ساده سازی شود تا تنها امکانات حیاتی آن باقی بماند. اگر پس از رسیدن به دست مشتری، با استفبال روبرو شد، می‌فهمیم که می‌توانیم زمان بیشتری برای تکمیل این امکانات بگذاریم.مسیر ما تازه شروع شده و راه زیادی داریم که تا بتوانیم به رشد مورد نظر (هم از نظر محصول و هم از نظر اندازه بازار) برسیم، و همیشه تلاشمان را می‌کنیم که بتوانیم به موثرترین و بهینه‌ترین روش در این راه پیش برویم. برای درست رفتن این مسیر هم باید همیشه به چیزی که با آن شروع کردیم وفادار بمانیم: ساده شروع کنیم، بعدا تکمیل کنیم.در نهایت، چه چیزهایی آموخته‌ایم؟همیش به مشتری‌ها گوش کنید: جدا از بازخوردهای مستقیم مشتریان، رفتار آن‌ها هم می‌تواند کمک بزرگی برای درک آن‌ها باشد. چطور از سیستم استفاده می‌کنند؟ از بخش‌های مختلف محصول چقدر استقبال می‌شود؟ چه استفاده‌ای از محصول می‌کنند؟ چه مشکلاتی را با محصول شما حل می‌کنند؟ و ... این مشاهده‌ها و تحلیلی آن‌ها، در کنار تحقیقات بازار صحیح، کمک می‌کند که نیازهای امروز و آینده محصول را بهتر درک کنید. همیشه ساده شروع کنید: چه برای شروع خود محصول و چه برای سرویس‌های جانبی و یا امکانات بزرگتان همیشه ساده شروع کنیم و بعد کامل‌تر کنید. هیچوقت تغییر بزرگی را یک شبه به مشتری تحمیل نکنید، مگر در موارد نادری که به خوبی تاثیرات آن را از قبل بدانید.چابک باشید: در توسعه محصول باید سریع و بهینه عمل کنید. باید بتوانید فاصله بین تشخیص یک نیاز یا مشکل و ارایه راهکار به مشتری را به حداقل برسانید. از طرف دیگر باید بتوانید از وسوسه افزودن امکانات نالازم اجتناب کنید تا محصولتان از کنترل خارج نشود.بیشتر روی مسائل امروز بمانیم و بیش از اندازه فکر آینده را نکنیم: دام تفکر کوتاه مدت مرگبار است، اما این که از تشخیص نیازهای حال حاضر ناتوان باشیم، چون بیش از حد درگیر مشکلات و مسائل احتمالی آینده هستیم، از آن هم مرگبارتر است.تیم فنی می‌تواند پاشنه آشیل استارتاپ شما شود: چه با ناتوانی در توسعه نیازمندی‌های امروز، چه با ناتوانی در پیش‌بینی پیچیدگی‌های لازم سیستم (که برای رشد در امکانات محصول و تعداد مشتریان لازم است)، و چه با پرداختن بیش از حد به مسائلی که ممکن است در آینده پیش بیاید. تیم فنی باید به خوبی بتواند یک تعادل بین نیازهای امروز و آینده برقرار کند، و اگر در این زمینه ناتوان باشد، مشکلات جدی پیش رو خواهید داشت. (در این نوشته بیشتر به این مورد پرداخته‌ام: لطفا از لبه تکنولوژی فاصله بگیرید!)هر محصولی داستان خودش را دارد، چه موفق باشد و چه شکست بخورد. دانستن داستان دیگران می تواند به هر کدام از ما کمک کند که تصمیم‌های بهتری بگیریم و اشتباهات دیگران را تکرار نکنیم و آموخته‌های آن‌ها را به ساده‌ترین شکل به دست بیاوریم. امیدوارم که داستان رشد فرمالو بتواند به شما کمک کند که بهتر بتوانید از یک ایده اولیه شروع کنید و به سمتی که نیاز دارید حرکت کنید.