10.14 پروڈکٹ مینجمنٹ اور دریافت

جائزہ اور محرکات

پروڈکٹ مینجمنٹ یہ طے کرنے کا نظم و ضبط ہے کہ کیا بنانا ہے اور کیوں، اور اس بات کا جوابدہ ہونا کہ آیا وہ کام کرتا ہے۔ پروڈکٹ مینیجر مسئلے، گاہک، اور نتیجے کا مالک ہوتا ہے۔ وہ شیڈول، ٹکٹ کی قطار، یا کسی حصہ دار کی طرف سے تھمائی گئی فیچرز کی چیک لسٹ کا مالک نہیں۔ یہ فرق ایک جملے میں پورا باب ہے۔ جب پروڈکٹ مینجمنٹ پراجیکٹ کوآرڈینیشن یا حکم بجا لانے میں ڈھ جائے تو ٹیم فیچر فیکٹری بن جاتی ہے: وہ مسلسل ship کرتی ہے، اپنی velocity کے اعداد پورے کرتی ہے، اور کوئی کاروباری میٹرک نہیں ہلاتی۔ کردار ٹھیک اسی کو روکنے کے لیے ہے۔

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

انٹرپرائز اور سرکاری ترتیبیں داؤ بڑھاتی اور کام کی شکل بدلتی ہیں۔ انٹرپرائز تیزی سے پراجیکٹ آپریٹنگ ماڈل (پراجیکٹ کو فنڈ کریں، ship کریں، ٹیم توڑ دیں) سے پروڈکٹ آپریٹنگ ماڈل (ایسی پائیدار ٹیموں کو فنڈ کریں جو برسوں نتائج کی مالک ہوں) کی طرف جا رہے ہیں، اور اندرونی پلیٹ فارمز کو حقیقی گاہکوں والی پروڈکٹس سمجھ رہے ہیں۔ حکومتیں یہی سبق صارف مرکوز ڈیزائن کے جھنڈے تلے سیکھ رہی ہیں: پراجیکٹس نہیں، سروسز کو فنڈ کریں، اور ناپیں کہ شہریوں کو واقعی سروس مل رہی ہے۔ یہ باب اس سوچ اور میکانکس کے بارے میں ہے جو اس تبدیلی کو حقیقی بناتے ہیں۔ یہ باب 11.1 (دریافت کی pipeline) کے ساتھ قریب سے جڑا ہے، جو pipeline کی مشینری تفصیل سے بتاتا ہے؛ یہاں ہم کردار، حکمت عملی، اور دریافت کی روزانہ عادات پر توجہ دیتے ہیں۔

بنیادی اصول

کیا اور کیوں کے مالک بنیں۔ پروڈکٹ مینیجر نتائج کے جوابدہ ہیں، کاموں کو ہم آہنگ کرنے کے نہیں۔
آؤٹ پٹس نہیں، نتائج۔ Ship کرنا لاگت ہے، نتیجہ نہیں۔ نتیجہ بدلا ہوا گاہک یا کاروباری میٹرک ہے۔
گاہک اور مسئلے کو سب سے بہتر جانیں۔ گاہک سے رابطے کے بغیر حکمت عملی اندازہ ہے۔
دریافت مسلسل ہے، مرحلہ نہیں۔ آپ ہر ہفتے گاہکوں سے بات کرتے ہیں، ترسیل کے متوازی۔
ترجیح کے فریم ورک فیصلے کے معاون ہیں، غیب گو نہیں۔ اعداد فیصلے کو آگاہ کرتے ہیں؛ وہ اسے کرتے نہیں۔
روڈ میپس ارادے کے بیانات ہیں، تاریخ والے وعدے نہیں۔ مسائل پر مضبوطی سے، حلوں پر ڈھیلے commit کریں۔
trio کو بااختیار بنائیں۔ پروڈکٹ، ڈیزائن، اور انجینئرنگ مل کر فیصلہ کرتے ہیں؛ اکیلا پروڈکٹ مینیجر برا فیصلہ کرتا ہے۔

سفارشات

کیا اور کیوں کے مالک بنیں، اور کیسے کی ملکیت ٹیم کو دیں

پروڈکٹ مینجمنٹ کے صحت مند ہونے کا واضح ترین امتحان یہ ہے کہ کون سا سوال کس کا ہے۔ پروڈکٹ مینیجر ہم کون سا مسئلہ حل کر رہے ہیں اور یہ ابھی کیوں اہم ہے کا مالک ہے۔ ڈیزائن صارف کے لیے یہ کیسا محسوس ہونا چاہیے کا مالک ہے۔ انجینئرنگ ہم اسے کیسے بنائیں کی مالک ہے۔ جب پروڈکٹ مینیجر حل، ڈیڈ لائنیں، اور نفاذ تھوپنے لگے، تو وہ پروڈکٹ کے عنوان والا پراجیکٹ مینیجر بن چکا ہے، اور اس نے وہی خودمختاری چھین لی ہے جو بااختیار ٹیم کو مؤثر بناتی ہے (باب 5.1 ڈیزائن شراکت کا احاطہ کرتا ہے، باب 10.7 ایجائل ترسیل کے ماڈل کا)۔

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

گاہک میں جمی پروڈکٹ کی وژن اور حکمت عملی طے کریں

پروڈکٹ کی حکمت عملی سخت انتخابوں کا چھوٹا مجموعہ ہے کہ آپ کن گاہکوں کی خدمت کرتے ہیں، ان کے کون سے مسائل حل کرتے ہیں، اور، اتنا ہی اہم، کن سے انکار کرتے ہیں۔ وژن اس دنیا کی پائیدار تصویر ہے جو آپ بنانا چاہتے ہیں، عموماً دو سے پانچ سال آگے۔ حکمت عملی وہ چالوں کا سلسلہ ہے جو آپ کو وہاں پہنچاتا ہے۔ دونوں کے بغیر ترجیح بندی اس میں بگڑ جاتی ہے کہ کون سب سے زور سے بحث کرتا ہے، اور روڈ میپ ہر ایک کے چہیتے فیچرز کی ایک ساتھ stapled فہرست بن جاتا ہے۔

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

نتائج پر منظم کریں اور فیچر فیکٹری سے بچیں

فیچر فیکٹری وہ ہے جو آپ کو ملتی ہے جب کامیابی کی تعریف “ہم نے ship کیا” ہو۔ ٹیمیں velocity ناپتی ہیں، ریلیزز گنتی ہیں، اور launches کا جشن مناتی ہیں، جبکہ بل ادا کرنے والے میٹرکس سپاٹ رہتے ہیں۔ علاج یہ ہے کہ کامیابی کو نتیجہ (گاہک یا کاروباری رویے میں تبدیلی) کے طور پر متعین کریں اور بنانے سے پہلے اس کے ساتھ پیمائش جوڑیں۔ یہاں پروڈکٹ مینجمنٹ مقاصد اور کلیدی نتائج (باب 11.4) سے ملتی ہے: مقاصد اس تبدیلی کو بیان کرتے ہیں جو آپ چاہتے ہیں، کلیدی نتائج اسے ناپتے ہیں، اور “فیچر X launch کریں” کے الفاظ والا کلیدی نتیجہ بھیس بدلا ہوا کام ہے۔

