آپ کا MVP اب کم از کم نہیں ہونا چاہیے

2026 میں اے آئی پلیٹ فارم پر بلڈ کرنے والے کسی بھی شخص کے لیے minimum viable product ایک بری صلاح ہے۔ بالکل غلط صلاح نہیں، بلکہ ایسی صلاح جو ایک ایسی دنیا سے آئی ہے جو اب موجود نہیں، پھر بھی دہرائی جا رہی ہے کیونکہ یہ بولنے میں اچھی لگتی ہے اور کسی سلائیڈ پر فٹ آتی ہے۔

ایرک ریز نے MVP کا خیال 2011 میں ان ٹیموں کے لیے لکھا تھا جہاں رکاوٹ انجینئر گھنٹے تھے۔ اگر کسی فیچر کو بنانے میں تین ہفتے لگتے اور آپ کو یقین نہ ہوتا کہ کوئی اسے چاہتا بھی ہے یا نہیں، تو دائرہ کار کو کم رکھنا واحد عقلی قدم تھا — آپ ایک حقیقی طور پر کمیاب وسیلے کو راشن کی طرح استعمال کر رہے تھے۔ یہی وجہ ہے کہ اس جملے میں "minimum" اہمیت رکھتا تھا۔ یہ پروڈکٹ کی پسند کے بارے میں کوئی فلسفہ نہیں تھا۔ یہ ایک ایسے لاگت ڈھانچے کے تحت اولین ترجیحات کا تعین تھا جہاں بنانا مہنگا تھا اور معلوم کرنا سستا صرف اسی صورت میں تھا جب آپ پہلے کم بناتے۔

لاگت کا ڈھانچہ پلٹ گیا

جب آپ اسپرنٹ بورڈ کی بجائے چیٹ-سے-پلان-سے-رن پائپ لائن کے ذریعے بناتے ہیں، تو اضافی فیچر تین ہفتے نہیں لیتا۔ اس کی قیمت ایک پرامپٹ اور تصدیقی گزر ہے۔ جو چیز پہلے مہنگی ہوا کرتی تھی — کوڈ لکھنا — اب تقریباً مفت ہے۔ جو چیز اب بھی حقیقتاً مہنگی ہے وہ یہ معلوم کرنا ہے کہ کیا بنانا ہے، اور لائیو ہونے کے بعد شور بھرے صارف رویے سے اشارہ نکالنا۔ MVP کا نظریہ پہلی رکاوٹ کے لیے بہتر بنایا گیا تھا۔ اے آئی پلیٹ فارم پر بنانے والے تقریباً کوئی بھی اب اس رکاوٹ سے محدود نہیں۔

اسی لیے جب کوئی بانی لاگ ان اسکرین اور ایک فیچر شپ کرتا ہے اور اسے "تیزی سے سیکھنے" کے لیے MVP کہتا ہے، تو وہ عام طور پر کچھ راشن نہیں کر رہا ہوتا۔ وہ ایسی صلاح سے ملانے کی کوشش کر رہا ہے جو ایک مختلف معیشت کے لیے معنی رکھتی تھی، اور اس عمل میں وہ کچھ ایسا شپ کر رہا ہے جو حقیقی اشارہ پیدا کرنے کے لیے بہت پتلا ہے۔ پانچ لوگ ایک فیچر والی ایپ آزماتے ہیں، تین فوراً چھوڑ دیتے ہیں، اور آپ نے تقریباً کچھ نہیں سیکھا سوائے یہ کہ ایک اسٹرپڈ ایپ اسٹرپڈ محسوس ہوتی ہے۔ یہ لین نہیں ہے۔ یہ بس چھوٹا ہے۔

اس آخری قطار کو دوبارہ پڑھیں۔ minimalism کی پوری دلیل ایک ایسے وسیلے کو بچانے کے لیے تھی جو اس وقت آپ کے لیے کمیاب نہیں ہے۔ آپ پرانے قاعدے کی قیمت چکا رہے ہیں — پتلی ٹیسٹنگ سرفیس، کمزور ریٹینشن سگنل، ایسے یوزرز جو اس لیے چھوڑ جاتے ہیں کیونکہ ایپ نامکمل لگی، نہ کہ اس لیے کہ آئیڈیا برا تھا — اور اس کا وہ فائدہ حاصل کیے بغیر جو یہ قاعدہ پہلے دیتا تھا۔

"وسیع تر بنانا" اصل میں کیا مطلب رکھتا ہے

