بازگشت به بلاگ
۲۸ بهمن ۱۴۰۴Sergei Solod4 دقیقه مطالعه

یک محصول SaaS را کاملاً تنها ساختم؛ با فعال شدن پرداخت‌ها ماهیت کار عوض شد

این محصول را شب‌ها، آخر هفته‌ها و در تعطیلات به‌تنهایی ساختم. وقتی پرداخت‌ها فعال شد، باگ، onboarding، moderation، retention و اعتماد دیگر موضوعات «برای بعد» نبودند و به بخشی از اداره یک محصول واقعی تبدیل شدند.

SaaSتوسعه انفرادیلانچ محصولPaymentsReliabilityعملیات محصول

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

فعال کردن پرداخت‌ها این حس را فوراً تغییر داد. کد ناگهان پیچیده‌تر نشد، اما مسئولیت من در برابر محصول تغییر کرد. وقتی کسی می‌تواند پول بدهد، یک flow خراب دیگر صرفاً یک edge case نیمه‌کاره نیست که بعداً سراغش بروم. onboarding، moderation، retention، اعتماد و قابلیت اتکا دیگر مسئله‌های آینده نیستند؛ بخشی از چیزی می‌شوند که محصول همین حالا وعده می‌دهد.

مهم‌ترین درسی که از لانچ گرفتم همین بود: ساختن یک پروژه انفرادی پر از قابلیت با اداره کردن یک محصول واقعی دو کار متفاوت است.

در توسعه انفرادی، توجه به گلوگاه تبدیل شد

وقتی محصول را می‌ساختم تقریباً از شبکه‌های اجتماعی ناپدید شدم. این استراتژی لانچ نبود. تصمیم‌های محصول، پیاده‌سازی، edge caseها، تست flowها و آماده‌سازی release همه برای همان ساعت‌های محدود رقابت می‌کردند.

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

یک build موفق جواب این سؤال‌ها را نمی‌دهد. یک پرداخت موفق هم نمی‌دهد.

پرداخت‌ها معنای باگ را برای من تغییر دادند

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

برای onboarding و moderation هم همین‌طور است. هنگام توسعه ممکن است شبیه سیستم‌های پشتیبان اطراف قابلیت «اصلی» به نظر برسند. در production بخشی از همان قابلیت‌اند چون کاربر مستقیماً آن‌ها را تجربه می‌کند. retention هم مشابه است: یک جلسه اول خوب ثابت نمی‌کند که محصول دلیلی برای برگشتن ایجاد کرده است.

پرداخت‌ها ثابت نکردند که تمام شده است. آن‌ها نشان دادند کلمه «تمام» چقدر کار را پشت خودش پنهان کرده بود.

لانچ نوع دیگری از اطلاعات به من داد

بعد از release کارهایی شروع شد که برای اسکرین‌شات جذاب نیستند: باگ‌هایی که فقط بعد از انتشار دیده می‌شوند، flowهای خراب، مشکلات moderation که با ورود کاربران واقعی می‌شوند و سؤال‌های retention که از ساختن یک برداشت اولیه خوب خیلی دشوارترند.

سعی می‌کنم این نشانه‌ها را بیش از حد تفسیر نکنم. باگ پس از release خودبه‌خود ثابت نمی‌کند معماری بد است. مشکل retention به‌تنهایی تشخیص product-market fit نیست. یک مشکل moderation ثابت نمی‌کند کل سیستم ناامن است. نشانه به من می‌گوید کجا را بررسی کنم؛ علت را خودکار به من نمی‌گوید.

چیزی که عوض می‌شود کیفیت شواهد است. قبل از لانچ می‌توانم چیزی را تست کنم که انتظار دارم کاربران انجام دهند. بعد از لانچ باید با کاری که واقعاً انجام می‌دهند روبه‌رو شوم. release لحظه از بین رفتن ابهام نیست؛ لحظه‌ای است که بخشی از مهم‌ترین ابهام‌ها بالاخره قابل مشاهده می‌شوند.

چرخه‌ای که حالا بعد از لانچ استفاده می‌کنم

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

  1. flow واقعی را مشاهده می‌کنم. فرض نمی‌کنم مسیری که طراحی کرده‌ام همان مسیری است که کاربران واقعاً طی می‌کنند.
  2. نشانه را از علت جدا می‌کنم. شکست یک مرحله نشان می‌دهد مشکل کجا رخ داده، نه این‌که حتماً چرا رخ داده است.
  3. شکست‌هایی را که به اعتماد مربوط‌اند در اولویت می‌گذارم. پرداخت، دسترسی، onboarding و moderation برایم از نقص‌های صرفاً ظاهری فوری‌ترند چون هزینه شکست بالاتر است.
  4. اول کوچک‌ترین مشکل تأییدشده را حل می‌کنم. ترجیح می‌دهم یک منبع اصطکاک واقعی را حذف کنم تا این‌که بر پایه حدس کل سیستم را بازطراحی کنم.
  5. بعد از اصلاح، تجربه کاربر را دوباره بررسی می‌کنم. یک تغییر کد می‌تواند از نظر فنی درست باشد اما مسئله‌ای را که کاربر می‌بیند حل نکند.

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

لانچ منبع حقیقت را برایم عوض کرد

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

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