علامات پر نظر رکھیں۔ اگر آپ کا روڈ میپ بغیر بیان کردہ نتیجے کے فیچرز کی فہرست ہے، اگر کوئی نہیں بتا سکتا کہ ship شدہ فیچر نے کون سا میٹرک ہلایا، اگر retrospective کبھی “کیا کام کیا” نہیں پوچھتا بلکہ صرف “کیا ہم نے ship کیا”، تو آپ فیچر فیکٹری میں ہیں۔ اس سے نکلنا زیادہ تر نظم و ضبط کا معاملہ ہے: حل کے طور پر تشکیل شدہ کام قبول کرنے سے انکار کریں جب تک کوئی مسئلہ اور پیمائش نہ بتائے۔ پروڈکٹ analytics اور کنٹرول شدہ تجربات (باب 7.4) آپ کو حقیقی نتیجے کو آرام دہ کہانی سے ممتاز کرنے کا انسٹرومنٹ پینل دیتے ہیں۔

ترسیل کے ساتھ مسلسل دریافت چلائیں

مسلسل پروڈکٹ دریافت کا مطلب ہے کہ ہر ہفتے، ترسیل کے متوازی، ٹیم گاہکوں سے سیکھ رہی ہے اور جو وہ بنانے کا منصوبہ رکھتی ہے اس کے پیچھے مفروضے آزما رہی ہے۔ ماڈل dual-track ہے: دریافت کا track خیالات کا خطرہ کم کرتا ہے جبکہ ترسیل کا track توثیق شدہ خیالات بناتا ہے، اور دونوں ترتیب وار مراحل کی بجائے مسلسل چلتے ہیں (باب 11.1 pipeline کی تفصیل دیتا ہے)۔ اس کے پیچھے عملی عہد چھوٹا اور بے رحم ہے: ہر ہفتے گاہکوں سے بات کریں، چاہے آپ مصروف ہوں، خاص طور پر جب مصروف ہوں۔

اس کے لیے مفید ریڑھ opportunity-solution tree ہے: آپ مطلوبہ نتیجے سے شروع کرتے ہیں، ان گاہک کے مواقع (ضروریات، تکلیفیں، خواہشات) میں شاخ بناتے ہیں جو اسے ہلا سکیں، ہر موقع کے امیدوار حلوں میں دوبارہ شاخ بناتے ہیں، اور پھر مفروضوں کے ان امتحانات میں جو بتائیں کہ حل کام کرتا ہے یا نہیں۔ درخت ٹیم کو ایمانداری پر رکھتا ہے کہ کوئی خاص فیچر میز پر کیوں ہے اور آپ کو پہلے حل پر فریفتہ ہونے کی بجائے مواقع کا موازنہ کرنے پر مجبور کرتا ہے۔ انجینئرنگ commit کرنے سے پہلے، آپ سب سے خطرناک مفروضہ سب سے سستے تجربے سے آزماتے ہیں: انٹرویو، prototype، fake-door ٹیسٹ، A/B ٹیسٹ۔ دریافت کا آؤٹ پٹ فیچرز کی فہرست نہیں۔ یہ توثیق شدہ، قابل پیمائش شرطوں کی دھار ہے جو ترسیل کے لیے تیار ہیں۔

ترجیح کے فریم ورکس کو فیصلے کے معاون کے طور پر استعمال کریں، غیب گو نہیں

ترجیح کے فریم ورک گندے فیصلے کو مفید ساخت دیتے ہیں، اور ہر ایک غلط ہے اگر آپ اس کے عدد کو سچ سمجھیں۔ RICE ہر خیال کو Reach (کتنے صارفین)، Impact، Confidence، اور Effort سے سکور کرتا ہے، پھر (Reach x Impact x Confidence) / Effort سے رینک کرتا ہے۔ Weighted scoring اختیارات کو کئی وزن دار معیاروں کے مقابل ریٹ کرتی ہے۔ تاخیر کی لاگت پوچھتی ہے کہ انتظار کا ہر ہفتہ آپ کو کیا لاگت دیتا ہے، جو اکثر ترتیب کے لیے سب سے تیز عدسہ ہے۔ Kano ماڈل فیچرز کو بنیادی توقعات، کارکردگی کی ضروریات، اور delighters میں چھانٹتا ہے، یاد دلاتا ہے کہ تمام اطمینان خطی نہیں۔

انہیں اپنے مفروضے ظاہر کرنے اور سمجھوتوں کو قابل بحث بنانے کے لیے استعمال کریں، فیصلے سے دستبردار ہونے کے لیے نہیں۔ RICE میں Confidence کی اصطلاح اور weighted scoring کے تخمینے حساب کا لباس پہنے فیصلے ہیں، اور جھوٹی درستگی برے داؤ کو ایسی رینک شدہ فہرست میں دھو سکتی ہے جو معروضی لگے۔ اعداد چلائیں، پھر پوچھیں کہ کیا رینکنگ آپ کی حکمت عملی اور گاہک کے علم سے ملتی ہے۔ اگر نہیں، تو فیصلے پر بھروسہ کریں اور ان پٹس کی چھان بین کریں۔ فریم ورک سوچنے کا معاون ہے؛ درست ہونے کی ذمہ داری اب بھی آپ کی ہے۔

روڈ میپس کو ارادے کے بیانات سمجھیں

تاریخ والا روڈ میپ جو مخصوص سہ ماہیوں میں مخصوص فیچرز کا وعدہ کرتا ہے ایک افسانہ ہے جس پر سب دستخط کرتے ہیں اور کوئی برقرار نہیں رکھ سکتا، کیونکہ یہ وہ ایک چیز (حل) طے کر دیتا ہے جس کے بارے میں دریافت کو سیکھتے رہنا ہے۔ now / next / later روڈ میپ کو ترجیح دیں: ہم ابھی کس پر کام کر رہے ہیں، اگلا کیا امکان ہے، اور ہم بعد میں کس پر غور کر رہے ہیں، مسائل اور نتائج کے طور پر ظاہر، تاریخوں کے ساتھ وابستہ فیچرز کے طور پر نہیں۔ یہ سمت ایمانداری سے بتاتا ہے جبکہ شہادت آنے پر حل بدلنے کی آزادی محفوظ رکھتا ہے۔

