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