میرا مطلب ہر وہ چیز بنانا نہیں جو آپ تصور کر سکتے ہیں۔ میرا مطلب ہے کہ یوزرز تلاش کرنے سے پہلے چیز کی مکمل واضح شکل بنائیں — onboarding، core loop، وہ ایک متعلقہ فیچر جو آپ کی کیٹیگری میں ہر کوئی رکھتا ہے، وہ settings پیج جو اسے پروٹوٹائپ کی بجائے سافٹ ویئر جیسا محسوس کراتا ہے۔ اگر آپ habit tracker بنا رہے ہیں، تو یہ streaks، reminders اور history view ہے، صرف streaks نہیں۔ اگر آپ niche marketplace بنا رہے ہیں، تو یہ listings، messaging اور ٹرسٹ سگنل (reviews، تصدیق، کچھ بھی) ہے، صرف contact form والی listings نہیں۔

ٹیسٹ یہ نہیں کہ "میں اسے کتنا چھوٹا بنا سکتا ہوں۔" ٹیسٹ یہ ہے کہ "سب سے چھوٹا ورژن کیا ہے جسے کوئی اجنبی مکمل پروڈکٹ سمجھ لے۔" یہ ایک الگ معیار ہے، اور عام طور پر یہ تین یا چار فیچرز پر مشتمل ہوتا ہے، نہ کہ صرف ایک۔ ایسے پلیٹ فارم پر جہاں ہر فیچر ایک plan step اور verification pass ہے، بھرتی کا فیصلہ نہیں، پہلے ہفتے میں یہ معیار حاصل کرنا اب حقیقت پسندانہ ہے — جو 2011 میں بالکل نہیں تھا۔

اس کا ایک ورژن ایسا بھی ہے جس نے مجھے شروع میں نقصان پہنچایا۔ میں نے ایک دوست کے اسٹوڈیو کے لیے ایک چھوٹا ٹول بنایا — ایک اسکرین، ایک کام، تیزی سے مکمل، بہت MVP۔ کسی نے استعمال نہیں کیا، اور میں نے خود کو بتایا کہ یہی مارکیٹ کا فیصلہ ہے۔ ایسا نہیں تھا۔ اصل بات یہ تھی کہ یہ ٹول ان کے ورک فلو کے باقی تین ٹیبز کے مقابلے میں نامکمل لگا، اس لیے کسی نے اسے عادت بنانے کے لیے کافی اعتماد نہیں کیا۔ آئیڈیا ٹھیک تھا۔ ناکامی شکل کی تھی، اور میں نے جان بوجھ کر پتلا شپ کیا کیونکہ میں سمجھتا تھا کہ پتلا ہونا خوبی ہے۔

جہاں ناقدین درست ہیں

جو لوگ اس پر اعتراض کریں گے ان کا نکتہ درست ہے، لیکن یہ انجینئرنگ لاگت کے بارے میں نہیں — یہ توجہ کے بارے میں ہے۔ پانچ فیچرز بنانے سے اب developer-weeks کی لاگت نہیں آتی، لیکن اس سے decision-weeks کی لاگت آتی ہے، اور یوزرز کی سمجھ بوجھ کی لاگت آتی ہے۔ ایک وسیع تر پہلا ورژن verify کرنے کے لیے زیادہ سرفیس ایریا لاتا ہے، بگ چھپنے کی زیادہ جگہیں، لکھنے کے لیے زیادہ onboarding، اور core loop کے کام کرنے سے پہلے نئے یوزر کو سیکھنے کے لیے زیادہ چیزیں۔ اگر آپ وسیع بنائیں اور core loop غلط ہو، تو اب آپ نے اپنا سگنل پانچ فیچرز میں الجھا دیا ہے، ایک کی بجائے، اور یہ سمجھنا کہ کس نے ریٹینشن ختم کی، ایک صاف ٹیسٹ کے مقابلے میں زیادہ وقت لے گا۔ scope discipline اب بھی اہم ہے — بس اب اس کا ہدف مختلف ہے۔ پرانا MVP آپ کے build time کو نظم دیتا تھا۔ جو ورژن اس معیشت کے مطابق ہے وہ آپ کے decision time کو نظم دیتا ہے: وہ چند فیچرز چنیں جو پروڈکٹ کو حقیقی محسوس کراتے ہیں، اس سے آگے سب کچھ سختی سے کاٹ دیں، اور صرف اس لیے شامل کرتے رہنے کی خواہش سے بچیں کہ شامل کرنا سستا ہے۔ بنانا سستا ہونا برقرار رکھنے، سمجھانے، یا کچھ ٹوٹنے پر وجہ سمجھنے جیسا مفت نہیں ہے۔

تو اپنی جبلت سے زیادہ وسیع بنائیں، کیونکہ وہ رکاوٹ ختم ہو چکی ہے جس نے "minimum" کو صحیح لفظ بنایا تھا۔ لیکن وہ discipline برقرار رکھیں جس نے MVP کو ایک اچھا آئیڈیا بنایا تھا — بس اسے لانچ کے بعد scope creep پر نشانہ بنائیں، اپنے پہلے ورژن پر نہیں۔