بنیادی چال یہ ہے کہ مسائل اور نتائج پر مضبوطی سے commit کریں، اور حلوں پر ڈھیلے۔ جو حصہ دار تاریخ کے یقینی فیچر commitments مانگتے ہیں وہ عموماً پیش گوئی کے قابل ہونا مانگ رہے ہیں، جو معقول ہے؛ انہیں نتائج اور وقتی دائروں کی سطح پر دیں (“ہم اس نصف میں onboarding کے drop-off کو نمایاں گھٹائیں گے”) نہ کہ مخصوص فیچرز کی سطح پر جنہیں آپ نے ابھی توثیق نہیں کیا۔ جب آپ کو سخت تاریخ دینی ہو تو اسے قیمتی نتیجے سے باندھیں اور حل کے دائرے کو لچکنے دیں، بالکل جیسا باب 10.6 پراجیکٹ کی ترسیل کے لیے سفارش کرتا ہے۔

مطلوبیت، عملی ہونا، ممکن ہونا، اور استعمال پذیری کی توثیق کریں

حقیقی سرمایہ کاری commit کرنے سے پہلے، پروڈکٹ کے خیال کو چار خطرے عبور کرنے ہیں۔ مطلوبیت (Desirability): کیا گاہک واقعی اسے چاہتے ہیں؟ عملی ہونا (Viability): کیا یہ کاروبار کے لیے کام کرتا ہے (قانونی، مالی، برانڈ، سیلز)؟ ممکن ہونا (Feasibility): کیا انجینئرنگ دستیاب وقت اور ٹیکنالوجی سے اسے بنا سکتی ہے؟ استعمال پذیری (Usability): کیا لوگ واقعی اسے استعمال کر سکتے ہیں؟ trio انہیں ڈھانپنے کے لیے بنی ہے: پروڈکٹ viability پر، ڈیزائن usability پر، انجینئرنگ feasibility پر، اور desirability سب کا مسئلہ ہے۔ ایک چھوڑیں تو وہ ایسے launch کے طور پر لوٹتی ہے جسے گاہک نظر انداز کریں، قانونی روکے، انجینئرنگ ship نہ کر سکے، یا صارف سمجھ نہ سکیں۔

یہی بنانے، خریدنے، یا شراکت کرنے کے فیصلوں کا چوکھٹا بھی ہے۔ اگر کوئی صلاحیت آپ کے امتیاز کا مرکز ہے تو اسے بنائیں۔ اگر ضروری مگر غیر امتیازی ہے (billing، authentication، ای میل کی ترسیل)، تو خریدنے یا شراکت کو مضبوطی سے ترجیح دیں، کیونکہ ہر فیچر جو آپ بناتے ہیں دیکھ بھال، سیکیورٹی کی سطح، اور ذہنی بوجھ کی دائمی دم رکھتا ہے۔ کم از کم قابل عمل پروڈکٹ (MVP) وہ سستی ترین چیز ہے جو آپ کے سب سے خطرناک مفروضے کو آزمائے، نہ کہ گھٹایا ہوا ورژن 1.0 جو آپ ship کر کے بھول جائیں؛ اسے ایماندار رکھنے کو پوچھیں کہ آپ کیا سیکھیں گے، نہ کہ صرف کیا launch کریں گے۔

پروڈکٹ-مارکیٹ فٹ جانیں اور پروڈکٹ آپریشنز میں سرمایہ کاری کریں

پروڈکٹ-مارکیٹ فٹ وہ لمحہ ہے جب پروڈکٹ مضبوط بازاری طلب پوری کرتی ہے، اور آپ عموماً ثابت کرنے سے پہلے اسے محسوس کرتے ہیں: برقراری کے منحنی صفر تک گرنے کی بجائے چپٹے ہو جاتے ہیں، استعمال زبانی بات سے بڑھتا ہے، گاہک پروڈکٹ کھونے پر واقعی پریشان ہوں گے، اور آپ طلب پیدا کرنے کی بجائے اس کے ساتھ چلنے کی جدوجہد کرتے ہیں۔ فٹ سے پہلے آپ کا کام اسے ڈھونڈنا ہے، اور تقریباً کچھ اور اہم نہیں۔ فٹ کے بعد آپ کا کام پیمانہ بڑھانا اور اس کا دفاع کرنا ہو جاتا ہے۔ دونوں مراحل کو ملانا (فٹ ہونے سے پہلے پیمانہ بڑھانا، یا اسے پانے کے بعد بھی تلاش جاری رکھنا) کلاسیکی اور مہنگی غلطی ہے۔

جیسے پروڈکٹ ٹیموں کی تعداد بڑھے، پروڈکٹ آپریشنز میں سرمایہ کاری کریں: مشترک تحقیق، ڈیٹا، ٹولنگ، اور عمل جو بہت سی ٹیموں کو ہر ایک کے دوبارہ ایجاد کیے بغیر اچھی دریافت کرنے دیں۔ پروڈکٹ ops گاہک انٹرویو کی تال کو عملہ دیے رکھتا ہے، analytics کو قابل اعتماد، روڈ میپ کی شکل کو مستقل، اور OKR کی تال کو چلتا رکھتا ہے۔ پروڈکٹ آپریٹنگ ماڈل کی طرف جاتے انٹرپرائز میں، اور پلیٹ فارم-بطور-پروڈکٹ ادارے میں جہاں اندرونی پلیٹ فارمز کے حقیقی اندرونی گاہک ہیں، پروڈکٹ ops ہی ماڈل کو درجنوں ٹیموں میں مربوط رکھتا ہے بجائے اس کے کہ وہ مقامی عادات میں بکھر جائے۔

سمجھوتے: فوائد اور نقصانات

طریقہ	فوائد	نقصانات
بااختیار پروڈکٹ ٹیم (نتائج)	نتائج کی مالک؛ بہتر حل ڈھونڈتی ہے؛ متحرک	سینئر ٹیلنٹ اور حقیقی اعتماد چاہیے؛ اوپر سے ہدایت دینا مشکل
Feature-team / حکم بجا لانے کا ماڈل	پیش گوئی کے قابل آؤٹ پٹ؛ منظم اور معاہدہ کرنا آسان	غلط چیزیں کارکردگی سے ship کرتا ہے؛ نتیجے کا کوئی مالک نہیں
مسلسل دریافت	ہفتہ وار داؤ کا خطرہ کم کرتی ہے؛ تیز سیکھنا؛ کم ضیاع	تحقیقی صلاحیت اور نظم و ضبط چاہیے؛ شیڈول کرنا مشکل
بھاری پیشگی تقاضے	فنڈ دینے والوں کو تسلی بخش؛ واضح دائرہ	مفروضے غیر آزمائے؛ دیر سے رائے؛ big-bang کا خطرہ
Now/next/later روڈ میپ	غیر یقینی کے بارے میں ایماندار؛ سیکھنا محفوظ رکھتا ہے	ان حصہ داروں کو مایوس کرتا ہے جو تاریخ والے فیچر commitments چاہتے ہیں
تاریخ والا فیچر روڈ میپ	پیش گوئی کے قابل لگتا ہے؛ بتانا آسان	جو آپ نہیں جان سکتے اس کا وعدہ؛ نتیجے پر آؤٹ پٹ کو انعام دیتا ہے
فریم ورک سکور سے ترجیح	ساختہ، قابل بحث، سیاست گھٹاتا ہے	جھوٹی درستگی؛ برے داؤ کو معروضی دکھا سکتا ہے

