CB Insights हर साल इसका विश्लेषण प्रकाशित करता है कि स्टार्टअप क्यों विफल होते हैं। सालों से सबसे बड़ा कारण एक ही रहा है: "बाज़ार में कोई ज़रूरत नहीं।" कमज़ोर क्रियान्वयन नहीं। पैसा खत्म हो जाना नहीं। खराब टीम नहीं। प्रोडक्ट ने बस ऐसी समस्या हल नहीं की जिसके लिए लोग अपना व्यवहार बदलने को तैयार होते।
प्रोडक्ट बनाने में जितनी मेहनत लगती है, उसे देखते हुए यह आँकड़ा चौंकाने वाला है। टीमें महीनों — कभी-कभी सालों — सिस्टम डिज़ाइन करने, कोड लिखने, आर्किटेक्चर पर बहस करने और फ़्लो को निखारने में लगा देती हैं। और उनके विफल होने का सबसे आम कारण यह है कि किसी ने पूछा ही नहीं कि क्या इसमें से कुछ भी किसी असली समस्या को हल कर रहा है।
जिन प्रोडक्ट को लोग सचमुच चाहते हैं, उन्हें बनाना कोई जन्मजात प्रतिभा नहीं है। यह एक अनुशासन है। इसकी एक पद्धति है, और वह पद्धति सीखी जा सकती है।
प्रोडक्ट की सबसे आम गलती यह है कि समस्या को गहराई से समझने से पहले ही किसी समाधान से लगाव हो जाता है। पहली बार के संस्थापकों में यह लगभग हर किसी के साथ होता है, और अनुभवी संस्थापकों में भी हैरानी की हद तक आम है। पैटर्न हमेशा वही रहता है: किसी के पास एक विचार आता है, उसे वह बहुत आकर्षक लगता है, और वे बनाना शुरू कर देते हैं। ग्राहक बाद में याद आता है — ऐसा व्यक्ति जिसे मनाना है, समझना नहीं।
इसका इलाज जटिल नहीं है, पर अनुशासन माँगता है: समाधानों पर विचार करने से पहले समस्या पर उससे ज़्यादा समय लगाइए जितना आपको ज़रूरी लगता है। उन लोगों से बात कीजिए जिनके सामने यह समस्या है। उन्हें काम करते हुए देखिए। समझिए कि वे आज कौन-से जुगाड़ (वर्कअराउंड) इस्तेमाल करते हैं और वे अधूरे क्यों हैं। तभी आपके पास इतना संदर्भ होगा कि आप कुछ ऐसा डिज़ाइन कर सकें जो सचमुच फ़िट बैठे।
अच्छा प्रोडक्ट डेवलपमेंट सीधी रेखा नहीं है — यह एक लूप है। लूप का हर चक्कर मान्यताओं की जगह सबूत रखने का मौका है। जो टीमें लोगों के चाहे हुए प्रोडक्ट बनाती हैं, वे इस लूप को जल्दी और बार-बार पूरा करती हैं।
यह लूप कोई औपचारिकता नहीं है। हर चरण का एक तय नतीजा होता है, जो अगले चरण का इनपुट बनता है। चरण छोड़ देना — सबसे आम तौर पर समस्या से सीधे बिल्ड पर कूद जाना — ही वह चीज़ है जो निशाने से चूकने वाले प्रोडक्ट पैदा करती है।
हर समस्या हल करने लायक नहीं होती। प्रोडक्ट की एक अच्छी समस्या में तीन गुण होते हैं: वह बार-बार होती है (लोगों को अक्सर प्रभावित करती है, कभी-कभार नहीं), वह तीव्र है (लोग उसे इतनी शिद्दत से महसूस करते हैं कि राहत चाहते हैं), और मौजूदा समाधान सचमुच नाकाफ़ी हैं (सिर्फ़ इतना नहीं कि वे आपके बनाए समाधान से थोड़े अलग हैं)।
गलती यह होती है कि पहले गुण को पकड़ लिया जाता है और बाकी दो को अनदेखा कर दिया जाता है। "लोग मीटिंग में समय बर्बाद करते हैं" — यह समस्या बार-बार होती है। लेकिन अगर दर्द कम है — अगर लोगों ने काम चलाऊ वर्कअराउंड ढूँढ लिए हैं — तो हो सकता है कि इसे हल करना व्यावसायिक रूप से फ़ायदेमंद न हो। और अगर पहले से बारह टूल वही कर रहे हैं जो आप करना चाहते हैं, तो आपके पास यह बताने का बहुत ठोस कारण होना चाहिए कि लोग आपका ही टूल क्यों चुनेंगे।
प्रोडक्ट के दायरे में रिसर्च की छवि खराब है — इसे धीमी कंसल्टिंग फ़र्मों, मोटी रिपोर्टों और ऐसे निष्कर्षों से जोड़ा जाता है जिन्हें कोई नहीं पढ़ता। यह क्रियान्वयन की विफलता है, इस प्रथा की नहीं। अच्छी प्रोडक्ट रिसर्च तेज़ और विशिष्ट होती है, और जो आप बनाते हैं उसे बदल देती है।
रिसर्च का लक्ष्य यह पुष्टि करना नहीं है कि समस्या असली है। रिसर्च में भारी निवेश करने से पहले आपको इस पर पहले से भरोसा होना चाहिए। लक्ष्य समस्या को इतनी गहराई से समझना है कि आप जान सकें कि एक अच्छा समाधान कैसा दिखता है: यह समस्या ठीक-ठीक किसे है, किस संदर्भ में, उन्होंने पहले क्या आज़माया है, वे इसे बताने के लिए कौन-से शब्द इस्तेमाल करते हैं, और उनके लिए "हल हो गया" का मतलब क्या होगा।
परिकल्पना (हाइपोथीसिस) एक विशिष्ट, खंडन-योग्य भविष्यवाणी है कि आप क्या सच मानते हैं। यह स्पष्टता के लिए मजबूर करती है। अगर आप स्पष्ट परिकल्पना नहीं लिख सकते, तो आप समस्या को अभी इतना नहीं समझ पाए हैं कि उसका समाधान बना सकें।
प्रोडक्ट की एक काम की परिकल्पना के तीन हिस्से होते हैं:
संकेत सबसे अहम हिस्सा है — और सबसे ज़्यादा छोड़ा जाने वाला भी। पहले से तय संकेत के बिना हर प्रयोग "कुछ हद तक सफल" ही रहता है। टीमें अस्पष्ट डेटा की अपने पक्ष में व्याख्या करने के तरीके ढूँढ लेती हैं। खंडन की शर्त के बिना परिकल्पना बस एक इच्छा है।
बिल्ड वाले चरण में ज़्यादातर टीमें बहुत ज़्यादा समय लगा देती हैं। लक्ष्य प्रोडक्ट बनाना नहीं है — लक्ष्य वह न्यूनतम चीज़ बनाना है जो आपकी परिकल्पना पर आपको संकेत दे। ये अलग-अलग उद्देश्य हैं और इनके नतीजे बहुत अलग होते हैं।
शुरुआती दौर की ज़्यादातर परिकल्पनाओं के लिए न्यूनतम उससे कहीं कम होता है जितना टीमें सोचती हैं। क्या आप दस लोगों के लिए वह काम हाथ से कर सकते हैं जो सॉफ़्टवेयर करता, ताकि परखा जा सके कि वे नतीजे को कितना महत्व देते हैं? क्या आप नया इन्फ्रास्ट्रक्चर बनाने से पहले मौजूदा टूल जोड़कर वर्कफ़्लो को परख सकते हैं? क्या आप कोई भी कोड लिखने से पहले प्रोटोटाइप का स्केच बनाकर पाँच यूज़र्स को उसमें से गुज़ार सकते हैं?
यहाँ अनुशासन यह है कि कुछ भी बनाने से पहले पूछें: "मैं क्या सीखना चाहता हूँ?" और "उसे सीखने के लिए न्यूनतम चीज़ क्या होगी?" जवाब लगभग हमेशा उससे छोटा होता है जो टीम बनाना चाहती है।
लॉन्च के बाद — चाहे वह प्रोटोटाइप हो, मैन्युअल पायलट हो या लाइव फ़ीचर — मापन वाला चरण वही है जहाँ टीमें सबसे ज़्यादा खुद को धोखा देती हैं। वे यूज़र्स से पूछती हैं कि उन्हें यह पसंद आया या नहीं। यूज़र्स हाँ कहते हैं। टीम प्रयोग को प्रमाणित घोषित कर देती है।
भावना संकेत नहीं है। एकमात्र भरोसेमंद संकेत व्यवहार है: क्या लोगों ने वह काम किया? क्या वे लौटकर आए? क्या उन्होंने भुगतान किया? क्या उन्होंने किसी और को बताया?
मात्रात्मक मापन के लिए लॉन्च से पहले इंस्ट्रूमेंटेशन कर लें। तय रखें कि आप कौन-सी खास गतिविधियाँ ट्रैक कर रहे हैं। पहले से एक सीमा तय करें — "अगर Z दिनों के भीतर X% यूज़र Y पूरा करते हैं, तो हम इसे प्रमाणित मानेंगे।" गुणात्मक मापन के लिए खुले-ढीले संतुष्टि सर्वे नहीं, बल्कि संरचित फ़ॉलो-अप इंटरव्यू करें।
सीखने वाला चरण यूज़र और समस्या के बारे में आपके मानसिक मॉडल को अपडेट करने का है, सिर्फ़ यह तय करने का नहीं कि आगे क्या बनाना है। जो टीमें यह चरण छोड़ देती हैं, वे डेटा तो जुटा लेती हैं पर समझ जमा नहीं करतीं। वे तेज़ी से काम निपटाती हैं, लेकिन समय के साथ उनकी परख बेहतर नहीं होती।
एक अच्छे लर्निंग सेशन में ये सवाल पूछे जाते हैं: हमने क्या अनुमान लगाया था? असल में क्या हुआ? यह अंतर हमारी मान्यताओं के बारे में क्या बताता है? अब वह सबसे अहम चीज़ क्या है जो हम नहीं जानते?
सीखने वाले चरण का नतीजा या तो समस्या की ज़्यादा सटीक परिभाषा होता है, या संशोधित परिकल्पना, या — अगर प्रयोग साफ़ तौर पर विफल रहा — पूरी तरह अलग दिशा में जाने का फ़ैसला। ये सभी नतीजे मूल्यवान हैं। सबसे बुरा नतीजा अस्पष्टता है: "हमने कुछ बातें सीखीं, लेकिन पक्का नहीं कि आगे क्या करना है।" यह इस बात का संकेत है कि प्रयोग पर्याप्त रूप से विशिष्ट नहीं था।
प्रोडक्ट डेवलपमेंट में ऐसा कोई चरण नहीं आता जहाँ आप यह लूप चलाना बंद कर दें। सवाल बदलते हैं — शुरू में आप परख रहे होते हैं कि समस्या असली है या नहीं; बाद में यह कि कोई खास समाधान-तत्व काम कर रहा है या नहीं — लेकिन ढाँचा हमेशा वही रहता है। अवलोकन कीजिए, परिकल्पना बनाइए, परखिए, सीखिए।
लोगों के चाहे हुए प्रोडक्ट बनाने वाली टीमें वे नहीं होतीं जिनकी शुरुआती समझ सबसे चतुर होती है। वे वे होती हैं जो लूप को सबसे तेज़ी से और सबसे ईमानदारी से पूरा करती हैं। सीखने की रफ़्तार, शिप करने की रफ़्तार नहीं, असली प्रतिस्पर्धात्मक बढ़त है।