زیادہ تر لانچ سے پہلے کی صارف تحقیق ایک ڈرامہ ہے، اور سب سے بری بات یہ ہے کہ دونوں فریق اپنے مکالمے جانتے ہیں۔ آپ پوچھتے ہیں "کیا آپ ایسی چیز استعمال کریں گے،" اور کال کے دوسری طرف موجود شخص — جو نرمی سے پیش آ رہا ہے، جس کا کچھ داؤ پر نہیں، جو ایک ایسی پروڈکٹ کا تصور کر رہا ہے جو موجود ہی نہیں — کہتا ہے ہاں۔ آپ اسے تصدیق سمجھ کر لکھ لیتے ہیں۔ یہ تصدیق نہیں ہے۔ یہ ایک اجنبی کا ایک فرضی چیز کے بارے میں شائستگی دکھانا ہے۔
میں یہ انٹرویوز مذہبی جوش سے کیا کرتا تھا، کیونکہ ہر پروڈکٹ سٹریٹجی کی کتاب یہی سکھاتی ہے۔ کوڈ کی ایک لائن لکھنے سے پہلے پچاس صارفین سے بات کریں۔ درد کے نکتے کو تلاش کریں۔ حل سے پہلے مسئلے کی تصدیق کریں۔ یہ نظم و ضبط والا لگتا ہے، اور وائٹ بورڈ پر اچھا لگتا ہے۔ لیکن دس دریافتی کالوں کا اصل حاصل یہ ہے کہ دس لوگ آپ کو بتاتے ہیں کہ وہ آپ سے کیا سننا چاہتے سمجھتے ہیں، جو ان کی اپنی مبہم یاد سے فلٹر ہو کر آتا ہے، اس مسئلے کی جس کے بارے میں انہوں نے کال شروع ہونے کے بعد سے نہیں سوچا۔ کوئی جان بوجھ کر جھوٹ نہیں بولتا۔ ان کے پاس ابھی معلومات ہی نہیں ہوتیں — کیونکہ وہ معلومات اس وقت تک موجود نہیں ہوتی جب تک وہ چیز خود موجود نہ ہو۔
وہ چیز جو انٹرویوز پیدا نہیں کر سکتے
بنانے سے پہلے آپ کو اصل میں جو جاننے کی ضرورت ہے وہ رویے سے متعلق ہے، رویے کی جھلک نہیں: کیا کوئی شخص اس ایپ کو دوبارہ کھولے گا، کیا وہ اس کے لیے ادائیگی کرے گا، کیا وہ تیسری اسکرین پر پھنس کر چھوڑ دے گا۔ ان میں سے کچھ بھی بات چیت میں سامنے نہیں آتا۔ یہ سیشن ری پلے، ڈراپ آف چارٹ، سپورٹ ٹکٹ میں سامنے آتا ہے۔ ایک صارف پوری خلوص سے آپ کو بتا سکتا ہے کہ آن بورڈنگ "سمجھ آتی ہے،" اور پھر چالیس سیکنڈ میں اسے چھوڑ دے، کیونکہ خود بیانی اور رویہ دو مختلف آلات ہیں جو دو مختلف چیزیں ناپتے ہیں۔
معاشیات پہلے کبھی بھی انٹرویو-پہلے کے ترتیب پر مجبور کرتی تھی۔ اگر کوئی چیز بنانے میں آٹھ ہفتے اور تین انجینئرز لگتے ہیں، تو آپ اسے شپ کرنے کے بعد یہ جاننے کا خرچہ برداشت نہیں کر سکتے کہ یہ غلط ہے — اس لیے آپ خطرے کو سستی بات چیت میں پہلے سے شامل کر دیتے ہیں اور امید کرتے ہیں کہ وہ مہنگی غلطیوں کو پکڑ لیں گی۔ یہ سودا اس وقت معنی رکھتا تھا جب بنانا ہی رکاوٹ تھا۔ اب ایسا نہیں ہے۔ ایک کام کرنے والا پروٹو ٹائپ — حقیقی auth، حقیقی ڈیٹا بیس، ایک UI جسے کوئی اصل میں کلک کر کے دیکھ سکے — اب صحیح اوزاروں کے ساتھ، بشمول میرے اوزار، ایک دوپہر میں بنایا جا سکتا ہے۔ ایک بار جب پہلے ورژن کی لاگت اتنی کم ہو جائے، تو انٹرویو سستے رسک کم کرنے کا طریقہ نہیں رہتا بلکہ مہنگا قدم بن جاتا ہے۔ آپ ایک ایسی بلڈ سے بچنے کے لیے ہفتوں کے کیلنڈر وقت سے ادائیگی کر رہے ہوتے ہیں جس کی قیمت آپ کو صرف ایک ویک اینڈ کی ہوتی۔
میں اس کی بجائے کیا کرتا ہوں
آئیڈیا کا سب سے چھوٹا اصل ورژن بنائیں، اسے تین سے پانچ ایسے حقیقی لوگوں کے سامنے رکھیں جنہیں یہ مسئلہ درپیش ہے، اور دیکھیں، پوچھیں نہیں۔ "آپ نے کیا سوچا" نہیں — بلکہ کہاں آپ کا کرسر رکا، آپ نے کیا کلک کیا جس نے کچھ نہیں کیا، آپ نے کیا کرنے کی کوشش کی جسے پروڈکٹ نے سرے سے سپورٹ ہی نہیں کیا۔ وہ آخری چیز سونا ہے: وہ چیز جس کی انہوں نے بغیر کہے کوشش کی، کسی بھی فرضی انٹرویو میں کہی گئی بات سے زیادہ سچا اشارہ ہے، کیونکہ یہ ظاہر کی گئی ترجیح ہے نہ کہ بیان کردہ ترجیح۔
یہ روایتی ریسرچ فنل کو الٹ دیتا ہے، اور یہ واضح کرنا ضروری ہے کہ کیا بدلتا ہے:
| انٹرویو-پہلے | بلڈ-پہلے | |
|---|---|---|
| آپ کیا ناپ رہے ہیں | بیان کردہ ارادہ ("میں شاید یہ استعمال کروں گا") | ظاہر شدہ رویہ (انہوں نے اسے اس ہفتے تین بار کھولا، یا نہیں کھولا) |
| غلط ہونے کی لاگت | فی چکر کم، لیکن آپ درجنوں انٹرویوز میں مہینوں تک غلط رہ سکتے ہیں | ایک بلڈ سائیکل، پھر ڈیٹا آپ کو تیزی سے درست کر دیتا ہے |
| پوچھنے کے لیے بہترین سوال | "آپ آج کل یہ کام کرنے میں کیا چیز پریشان کن پاتے ہیں؟" | "مجھے دکھائیں کہ آپ نے آخری بار یہاں X کرنے کی کوشش کب کی" |
| یہ کس چیز میں اچھا ہے | کیا مسئلہ سرے سے موجود ہے | کیا اس کا آپ کا خاص حل کارآمد ہے |
| ناکامی کی صورت | سب مؤدب ہیں، کوئی بھی سچ نہیں بولتا، اور آپ پورے اعتماد کے ساتھ غلط چیز بنا لیتے ہیں | آپ اعتماد کمانے سے پہلے ہی کوئی نامکمل چیز شپ کر دیتے ہیں، اور پہلا تاثر خراب ہو جاتا ہے |
غور کریں کہ یہ دونوں قطاریں ایک دوسرے کو منسوخ نہیں کرتیں — یہ مختلف سوالات کا جواب دیتی ہیں۔ انٹرویوز اس بات کی تصدیق کرنے میں کافی اچھے ہیں کہ مسئلہ حقیقی ہے۔ لیکن یہ بتانے میں ناکام رہتے ہیں کہ آپ کا خاص حل درست ہے، کیونکہ آپ کا خاص حل ابھی کسی کے سامنے پیش ہی نہیں ہوا کہ وہ اس پر ایمانداری سے ردعمل دے سکے۔ یہی وہ فرق ہے جسے زیادہ تر "صارفین سے بات کریں" والی نصیحت نظرانداز کر دیتی ہے: یہ عام طور پر مسئلے کی دریافت کے لیے تو اچھی نصیحت ہے مگر حل کی تصدیق کے لیے بری، اور لوگ اسے دونوں پر لاگو کر دیتے ہیں۔
میری جاننے والی ایک بانی نے سیلون کے لیے بنائے گئے ایک شیڈولنگ ٹول کے لیے چودہ انٹرویوز کیے۔ تیرہ نے کہا کہ ڈبل بکنگ کا مسئلہ حقیقی اور تکلیف دہ ہے۔ اس نے یہ بنا دیا۔ لیکن اس کو اپنانے کی رفتار بالکل نہیں بڑھی۔ پتہ چلا کہ سیلون مالکان کو ڈبل بکنگ اصولاً ناپسند تھی، لیکن وہ پہلے ہی اپنے کمزور ذاتی طریقہ کار بنا چکے تھے جنہیں چھوڑنا نہیں چاہتے تھے — ایسی بات جس کا کسی نے ذکر نہیں کیا، کیونکہ جب تک آپ کسی متبادل کو دکھا کر انہیں اسے مسترد کرتے دیکھیں، کوئی بھی اپنے نمٹنے کے طریقے بیان کرنے کا سوچتا ہی نہیں۔
جہاں ناقدین درست ہیں
یہ ہر جگہ لاگو نہیں ہوتا، اور اگر میں ایسا ظاہر کروں تو یہ زیادہ بیچنا ہوگا۔ اگر تعمیر کو واپس پلٹنا واقعی مہنگا ہو — ہارڈویئر، کوئی ریگولیٹڈ میڈیکل ورک فلو، یا ہر تبدیلی کے ساتھ منسلک کوئی تعمیل جائزہ — تو انٹرویو-پہلے والا حساب کتاب پلٹ جاتا ہے، کیونکہ وہ لاگت کا عدم توازن جو تعمیر-پہلے کو سستا بناتا ہے، وہاں سرے سے موجود ہی نہیں ہوتا۔ ایک پروٹوٹائپ جسے آپ ایک شام میں پھینک سکتے ہیں، اس ڈیوائس سے بالکل مختلف چیز ہے جس کے لیے آپ نے سانچہ (mold) بنوایا ہو۔
تحقیق کا دوسرا موقع جہاں کارآمد ثابت ہوتی ہے، وہ ہے طویل سیلز سائیکل والی انٹرپرائز فروخت۔ اگر آپ کا خریدار کوئی پروکیورمنٹ کمیٹی ہے اور آپ کا سیلز سائیکل چار مہینے کا ہے، تو آپ "بس شپ کر دیں اور دیکھیں" کے راستے سے دستخط شدہ معاہدے تک نہیں پہنچ سکتے — آپ کو تعمیر سے پہلے یہ جاننا ضروری ہے کہ آیا یہ چیز سکیورٹی جائزے سے گزرے گی بھی یا نہیں، کیونکہ چھ مہینوں بعد رد ہونے والے سودے کی لاگت کسی بھی انٹرویو سے کہیں زیادہ ہوتی ہے۔ اور خالص مسئلہ دریافت، جو جلد اور سستے میں کی جائے — یعنی کسی کے ساتھ بیٹھ کر اسے اس کا اصل کام کرتے دیکھنا، نہ کہ اس سے کسی مستقبل کی پروڈکٹ کا تصور کرنے کو کہنا — واقعی کم استعمال ہوتی ہے اور واقعی مفید ہے۔ میں لوگوں سے بات کرنے کے خلاف نہیں ہوں۔ میں ایک مؤدب فرضی گفتگو کو بطور ثبوت سمجھنے کے خلاف ہوں، جبکہ اسی شخص کے سامنے دس منٹ کے لیے رکھی ایک کھردری، حقیقی چیز اس کے بجائے سچائی بتا دے گی۔