مرکزی کھنچاؤ commitment بمقابلہ سیکھنا ہے۔ بجٹ، معاہدے، اور ایگزیکٹو سخت commitments چاہتے ہیں، جو تاریخ والے فیچر روڈ میپس اور پیشگی تقاضوں کی طرف کھینچتے ہیں۔ اچھی پروڈکٹس کو دریافت کی گنجائش چاہیے، جو نتائج اور مسلسل تجربات کی طرف کھینچتی ہے۔ اسے اسی طرح حل کریں جیسے اس گائیڈ میں ہر جگہ: مسائل، نتائج، اور وقتی دائروں پر مضبوطی سے commit کریں، اور مخصوص حل ڈھیلے تھامیں۔ یہ قیادت کو وہ پیش گوئی کی صلاحیت دیتا ہے جو اسے واقعی چاہیے (اہم چیزوں پر قابل پیمائش پیش رفت) بغیر ٹیم کو ان فیچرز کا وعدہ کرنے پر مجبور کیے جنہیں اس نے ابھی توثیق نہیں کیا۔

اپنی ٹیم کے ساتھ بحث کے سوالات

کیا آپ کا پروڈکٹ مینیجر نتیجے کا مالک ہے، یا backlog کا؟ یہ سب سے زیادہ ظاہر کرنے والا سوال ہے کہ آپ کی ٹیم واقعی کیسے کام کرتی ہے۔ اگر پروڈکٹ مینیجر کو روڈ میپ ship کرنے، حصہ داروں کی درخواستوں کا پیچھا کرنے، اور sprint بھرا رکھنے پر ناپا جاتا ہے تو آپ کے پاس پروڈکٹ کے عنوان والا پراجیکٹ کوآرڈینیٹر ہے، اور کوئی واقعی جوابدہ نہیں کہ کام کوئی میٹرک ہلاتا ہے یا نہیں۔ شہادت لائیں: اپنے پروڈکٹ مینیجر کی پچھلی تین ڈیلیورایبلز دیکھیں اور پوچھیں ہر ایک کو کون سا گاہک یا کاروباری نتیجہ بدلنا تھا، اور کیا کسی نے جانچا۔ بڑے ادارے میں داؤ مرکب ہوتے ہیں، کیونکہ آؤٹ پٹس کی طرف اشارہ کی ہوئی ایک ٹیم کئی سہ ماہیاں ایسے فیچرز بنانے میں جلا سکتی ہے جو demos میں اچھے ٹیسٹ ہوں اور production میں کچھ نہ بدلیں۔ جواب کو دونوں چیزیں بدلنی چاہییں: آپ پروڈکٹ مینیجر کو کس پر ناپتے ہیں اور آپ ٹیم کو حلوں پر کتنا کنٹرول دینے کو تیار ہیں۔ اگر کوئی نتیجے کا مالک نہیں تو روڈ میپ پر بحث سے پہلے اسے ٹھیک کریں۔
اس ٹیم میں کسی نے آخری بار گاہک سے کب بات کی، اور کیا یہ اس ہفتے تھی؟ مسلسل دریافت اسی عادت پر جیتی یا مرتی ہے، اور ترسیل کا دباؤ بڑھنے پر یہ سب سے پہلے کٹتی ہے، جو ٹھیک وہ وقت ہے جب آپ کو اس کی سب سے زیادہ ضرورت ہے۔ جو ٹیمیں گاہکوں سے بات کرنا چھوڑ دیتی ہیں انہیں پتا نہیں چلتا کہ وہ اندھی ہو چکی ہیں؛ وہ بس اندرونی رائے اور پرانی تحقیق سے استدلال شروع کرتی ہیں، زیادہ پراعتماد اور کم درست ہوتی جاتی ہیں۔ اصل لاگ لائیں: گنیں کہ آپ کے پچھلے دس فیچرز میں سے کتنے بنانے سے پہلے دستاویزی مفروضے اور سستے ٹیسٹ سے گزرے، بمقابلہ حصہ دار کے منہ سے سیدھے backlog میں۔ انٹرپرائز اور سرکاری ٹیموں کے لیے، جہاں ایک غیر ہم آہنگ اقدام کئی ٹیم-سہ ماہیاں اور، عوامی شعبے میں، حقیقی عوامی اعتماد ضائع کر سکتا ہے، نام لیں کہ ہفتہ وار گاہک رابطہ زندہ رکھنے کا جوابدہ کون ہے۔ اگر ایماندار جواب “اس ہفتے نہیں” یا “یقین نہیں” ہے تو آپ مفروضوں پر اڑ رہے ہیں اور اسے حکمت عملی کہہ رہے ہیں۔
پراجیکٹ آپریٹنگ ماڈل سے پروڈکٹ آپریٹنگ ماڈل کی طرف جانے کو کیا چاہیے، اور آپ کو کیا روک رہا ہے؟ بہت سے انٹرپرائز اب بھی عارضی پراجیکٹس فنڈ کرتے، انہیں عملہ دیتے، ship کرتے، اور ٹیم توڑ دیتے ہیں، جو پائیدار ملکیت اور گاہک کا علم تباہ کرتا ہے جس پر اچھا پروڈکٹ کا کام ٹکا ہے۔ برسوں نتائج کی مالک پائیدار ٹیموں کی طرف جانا، بشمول اندرونی پلیٹ فارمز کو حقیقی گاہکوں والی پروڈکٹس سمجھنا، فنڈنگ، ادارے کے ڈیزائن، اور نظم و نسق کی تبدیلی ہے، محض ملازمت کے عنوانات کی تبدیلی نہیں۔ شہادت لائیں: ایک موجودہ اقدام کی فنڈنگ اور عملے کا سراغ لگائیں، اور پوچھیں جب پراجیکٹ ختم ہو اور ٹیم بکھر جائے تو جمع سیکھنے کا کیا ہوتا ہے۔ متصادم غور حقیقی ہے، کیونکہ سالانہ پراجیکٹ بجٹ اور خریداری کے قواعد جائز جوابدہی کی وجوہات سے موجود ہیں، اور آپ کو انہیں پورا کرنا ہے، نظر انداز نہیں۔ جواب کو سب سے چھوٹا ٹھوس قدم (ایک مستقل ٹیم جو مستحکم بجٹ کے ساتھ ایک نتیجے کی مالک ہو) شناخت کرنا چاہیے جو پورے پورٹ فولیو کو بدلنے کی کوشش سے پہلے ماڈل ثابت کرے (باب 10.1)۔
جب ہم ترجیح کا فریم ورک چلاتے ہیں تو کیا وہ فیصلے کو آگاہ کرتا ہے یا پہلے سے کیے گئے فیصلے پر محض مہر لگاتا ہے؟ RICE، weighted scoring، اور تاخیر کی لاگت اس لیے مفید ہیں کہ وہ مفروضوں کو کھلے میں لانے پر مجبور کرتے ہیں، اور جس لمحے عدد سوچنا بند کرنے کا بہانہ بنے وہ ضرر رساں ہو جاتے ہیں۔ متصادم غور حقیقی ہے: فریم ورک سیاست گھٹاتے اور قابل دفاع کاغذی راستہ دیتے ہیں، جس کی بڑے اداروں کو واقعی ضرورت ہے، پھر بھی Confidence اور Impact کی اصطلاحات حساب کا لباس پہنے فیصلہ ہیں اور برے داؤ کو معروضی لگنے والی رینک میں دھو سکتی ہیں۔ اپنے پچھلے چند ترجیحی فیصلے لائیں اور دو چیزیں جانچیں: کیا کبھی کسی نے سکور کو اوور رائیڈ کیا جب حکمت عملی یا گاہک کا علم متفق نہ تھا، اور کیا سب سے زیادہ تنخواہ پانے والے کی ترجیح نے خاموشی سے وہ ان پٹس طے کیے جنہوں نے رینکنگ بنائی۔ انٹرپرائز اور سرکاری ترتیبوں میں، جہاں سکور شدہ backlog اکثر steering کمیٹیوں اور آڈیٹرز کو دکھایا جانے والا دستاویز بنتا ہے، نام لیں کہ عدد کو اوور رائیڈ کرنے کی اجازت کس کو ہے اور کن بنیادوں پر، کیونکہ جس فریم ورک کو کوئی رد نہ کر سکے وہ سوچنے کا معاون نہیں رہا بلکہ ربر اسٹیمپ بن گیا۔
ہم نے حصہ داروں سے تاریخ والے فیچرز کے طور پر کیا وعدہ کیا ہے، اور کیا ہم ان commitments کو اعتماد کھوئے بغیر نتائج کے طور پر دوبارہ بیان کر سکتے ہیں؟ تاریخ والے فیچر روڈ میپس پیش گوئی کے قابل ہونے کا احساس دیتے ہیں اور عموماً افسانہ ہیں، کیونکہ وہ وہ حل طے کرتے ہیں جس کے بارے میں دریافت کو سیکھتے رہنا ہے، اور بڑے ادارے میں ہر ایسا وعدہ انحصار کرنے والی ٹیموں، مارکیٹنگ کے منصوبوں، اور ایگزیکٹو توقعات میں لہریں بھیجتا ہے۔ کھنچاؤ جائز ہے: فنڈ دینے والے اور حصہ دار بجٹ اور جوابدہی کی وجوہات سے یقین چاہتے ہیں، اس لیے آپ commit کرنے سے محض انکار نہیں کر سکتے؛ آپ کو غیر توثیق شدہ فیچرز کی بجائے نتائج اور وقتی دائروں کی سطح پر پیش گوئی دینی ہے۔ موجودہ روڈ میپ لائیں اور ہر چیز کو یا تو نتیجہ جس پر آپ commit کر سکیں یا مخصوص حل جس کا آپ اندازہ لگا رہے ہیں کے طور پر نشان زد کریں، پھر مسودہ بنائیں کہ آپ اندازوں کو now/next/later مسائل کے طور پر کیسے دوبارہ بیان کریں گے۔ سالانہ بجٹ اور خریداری کے سنگ میلوں سے بندھی انٹرپرائز اور عوامی شعبے کی ٹیموں کے لیے، شناخت کریں کہ کون سے commitments واقعی معاہداتی ہیں بمقابلہ محض عادتی، کیونکہ عادتی وہ جگہ ہیں جہاں آپ جھوٹی درستگی کو ایماندار سمت سے بدل سکتے ہیں، اور معاہداتی وہ جہاں آپ کو فیچر کی بجائے نتیجے پر commitment کا مذاکرہ کرنا ہے۔
ہم کہاں غیر امتیازی صلاحیت بنا رہے ہیں جسے ہم خرید یا شراکت سے لے سکتے ہیں، اور فیصلہ کون کرتا ہے؟ ہر فیچر جو آپ بناتے ہیں دیکھ بھال، سیکیورٹی کی سطح، اور سپورٹ کے بوجھ کی دائمی دم رکھتا ہے، اس لیے billing، authentication، یا ای میل کی ترسیل ہاتھ سے بنانا آپ کی نایاب ترین صلاحیت اس کام پر خرچ کرتا ہے جو آپ کو ممتاز نہیں کرتا (باب 10.4)۔ متصادم غور یہ ہے کہ “خریدنا” کنٹرول اور موزونیت کو رفتار اور کم ملکیت کی لاگت سے بدلتا ہے، اور کبھی جو صلاحیت آپ نے عام سمجھی وہ دراصل آپ کی برتری کا مرکز ہوتی ہے، اس لیے مطلوبیت-عملی ہونا-ممکن ہونا-استعمال پذیری کا عدسہ ایمانداری سے لگانا ہے نہ کہ ترجیح کی آڑ کے طور پر۔ آپ کی ٹیمیں فی الحال اندرونی طور پر کیا بنا رہی ہیں اس کی فہرست لائیں، ہر ایک کو بنیادی امتیاز یا غیر امتیازی plumbing کے طور پر نشان زد کریں، اور plumbing کی جاری ملکیت کی لاگت کا فروخت کنندہ کے متبادل کے مقابل اندازہ لگائیں۔ انٹرپرائز اور سرکاری سیاق میں خریداری کے قواعد، ڈیٹا کی رہائش اور سیکیورٹی کے تقاضے، اور فروخت کنندہ کے lock-in اور اخراج کی شرائط شامل کریں، کیونکہ وہاں بنانے-خریدنے-شراکت کا فیصلہ محض انجینئرنگ کا سمجھوتہ نہیں بلکہ تعمیل اور جوابدہی کا ہے، اور اس کے مالک کو آڈیٹر کے سامنے انتخاب کا دفاع کرنے کے قابل ہونا چاہیے۔

