- ज़्यादातर उपयोगकर्ता application की केवल लगभग 20% features ही इस्तेमाल करते हैं, और वह 20% हर उपयोगकर्ता के लिए अलग होता है
- बाकी की 80% features को रुकावट भी माना जा सकता है, और वे उल्टा असुविधा या असंतोष पैदा करती हैं
- अगर niche market को सटीक रूप से target किया जाए, तो एक मज़बूत user base बनाया जा सकता है
- Kagi, Figma, Notion जैसे उदाहरण, जिन्होंने बड़ी कंपनियों द्वारा नज़रअंदाज़ किए गए 20% को अच्छी तरह हल करके एक high-loyalty market बनाया, नए market opportunity दिखाते हैं
- VS Code, Slack, Discord extensibility और personalization के ज़रिए उपयोगकर्ताओं को अपना खुद का 20% optimize करने में मदद करते हैं
- असली बात सभी के लिए product बनाने की नहीं, बल्कि ऐसा tool बनाने की है जो हर व्यक्ति की ज़रूरी चीज़ को गहराई से संतुष्ट करे, और यही feature bloat की समस्या से बचने का रास्ता है
बचपन के अनुभव और software इस्तेमाल करने का तरीका
- लेखक बचपन में 2GB storage space मैनेज करने के लिए बेकार files delete करता था और इस चक्कर में अक्सर computer खराब कर देता था
.ini file जैसी महत्वपूर्ण system files delete करने के बाद Windows और Office 97 को शुरू से फिर install करना पड़ता था
- लेखक के पिता ज़ोर देकर कहते थे कि Excel install ज़रूर करना, लेकिन लेखक के लिए Excel बस Word में table paste करने का एक tool था
- Excel की ढेर सारी features में से केवल table copy/paste ही उसके लिए मायने रखता था
- लेखक का एक परिचित भी Excel को सिर्फ घरेलू खर्च लिखने के लिए इस्तेमाल करता था, और बाकी features को छूता तक नहीं था
सबका अलग 20%
- software इस्तेमाल में '80/20 rule' मौजूद है: ज़्यादातर उपयोगकर्ता कुल features के सिर्फ 20% का ही इस्तेमाल करते हैं
- लेकिन हर उपयोगकर्ता जिस 20% पर ध्यान देता है, वह अलग होता है, और उसे लगता है कि वही हिस्सा सबसे महत्वपूर्ण है
- उदाहरण: Word में table बनाना इस्तेमाल करते हैं लेकिन mail merge नहीं, Excel में pivot table इस्तेमाल करते हैं लेकिन script नहीं, PowerPoint में animation का उपयोग नहीं करते
- नई features जोड़ने या UI बदलने वाले updates की वजह से लोगों को लगता है कि application धीमा हो गया है या उसमें गैर-ज़रूरी features बढ़ गई हैं, जिससे असंतोष पैदा होता है
- जो 80% features इस्तेमाल नहीं होतीं, वे उल्टा 20% के workflow में रुकावट डालने वाली चीज़ की तरह महसूस हो सकती हैं
परफेक्ट नतीजे की चाह
- यह phenomenon सिर्फ Microsoft में नहीं, बल्कि दूसरी IT कंपनियों में भी इसी तरह दिखाई देता है
- उदाहरण के लिए, जब Google Search में सटीक keyword search चाहिए होती है, तब गैर-ज़रूरी related term results उल्टा निराशा पैदा करते हैं
- कंपनी की नज़र में यह "1% users की demand" हो सकती है, लेकिन 1 अरब लोगों का 1% यानी 1 करोड़ लोग एक बहुत बड़ा market है
- Kagi ने Google द्वारा नज़रअंदाज़ किए गए छोटे market पर ध्यान केंद्रित कर privacy-protecting, ad-free, quality-focused search के अंतर के साथ market को target किया
- बड़ी कंपनियों की कमियों पर ध्यान देकर छोटे user groups को संतुष्ट करने वाला niche market बनाया जा सकता है
- सभी को संतुष्ट करने की ज़रूरत नहीं; किसी खास group के 20% experience को पूरी तरह संतुष्ट करने की strategy बनाना संभव है
भूले हुए 20% को ढूँढना
- कई innovative कंपनियाँ उन विशिष्ट user groups पर फोकस करती हैं जिन्हें बड़ी कंपनियाँ मिस कर देती हैं
- Figma ने collaborative design में Adobe को पीछे छोड़ने पर फोकस किया, और Notion भी खास उपयोगकर्ता ज़रूरतों के लिए optimize हुआ hybrid tool बनकर स्थापित हुआ
- सफल software समय के साथ features बढ़ाते जाते हैं, लेकिन इस प्रक्रिया में कुछ उपयोगकर्ताओं का 20% दब जाता है और वहाँ एक niche बन जाती है
- open source software इस क्षेत्र में मज़बूत है, क्योंकि उसके ज़रिए खास workflows के लिए custom builds बनाई जा सकती हैं
- उदाहरण के तौर पर Blender में केवल architectural visualization के लिए lightweight version विकसित किया जा सकता है
सही 20% के लिए design
- यह philosophy VS Code में अच्छी तरह लागू होती है
- इसकी default functionality simple text editing पर केंद्रित है, लेकिन extensions के ज़रिए हर व्यक्ति अपना मनचाहा development environment बना सकता है
- यह ऐसा structure है जिसमें सभी उपयोगकर्ता अपने-अपने 20% को customize कर सकते हैं
- Slack integrations, Discord bots भी इसी सिद्धांत पर उपयोगकर्ताओं को अपना अनुभव सीधे customize करने में मदद करते हैं
- शुरुआत से ही सभी उपयोगकर्ताओं के 20% का अनुमान लगाना मुश्किल है, लेकिन extensibility और customization देने पर हर कोई अपने लिए सर्वोत्तम उपयोग बना सकता है
निष्कर्ष: सभी उपयोगकर्ताओं के लिए product से बेहतर है, हर व्यक्ति के 'ज़रूरी 20%' पर फोकस
- अगर हर feature में अच्छा बनने की कोशिश करेंगे, तो आखिरकार software भारी और असंतोष बढ़ाने वाला बन जाएगा
- यह ज़रूरी है कि हर feature उसे खोजने वाले खास उपयोगकर्ता के लिए पूरी तरह काम करे
- उपयोगकर्ता वैसे भी कुल features में से केवल कुछ का ही इस्तेमाल करेंगे, इसलिए किसी खास feature को सचमुच बेहतरीन बनाने पर ध्यान देना ज़्यादा असरदार है
- यह मानना ज़रूरी है कि software का उपयोग उन तरीकों से भी हो सकता है जिनकी पहले कल्पना नहीं की गई थी, और planning में इस विविधता को स्वीकार करना चाहिए
- उपयोगकर्ताओं पर सब कुछ थोपने के बजाय, केवल उन हिस्सों पर development करना जो वास्तव में पसंद किए जाते हैं, अधिक संतुष्टि देता है
2 टिप्पणियां
हर चीज़ पर बस Pareto law थोप देते हैं;; 15% भी हो सकता है, है ना? हाहा
Hacker News राय
जिस एक SaaS कंपनी में मैंने काम किया था, वहाँ हमने यह विश्लेषण करने की कोशिश की थी कि यूज़र वास्तव में किन फीचर्स के सिर्फ एक हिस्से का इस्तेमाल करते हैं। मकसद था कुछ मुख्य यूज़र प्रकारों के हिसाब से प्रोडक्ट की जटिलता कम करना और परेशान करने वाले फीचर्स हटाना। नतीजा यह निकला कि लॉगिन स्क्रीन को छोड़कर, हर किसी के लिए महत्वपूर्ण 20% पूरी तरह अलग था। विश्लेषण का परिणाम वेटेड रैंडम सैंपलिंग से अलग नहीं था
इससे पूरी तरह सहमत हूँ। लेकिन जैसे ही आप एंटरप्राइज़ ग्राहकों को प्रोडक्ट बेचना शुरू करते हैं, स्थिति पूरी तरह बदल जाती है। एक भी "हाइजीन फीचर" की कमी डील बिगाड़ सकती है। और हर एंटरप्राइज़ के लिए ज़रूरी फीचर्स भी अलग होते हैं। यहाँ हाइजीन फीचर का मतलब उस न्यूनतम आवश्यक चीज़ से है जिसकी ज़रूरत सबको होती है, जैसे टॉयलेट
यह पोस्ट मुझे Spolsky के ब्लॉग लेखों की याद दिलाती है
strategy-letter-iv-bloatware-and-the-8020-myth
simplicity
मैंने अपने लिए एक hobby app बनाया था और कभी-कभी सोचता हूँ कि उसे polish करके public करूँ। लेकिन मेरे पास उसे promote या लोगों तक पहुँचाने की ज़रा भी इच्छा नहीं है, इसलिए उसे public करना बेकार लगता है। सच कहूँ तो बड़ा कारण यह है कि जिन बाकी 80% फीचर्स का मैं खुद इस्तेमाल नहीं करता, उन्हें बनाने का भी मन नहीं है
मार्केटिंग में Modified Pareto नाम का एक विचार है। यह 80/20 नहीं बल्कि 60/20 है। 20% heavy users प्रोडक्ट की 60% वैल्यू consume करते हैं, और 80% light users 40% consume करते हैं। यह इतना छोटा हिस्सा नहीं है कि उसे नज़रअंदाज़ कर दिया जाए, इसलिए हल्के यूज़र्स पर भी ध्यान देना ज़रूरी है
value-paretos-bottom-80
यही चलता रहता है। असल में यह कहीं ज़्यादा महत्वपूर्ण है कि यूज़र यह 'महसूस' करें कि सॉफ़्टवेयर उनकी समस्या हल कर सकता है। अगर आप उनसे पैसा खर्च करवाना चाहते हैं, तो उन्हें यह एहसास होना चाहिए कि सॉफ़्टवेयर संभावित रूप से उनकी कई तरह की समस्याएँ भी हल कर सकता है। उन समस्याओं में वे फीचर्स भी शामिल हो सकते हैं जिन्हें यूज़र खुद शायद कभी इस्तेमाल न करें। उदाहरण के लिए 3D software में rigging system भले ही 2% यूज़र्स सिर्फ 1% समय के लिए इस्तेमाल करें, लेकिन उसके बिना कुछ लोग प्रोडक्ट पर विचार ही नहीं करेंगे
मुझे अपने काम का उपयोग वास्तव में कैसे होगा, इसका अंदाज़ा लगाने में महारत नहीं है, इसलिए मैं अक्सर सिर्फ वही तरीका पसंद करता हूँ जिसे "Desire paths" कहा जाता है — यानी लोगों के पहले से बने रास्तों को पक्का करना
the-road-most-traveled-by-paving
मैं इस बात से सहमत हूँ कि "फीचर बढ़ने से रोकने की कोशिश करने के बजाय, यह स्वीकार करना चाहिए कि सॉफ़्टवेयर ऐसे तरीकों से इस्तेमाल हो सकता है जिनकी आपने कभी कल्पना भी नहीं की थी।" इसी वजह से मुझे लगता है कि interoperability सॉफ़्टवेयर का सबसे महत्वपूर्ण पहलू है। मुझे इस लेख की मुख्य समस्या यह लगती है कि अलग-अलग सॉफ़्टवेयर और अलग-अलग versions के file formats बंद और सीमित होते हैं। मुझे कई tools को मिलाकर इस्तेमाल करने में समस्या नहीं है, समस्या यह है कि वे tools pipeline में साथ मिलकर ठीक से काम नहीं करते। Unix का सपना सच में बहुत कठिन लगता है
किसी भी कुछ हद तक बड़े app में लगभग कभी ऐसा नहीं होता कि हर फीचर का 100% उपयोग हो। मेरे अनुभव में लगभग हर application में 10~30% हिस्सा ऐसा होता है जिसका लगभग कोई उपयोग नहीं करता। आमतौर पर यह या तो ऐसे वर्कफ़्लो होते हैं जिन्हें डेवलपमेंट टीम के अलावा कोई समझ ही नहीं सकता, या वे बहुत ख़राब और अक्षम होते हैं, या फिर वे इतने बुनियादी फीचर्स होते हैं कि जिन कंपनियों को वास्तव में उनकी ज़रूरत है, उनके पास उस सॉफ़्टवेयर को खरीदने की आर्थिक क्षमता ही नहीं होती
सही है, लेकिन बहुत से यूज़र्स के लिए अलग-अलग 20% फीचर्स महत्वपूर्ण होते हैं, इसलिए मौजूदा यूज़र संख्या बनाए रखने के लिए आपको सभी फीचर्स बनाए रखने पड़ते हैं। फिर भी, अगर आप ऐसे फीचर्स हटा दें जो मुश्किल से इस्तेमाल होते हैं लेकिन maintenance या development में बहुत समय खाते हैं, तो ROI बढ़ता है
लेकिन यूज़र ज़रूरी नहीं कि उसी 20% को महत्वपूर्ण मानें। एक और बात यह है कि यूज़र app इस्तेमाल करने से पहले अक्सर ठीक से जानते ही नहीं कि उसमें कौन से फीचर्स हैं। install करने का फ़ैसला app में वास्तव में मौजूद फीचर्स पर नहीं, बल्कि install से पहले यूज़र की अपनी अपेक्षाओं पर आधारित होता है। यह बहुत महत्वपूर्ण अंतर है। आप फीचर्स पर मेहनत कर सकते हैं, लेकिन उसका लाभ अक्सर यूज़र हासिल करने के बाद ही मिलता है।
MVP बनाते समय यह खास तौर पर महत्वपूर्ण है, क्योंकि ज़्यादातर मामलों में install और retention को रोकने वाली चीज़ फीचर्स की कमी नहीं होती। आमतौर पर समस्या messaging, marketing, या फिर यह होती है कि यूज़र को आकर्षित करने लायक कोई वैल्यू ही नहीं है। अंधाधुंध फीचर जोड़ने से ये समस्याएँ हल नहीं होतीं। यह सुनने में सरल लगता है, लेकिन बहुत सी कंपनियाँ यही बात चूक जाती हैं।
सबसे सरल MVP तो यह भी हो सकता है कि आप कुछ भी implement किए बिना पहले लोगों से pre-register करवाएँ। इससे आप यह validate कर सकते हैं कि messaging सही पहुँच रही है या नहीं। अगर साइन अप के बाद वे निराश होते हैं, तो कम से कम यह तो साबित होता है कि messaging काम कर रही थी।
हालाँकि, इस तरीके का मतलब यह भी है कि आप MVP को उसके वादे से कम तैयार अवस्था में launch करते हैं, और अधूरे वादे से निराशा पैदा होने का जोखिम रहता है। साथ ही, कई फीचर्स वास्तव में इतने ज़रूरी नहीं होते, खासकर SaaS में, जहाँ बहुत सी चीज़ें ऐसी होती हैं जिनके लिए ग्राहक वास्तव में पैसे देने को तैयार नहीं होते। ग्राहकों की माँगों को तुरंत आवश्यक शर्त मान लेने के बजाय, यह साफ़ समझना ज़रूरी है कि क्या वे वास्तव में उसे 'वैल्यू' मानते हैं, क्या वे उसके लिए पैसे देने को तैयार हैं, और क्या वह सच में कोई महत्वपूर्ण pain point हल करती है। ग्राहक ने किसी फीचर की माँग क्यों की, यह समझना उसे तुरंत बना देने से कहीं ज़्यादा महत्वपूर्ण है