شعبہ جاتی نقطۂ نظر

اسٹارٹ اپ۔ کم رن وے کے ساتھ دریافت عمل نہیں، بقا ہے۔ ایک بانی پروڈکٹ کی ٹوپی پہنتا ہے، بغیر رسم کے ہر ہفتے گاہکوں سے بات کرتا ہے، اور کسی انجینئر کو بنانے پر لگانے سے پہلے سستے ترین ٹیسٹ (fake-door بٹن، پانچ انٹرویو) چلاتا ہے۔ بھاری فریم ورک اور تاریخ والے روڈ میپس چھوڑ دیں؛ پوری کمپنی حکمت عملی اپنے ذہن میں رکھ سکتی ہے، اس لیے نظم و ضبط اس پر خرچ کریں کہ بلند درخواست بنانے سے انکار کریں جب تک کوئی مسئلہ اور میٹرک نہ بتائے۔

چھوٹا کاروبار۔ آپ کے پاس مخصوص پروڈکٹ مینیجر نہیں، اس لیے پروڈکٹ کی سوچ ایسی عادت ہے جو مالک یا لیڈ انجینئر دوسرے فرائض کے ساتھ اٹھاتا ہے۔ زیادہ تر بنانے-بمقابلہ-خریدنے کے فیصلوں کو خریدنے کی طرف ڈھالیں: booking، ادائیگیوں، یا ای میل جیسی غیر امتیازی صلاحیت فروخت کنندہ کی ہے، اور آپ کی نایاب توجہ ان ایک دو چیزوں پر جاتی ہے جو واقعی گاہک جیتتی ہیں۔ رسمی روڈ میپ کی بجائے ہلکی now/next/later فہرست رکھیں، اور مکمل OKR نظام کی بجائے ایک ہی پیشگی میٹرک (دوبارہ خریداریاں، no-shows) کو اپنا نتیجہ سمجھیں۔

بڑا ادارہ۔ کام بہت سی پروڈکٹ ٹیموں کو ہم آہنگ کرنا ہے بغیر ماڈل کو بکھرنے دیے: نتائج کی مالک پائیدار trios، مستقل روڈ میپ کی شکل، اور پروڈکٹ آپریشنز جو انٹرویو کی تال، analytics، اور OKR کی تال کو درجنوں ٹیموں میں مربوط رکھے۔ نظم و نسق اور آڈٹ قابل سراغ ہونا چاہتے ہیں، اس لیے نتائج، ترجیح کی دلیل، اور بند کرنے کے فیصلے واضح بنائیں بجائے تاریخ والے فیچر وعدوں کی طرف لوٹنے کے جو کمیٹی کو مطمئن کرتے ہیں مگر اثر پر آؤٹ پٹ کو انعام دیتے ہیں۔ پراجیکٹ فنڈنگ سے پروڈکٹ آپریٹنگ ماڈل کی طرف تبدیلی دانستہ منظم کریں، کیونکہ ادارے کا ڈیزائن اور بجٹ ملازمت کے عنوانات سے آہستہ بدلتے ہیں۔

حکومت۔ خریداری کے قواعد، شفافیت، اور عوامی جوابدہی ہر انتخاب کو شکل دیتے ہیں۔ مقررہ دائرے کے پراجیکٹس کی بجائے پائیدار سروس ٹیموں کو فنڈ کریں، کامیابی کو شہری نتیجے (درخواست دینے کا وقت، خود سروس کی تکمیل) کے طور پر متعین کریں جس کی نگران ادارے توثیق کر سکیں، اور صارف مرکوز ڈیزائن اور رسائی کے معیارات کو سخت تقاضے سمجھیں جو حقیقی درخواست دہندگان کے ساتھ آزمائے جائیں، بشمول معاون ٹیکنالوجی کے صارفین۔ نتائج اور پیش رفت سادگی سے شائع کریں تاکہ جانچ کرنے والے عوامی قدر دیکھیں، اور بنانے-بمقابلہ-خریدنے اور فروخت کنندہ کے معاہدوں کو ڈیٹا کی پورٹیبلٹی اور اخراج کے گرد ترتیب دیں تاکہ آج کا سپلائر کا انتخاب دہائی بھر کا lock-in نہ بنے۔

مثالیں

اسٹارٹ اپ۔ آزاد کلینکس کے لیے شیڈولنگ کا آلہ بناتا چھ افراد کا اسٹارٹ اپ بڑے “آن لائن booking” فیچر کے لالچ کا مقابلہ کرتا ہے جس کی تین بلند آواز گاہک بار بار درخواست کرتے ہیں۔ بانی-پروڈکٹ مینیجر اس کی بجائے دریافت کا ایک ہفتہ چلاتا ہے: پانچ کلینک مالکان کے انٹرویو، مارکیٹنگ سائٹ پر fake-door بٹن، اور ایک پیشگی میٹرک (ملاقاتوں کا فیصد جو no-show پر ختم ہوتی ہیں)۔ شہادت بتاتی ہے کہ booking نہیں، no-shows حقیقی تکلیف ہے، اس لیے ٹیم ایک واحد نتیجہ طے کرتی ہے (اس سہ ماہی pilot کلینکس کے لیے no-shows 10% سے نیچے کرنا)، سب سے خطرناک مفروضہ آزمانے کو چھوٹا deposit-اور-reminder MVP ship کرتی ہے، اور booking کا فیچر ایک لائن لکھے بغیر ختم کر دیتی ہے۔ روڈ میپ تاریخ والے منصوبے کی بجائے now/next/later فہرست ہے، اور پوری ٹیم پچھلے ہفتے کی گاہک کی کال یاد سے بیان کر سکتی ہے۔

بڑا ادارہ۔ خوردہ بینک اپنے ادائیگیوں کے گروپ کو پراجیکٹ ماڈل سے پروڈکٹ ماڈل میں لے جاتا ہے: ایک پائیدار trio (پروڈکٹ، ڈیزائن، انجینئرنگ) charter شدہ پراجیکٹس کی سیریز کی بجائے مستحکم سالانہ بجٹ کے ساتھ “روزمرہ کی ادائیگیاں فوری محسوس ہوں” کی مستقل نتیجے کے طور پر مالک ہے۔ ٹیم ہفتہ وار گاہک انٹرویو چلاتی اور opportunity-solution tree برقرار رکھتی ہے، امیدوار حلوں کی ترتیب کے لیے RICE استعمال کرتی ہے مگر جب تاخیر کی لاگت کا تجزیہ دکھاتا ہے کہ latency کی اصلاح زیادہ اہم ہے تو رینکنگ کو اوور رائیڈ کرتی ہے، اور حصہ داروں کو تاریخ والے فیچر وعدوں کی بجائے now/next/later روڈ میپ شائع کرتی ہے۔ دو مجوزہ فیچرز پیشگی اشاریے ہلانے میں ناکامی پر دریافت میں ختم ہوتے ہیں، تخمیناً دو سہ ماہیوں کی تعمیر کی کوشش بچاتے ہوئے، اور پروڈکٹ آپریشنز بینک کی پندرہ پروڈکٹ ٹیموں میں انٹرویو کی تال اور analytics کو قابل اعتماد رکھتی ہے۔

حکومت۔ فوائد کی درخواستیں جدید کرتی قومی ایجنسی ڈیجیٹل سروس ٹیموں کی وکالت کردہ عوامی شعبے کی پروڈکٹ سوچ اپناتی ہے: وہ مقررہ دائرے کے پراجیکٹ کی بجائے پائیدار سروس ٹیم کو فنڈ کرتی ہے، اور کامیابی کو ڈیلیور شدہ ماڈیولز کی بجائے شہری نتیجے (اوسط درخواست دینے کا وقت 40 سے 15 منٹ تک گھٹانا اور کامیاب خود سروس کی تکمیل 55% سے 85% تک بڑھانا) کے طور پر متعین کرتی ہے۔ صارف مرکوز ڈیزائن ناقابل مذاکرات ہے: ٹیم ہر ریلیز سے پہلے حقیقی درخواست دہندگان، بشمول معاون ٹیکنالوجی کے صارفین، کے ساتھ moderated usability ٹیسٹنگ چلاتی ہے، اور رسائی کے معیارات کو سخت تقاضے سمجھتی ہے۔ چونکہ روڈ میپ نتائج کے طور پر تشکیل شدہ ہے اور ٹیم برسوں سروس کی مالک ہے، نگران ادارے خرچ کی رپورٹ کی بجائے قابل پیمائش عوامی قدر دیکھتے ہیں، اور ایجنسی ایک دور کے go-live پر سب کچھ داؤ پر لگانے کی بجائے مفید صلاحیت جلد ship کر سکتی ہے (ابواب 11.1، 5.1)۔

کاروباری جواز: محرکات، ROI اور TCO

حقیقی پروڈکٹ مینجمنٹ کی واپسی پر ٹلے ہوئے ضیاع کا غلبہ ہے۔ بڑی ٹیکنالوجی کمپنیوں میں کنٹرول شدہ تجربات کے پروگرام بار بار پاتے ہیں کہ بنائے گئے فیچرز کا بڑا حصہ، اکثر آدھے کے قریب بیان کیا جاتا ہے، ہدف میٹرک میں کوئی قابل پیمائش بہتری نہیں لاتا یا اسے فعال طور پر نقصان پہنچاتا ہے۔ اگر ٹیم کی صلاحیت کا چوتھائی بھی ایسے خیالات پر جائے جو مسلسل دریافت سستے میں مار دیتی تو نظم و ضبط کئی گنا اپنی ادائیگی کر دیتا ہے: گاہک انٹرویو کا ایک ہفتہ اور fake-door ٹیسٹ انجینئرنگ کی ایک سہ ماہی کے مقابل، نیز ایسے فیچر کی دائمی دیکھ بھال جسے کوئی استعمال نہیں کرتا، کچھ بھی نہیں لاگت دیتا۔ فیچر فیکٹری کی بنیادی لاگت وہ فیچرز نہیں جو وہ ship کرتی ہے۔ یہ ان نتائج کی موقع کی لاگت ہے جو اس نے کبھی نہیں ہلائے۔

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

قیادت کے سامنے دلیل رکھنے کو، گفتگو “ہم کتنا ship کر رہے ہیں” سے “ہم اہم میٹرکس کتنے ہلا رہے ہیں” میں بدلیں، اور مہنگے فیچرز کی دو تین ٹھوس مثالیں دکھائیں جنہوں نے کچھ نہیں ہلایا۔ اپنانے کی لاگت معمولی ہے: تحقیقی صلاحیت، دریافت کی تال، نتیجے پر مبنی روڈ میپ، اور بنانے سے پہلے کامیابی متعین کرنے کا نظم و ضبط۔ سرمایہ کاری نہ کرنے کا خطرہ خاموش، بے شمار، اور مرکب ہے، کیونکہ فیچر فیکٹری پیداواری لگتی ہے ٹھیک اس وقت تک جب تک آپ دیکھیں کہ کاروبار ہلا ہی نہیں۔

ضد نمونے اور خامیاں

فیچر فیکٹری: کامیابی کی تعریف “ہم نے ship کیا”، velocity کا جشن جبکہ کاروباری میٹرکس سپاٹ ہیں۔
پروڈکٹ مینیجر بطور پراجیکٹ مینیجر: مسئلے اور نتیجے کی بجائے شیڈول اور ٹکٹ کی قطار کا مالک ہونا۔
پروڈکٹ مینیجر بطور فیچر سیکرٹری: حصہ داروں کی درخواستیں بغیر مسئلے یا پیمائش کے backlog میں نقل کرنا۔
تاریخ والے فیچر وعدے کے طور پر روڈ میپ: مخصوص سہ ماہیوں میں مخصوص حلوں پر commit کرنا جن کی آپ ابھی توثیق نہیں کر سکتے۔
ایک بار کا مرحلہ بطور دریافت: پیشگی دریافت کی sprint، پھر مہینوں کی تعمیر بغیر مزید گاہک رابطے کے۔
HiPPO سے چلتی ترجیح: سب سے زیادہ تنخواہ پانے والے کی رائے شہادت پر غالب آتی ہے، اور فریم ورک اس پر مہر لگانے کا تھیٹر بن جاتے ہیں۔
فریم ورک کی پرستش: RICE یا weighted سکور کو سچ سمجھنا، جھوٹی درستگی کو برے داؤ کو دھونے دینا۔
غیر امتیازی انفراسٹرکچر بنانا: billing یا auth ہاتھ سے بنانا جو فروخت کنندہ بہتر اور سستا دیتا۔
پروڈکٹ-مارکیٹ فٹ سے پہلے پیمانہ بڑھانا: ایسی پروڈکٹ پر نمو میں پیسہ ڈالنا جو بازار ابھی مضبوطی سے نہیں چاہتا۔
بغیر پروڈکٹ مالک کے اندرونی پلیٹ فارم: پلیٹ فارم ٹیم وہ بنا رہی ہے جو اسے دلچسپ لگتا ہے، وہ نہیں جو اس کے اندرونی گاہکوں کو چاہیے۔

پختگی کا ماڈل

سطح 1، آغاز: پروڈکٹ مینجمنٹ حکم بجا لانا اور ردعملی ہے۔ تاریخ والا فیچر روڈ میپ اوپر سے آتا ہے؛ کامیابی اسے ship کرنا ہے۔ کوئی بیان کردہ نتائج نہیں، باقاعدہ گاہک رابطہ نہیں، اور کوئی جوابدہ نہیں کہ کام نے میٹرک ہلایا یا نہیں۔
سطح 2، ترقی: بنیادی پروڈکٹ کے عمل ظاہر ہوتے ہیں مگر ٹیموں میں غیر مستقل ہیں۔ کچھ ٹیموں کے لیے نتائج اور OKRs موجود ہیں، مگر اہداف اکثر آؤٹ پٹ کی شکل کے ہیں اور روڈ میپس اب بھی فیچرز کی فہرستیں ہیں۔ دریافت کبھی کبھار ہوتی ہے، عموماً پیشگی مرحلے کے طور پر، اور ترجیح فریم ورک استعمال کرتی ہے، کبھی بلند ترین آواز کی آڑ کے طور پر۔
سطح 3، معیار بندی: بااختیار trios نتائج کی مالک ہیں، اور عمل دستاویزی اور ادارہ گیر متوقع ہے۔ روڈ میپس now/next/later ارادے کے بیانات ہیں؛ مسلسل دریافت عملے والی، ہفتہ وار عادت ہے جس میں دستاویزی مفروضوں کے ٹیسٹ ہیں؛ ترجیح کے فریم ورک فیصلے کو آگاہ کرتے ہیں، اس کی جگہ نہیں لیتے؛ اور پروڈکٹ-مارکیٹ فٹ کو مقامی عادت کی بجائے مشترک معیار کے طور پر سمجھا اور ٹریک کیا جاتا ہے۔
سطح 4، انتظام: عمل بنیادی خطوط کے مقابل ناپا اور کنٹرول کیا جاتا ہے۔ ہر ٹیم بیان کردہ بنیادی خط کے مقابل پیشگی اور بعد کے نتیجے کے میٹرکس ٹریک کرتی ہے، اور launch کے بعد ہر فیچر کو پیشگی رجسٹر شدہ کامیابی کے میٹرک کے مقابل جانچا جاتا ہے، رائے نہیں بلکہ شہادت پر نافذ بند کرنے کی حد کے ساتھ۔ دریافت کی صحت بھی ناپی جاتی ہے (انٹرویو کی تال پوری، تعمیر سے پہلے مفروضے آزمائے گئے، دریافت میں مارے گئے بمقابلہ ship شدہ خیالات)، برقراری کے منحنی اور would-be-disappointed سکور جیسے پروڈکٹ-مارکیٹ-فٹ کے اشارے مقدار بنائے جاتے ہیں، اور RICE Confidence جیسے فریم ورک کے ان پٹس کو اس کے مقابل calibrate کیا جاتا ہے کہ داؤ اصل میں کیسے نکلے۔
سطح 5، ہم آہنگی: پروڈکٹ آپریٹنگ ماڈل پورٹ فولیو میں چلتا ہے اور مسلسل بہتر اور فنڈنگ اور حکمت عملی سے مربوط ہے۔ پائیدار ٹیمیں برسوں نتائج کی مالک ہیں اور اندرونی پلیٹ فارمز پروڈکٹس کے طور پر منظم ہیں؛ دریافت اور ترسیل مسلسل لوپ کرتی ہیں؛ نتائج کا ڈیٹا سرمایہ کاری کو چلاتا اور پورٹ فولیو کو تطبیقی طور پر دوبارہ متوازن کرتا ہے؛ پروڈکٹ آپریشنز پیمانے پر عمل کو مربوط رکھتا ہے؛ اور قیادت نتائج کا پورٹ فولیو منظم کرتی ہے، شہادت اور بازار بدلنے پر داؤ معمول سے ریٹائر، دوبارہ دائرہ بند، اور دوبارہ ترجیح دیتی ہے۔

بحث کے لیے خیالات

اپنا موجودہ روڈ میپ دیکھیں: کتنی اشیا قابل پیمائش نتیجہ بیان کرتی ہیں بمقابلہ محض فیچر اور تاریخ؟
آپ کی ٹیم میں کون گاہک کے تعلق کا اتنا مالک ہے کہ پچھلے ہفتے کی گفتگو یاد سے بیان کر سکے؟
آپ کے حالیہ فیچرز میں سے کون سے آپ مار دیتے اگر آپ پہلے سب سے خطرناک مفروضے پر سستا تجربہ چلاتے؟
آپ کہاں غیر امتیازی صلاحیت بنا رہے ہیں جسے آپ خرید یا شراکت سے لے سکتے ہیں، اور یہ آپ کو کیا لاگت دے رہی ہے؟
کیا آپ کے پاس پروڈکٹ-مارکیٹ فٹ ہے، اور آپ فرض کرنے کی بجائے واقعی کیسے جانیں گے؟
پروڈکٹ آپریٹنگ ماڈل کی طرف آپ کا سب سے چھوٹا قدم کیا ہو سکتا ہے، اور کون سی نظم و نسق کی رکاوٹ راستے میں ہے؟

اہم نکات

پروڈکٹ مینجمنٹ کیا اور کیوں کی مالک ہے، اور نتائج کی جوابدہ ہے، کاموں کو ہم آہنگ کرنے یا درخواستیں نقل کرنے کی نہیں۔
بنانے سے پہلے کامیابی کو گاہک یا کاروباری رویے کی ناپی گئی تبدیلی کے طور پر متعین کر کے فیچر فیکٹری سے بچیں۔
ترسیل کے ساتھ مسلسل دریافت چلائیں: ہر ہفتے گاہکوں سے بات کریں اور سب سے خطرناک مفروضہ سستے ترین تجربے سے آزمائیں (باب 11.1)۔
ترجیح کے فریم ورکس (RICE، weighted scoring، تاخیر کی لاگت، Kano) کو فیصلے کے معاون کے طور پر استعمال کریں، کبھی غیب گو نہیں۔
روڈ میپس کو ارادے کے بیانات سمجھیں (now/next/later): مسائل اور نتائج پر مضبوطی سے، حلوں پر ڈھیلے commit کریں۔
trio کو بااختیار بنائیں اور سرمایہ کاری سے پہلے مطلوبیت، عملی ہونا، ممکن ہونا، اور استعمال پذیری کی توثیق کریں (باب 5.1)۔
انٹرپرائز اور حکومت میں پراجیکٹ آپریٹنگ ماڈل سے پروڈکٹ آپریٹنگ ماڈل کی طرف جائیں، پراجیکٹس نہیں سروسز کو فنڈ کریں، اور پروڈکٹ آپریشنز میں سرمایہ کاری کریں (ابواب 10.1، 11.4)۔

حوالہ جات اور مزید مطالعہ

Marty Cagan, Inspired and Empowered (empowered product teams, the product operating model).
Marty Cagan and Chris Jones, Transformed (moving to a product operating model).
Teresa Torres, Continuous Discovery Habits (opportunity-solution trees, weekly customer contact).
Melissa Perri, Escaping the Build Trap (outcomes over outputs, product operations).
Roman Pichler, Strategise (product vision, strategy, and roadmaps).
C. Todd Lombardo, Bruce McCarthy, Evan Ryan, and Michael Connors, Product Roadmaps Relaunched (now/next/later roadmaps).
Dan Olsen, The Lean Product Playbook (product-market fit).
Eric Ries, The Lean Startup (minimum viable product, build-measure-learn).
Noriaki Kano et al., “Attractive Quality and Must-Be Quality” (Journal of the Japanese Society for Quality Control, 1984): origin of the Kano model.
Melissa Perri and Denise Tilles, Product Operations (scaling product practice).
U.S. Digital Service, Digital Services Playbook; UK Government Digital Service, Government Design Principles and Service Standard (public-sector, user-centred product delivery).