अनावश्यक तत्वों को हटाने का महत्व
(gkogan.co)- अधिक जटिल हो चुका उत्पाद, ज़्यादा व्याख्या की बजाय अनावश्यक तत्वों को हटाकर बेहतर बन सकता है, और Pinecone के pricing calculator का मामला यह दिखाता है
- pricing calculator का उद्देश्य usage-based cost का पहले से अनुमान लगाने में मदद करना था, लेकिन input में छोटी-सी गलती से भी अनुमानित लागत अधिकतम 1,000 गुना तक बढ़कर sign-up को रोक देती थी
- अंदरूनी तौर पर समस्या को व्याख्या और default values जोड़कर ठीक करने की कोशिश की गई, लेकिन इन बदलावों ने एक नई उलझन पैदा कर दी और समर्पित Slack चैनल में 550 से अधिक संदेश जमा हो गए
- calculator हटाने वाले A/B test में, calculator न देखने वाले visitors के sign-up करने की संभावना 16% अधिक थी, inquiry करने की संभावना 90% अधिक थी, और pricing से जुड़े support tickets में कोई बढ़ोतरी नहीं हुई
- एक बार जो तत्व जोड़ दिया जाता है, उसका मूल्य घट जाने पर भी उसे बने रहने देना आसान होता है, इसलिए product, project और process में बड़े हिस्सों को हटाने के फ़ैसले की सचेत समीक्षा करनी चाहिए
Pinecone pricing calculator हटाने का मामला
- Pinecone ने usage-based pricing model में pricing page पर cost calculator रखा, क्योंकि उपयोगकर्ताओं के लिए वास्तविक लागत का पहले से सही अनुमान लगाना कठिन था
- संभावित उपयोगकर्ताओं से बात करके पता चला कि कुछ लोग calculator में बहुत अधिक अनुमानित लागत देखकर sign-up छोड़ रहे थे
- वह use case Pinecone के मानकों के हिसाब से काफ़ी छोटा था
- calculator अपेक्षा से कहीं ज़्यादा उलझाऊ और संवेदनशील था
- छोटी-सी गलतफ़हमी या गलत input से भी अनुमानित लागत अधिकतम 1,000 गुना बढ़ा-चढ़ाकर दिख सकती थी
- calculator ने उपयोगकर्ताओं को ग़लत भरोसा दिया, और वे documentation देखने, टीम से पूछने या सीधे product इस्तेमाल करके जाँचने के बजाय calculator की संख्या को ही वास्तविक लागत मान लेते थे
- त्वरित प्रतिक्रिया में व्याख्या, disclaimer, details और default values जोड़े गए, लेकिन एक उलझन कम करने की कोशिश दूसरी उलझन पैदा कर रही थी
- अंदरूनी चर्चा भी बढ़ती गई; समर्पित Slack चैनल में 550 से अधिक संदेश जमा हो गए, और meetings व documents पर बहुत समय लगा
- एक व्यक्ति ने पूछा, “क्या calculator सच में ज़रूरी है?”, लेकिन शुरुआत में यह सवाल बहुमत की राय के बीच दब गया
- बाद में यह जाँचने के लिए A/B test किया गया कि calculator और उससे पैदा हुई समस्याएँ हटाने पर भी क्या कोई मूल्य कम होता है
- calculator न देखने वाले visitors, calculator देखने वालों की तुलना में sign-up करने की 16% अधिक संभावना रखते थे
- inquiry करने की संभावना 90% अधिक थी
- pricing से जुड़े support tickets में कोई बढ़ोतरी नहीं हुई
- आंतरिक सर्वे में कंपनी के 10 में से 7 लोगों ने अनुमान लगाया था कि calculator वाला version बेहतर होगा, लेकिन test का परिणाम इसके उलट था
हटाना कठिन क्यों है
- कई संगठन समस्या हल करते समय घटाने की बजाय पहले जोड़ने के बारे में सोचते हैं
- हटाने से बड़ा लाभ मिल सकता है, फिर भी यह सहज विकल्प नहीं बन पाता
- संबंधित research के रूप में People systematically overlook subtractive changes का उल्लेख किया गया है
- reward system भी आम तौर पर कुछ जोड़ने वालों के पक्ष में होता है, और हटाने के लिए incentives कम ही होते हैं
- हटाने पर भी reward होना चाहिए, इसका उदाहरण Negative 2000 Lines Of Code से दिया गया है
- जिस व्यक्ति ने किसी तत्व को जोड़ने के लिए ज़ोरदार तर्क दिया हो, उसके लिए यह मानना कठिन होता है कि वह अब मूल्य नहीं जोड़ रहा
- अगर कोई दूसरे व्यक्ति द्वारा जोड़े गए तत्व को हटाने की बात करे, तो यह उस व्यक्ति के निर्णय या काम पर हमला जैसा लग सकता है, इसलिए उसे वैसे ही छोड़ देना आसान होता है
- अक्सर लोग मान लेते हैं कि जो चीज़ पहले से मौजूद है, वह किसी अच्छे कारण से है, और उसकी दोबारा समीक्षा नहीं करते
- मौजूदा स्थिति की आदत पड़ जाने पर लोग हटाने पर पर्याप्त विचार करने से पहले ही बदलाव से कतराने लगते हैं
- गैर-ज़रूरी तत्वों को साहस के साथ काटकर की गई simplification, बेहतर customer response rate, अधिक भरोसेमंद systems, और तेज़ growth व revenue ला सकती है
- छोटे-छोटे edits की बजाय project, product और process के बड़े हिस्सों को हटाने का विकल्प चुनना ज़रूरी है, और जिन हटाने वाले फ़ैसलों पर टीम का तीखा विरोध हो, उनमें अक्सर सबसे बड़ा लाभ छिपा हो सकता है
1 टिप्पणियां
Hacker News की रायें
मुझे नहीं पता यह calculator अच्छा था या खराब, लेकिन तर्क ऊपर-ऊपर से काफी बेतुका लगता है
अगर आप users से यह बात छिपाएँ कि product की cost ज्यादा हो सकती है, तो sign-up बढ़ना स्वाभाविक है। वे वास्तव में बेहतर स्थिति में आए या नहीं, यह इस पर निर्भर करता है कि बाद में उन्हें कोई नाराज़ करने वाला bill मिलता है या नहीं, और यह sign-up page के छोटे A/B test से पता नहीं चल सकता
ऐसे उदाहरण भी अक्सर दिखते हैं कि search result snippets से जानकारी हटाने पर click-through rate बढ़ गया। पहले snippet में मौजूद जानकारी देखने के लिए अब click करना पड़ेगा, इसलिए clicks बढ़ना स्वाभाविक है, लेकिन वास्तव में कौन-सा विकल्प बेहतर है, यह बात भुला दी जाती है
दुविधा यह थी कि “ऐसे cases को कैसे ठीक किया जाए”, और समाधान था “खराब calculator हटा दें।” उन्होंने 1000 गुना cost नहीं छिपाई, बल्कि गलत 1000 गुना estimate के कारण users खोने से बचा
car dealers द्वारा online price check मुश्किल बनाना और email या visit के लिए प्रेरित करना इसका उदाहरण है। calculator comparison shopping आसान बनाता है, और कई कंपनियों को यह पसंद नहीं होता। चाहे जानबूझकर हो या नहीं, यह consider करने लायक motivation है
user के लिए transparent होंगे तो वह और confused होगा ही। क्योंकि comparison criteria ही users को slaughterhouse की ओर हाँकी जाने वाली बेवकूफ livestock की तरह treat करता है। इस criteria में user को सोचने वाला इंसान मानने वाला कोई भी feature confusion पैदा करेगा और conversion rate को नुकसान पहुँचाएगा
जाहिर है price page बदसूरत हो गया, लेकिन “sign-ups बढ़ रहे हैं” इसलिए कोई फर्क नहीं पड़ा। इस case में calculator terminology से परिचित न होने वाले लोगों के लिए भारी लग सकता है, लेकिन पहले सहज फैसला “इसे simplify कैसे करें?” होना चाहिए था। हर चीज़ को statistically analyze और prove करना ही चाहिए—ऐसी A/B testing culture मुझे पसंद नहीं
अगर user शुरुआत में ही ठहरता नहीं, तो बाद में वह satisfied है या dissatisfied, यह कैसे test कर सकते हैं? loop बंद करके engagement बढ़ाएँ, तो बाद की interactions के जरिए customer को सही तरह educate और satisfy करने की संभावना भी बढ़ती है
मैंने upvote इसलिए किया क्योंकि इस लेख की बड़ी wisdom फैलाना चाहता था, लेकिन boundaries जल्दी धुंधली हो सकती हैं
“अगर इस हिस्से को हटाएँ, तो क्या कोई मूल्यवान चीज़ गायब होगी?” वाला mindset शुरुआती projects में कभी-कभी उल्टा असर कर गया। खासकर code और data में future value का अनुमान लगाना कठिन होता है
एक बार नए project में मैंने posts के tags के लिए extra metadata columns वाला शुरुआती SQL schema बनाया था, लेकिन अगले हफ्ते senior engineer ने YAGNI principle का हवाला देकर सब हटा दिया। उस समय roadmap में नहीं था, इसलिए technically सही था, लेकिन मूल काम करीब एक घंटे का था और data बनाए रखने की cost लगभग 0 थी
एक साल बाद वही columns जिस feature के लिए चाहिए थे, उसे बनाने वाला आखिरकार मैं ही था, और अब users वाली production DB migration सहित वही काम फिर करना पड़ा। इसलिए उल्टा यह भी सोचना चाहिए: “अगर इस हिस्से को हटाएँ, तो क्या कोई मूल्यवान चीज़ बनेगी?” इस लेख में जवाब साफ था, लेकिन मेरे case में ऐसा नहीं था
मुझे याद है SpaceX में एक metric है जो इसी तरह की concept पकड़ता है। हटाए गए features में से दूसरी बार फिर जोड़े गए features का ratio। अगर हटाए गए सारे features फिर से add हो जाएँ, तो feature recidivism rate 100% है, यानी आप बहुत बार काट रहे हैं; 70% भी ज्यादा है और 30% भी ज्यादा है
लेकिन 0% भी खराब है। अगर non-essential features हटाने की पर्याप्त कोशिश नहीं करेंगे, तो आखिरकार bloat हो जाएगा। product के शुरुआती दौर में यह ratio ज्यादा होना, और mature होने पर 0 नहीं लेकिन कम ratio तक उतरना बेहतर लगता है
मौजूदा समय में best product के लिए जरूरी exact feature set पता नहीं हो सकता, इसलिए unnecessary चीज़ें काटने के लिए probabilistic approach लेना ठीक है। जरूरत पड़े तो फिर add कर सकते हैं, और जब तक ऐसा बहुत बार न हो, पहले removal decision पर शक करने की वजह नहीं है
या फिर वास्तविक दुनिया में दोनों करके परिणाम देखने के बजाय, hypotheses और बिना कहे prior beliefs के proxy metrics पर 6 महीने meetings ही कर सकते हैं
फिर सवाल बनता है, “इसे use कर सकते हैं? delete कर सकते हैं?” और किसी को Knight Capital याद आ जाता है, जहाँ किसी ने पुराना field reuse किया और बड़ा हादसा हो गया। इसलिए existing fields छोड़ देना हमेशा ज्यादा safe बन जाता है, और अंत में
metadataऔरmetadata_1बन जाते हैं। अगले साल किसी को नहीं पता होता कि दो metadata fields क्यों हैं, और confusion और बढ़ जाती हैमेरे अनुभव का सबसे खराब codebase complex future use cases को ध्यान में रखकर design किया गया था। इस उदाहरण में भी codebase को column की जरूरत 1 साल बाद ही पड़ी। इसलिए future जरूरत के अनुमान पर बने हर code fragment को हटाने की precedent सही मानता हूँ। अंत में फिर जरूरत पड़ जाए, तब भी
किसी के लिए यह premature optimization है, तो किसी और के लिए “मैंने पहले ऐसा pattern देखा है और तब यह होता तो अच्छा होता, इसलिए इसे add करूँगा” है। कौन-सा पक्ष सही है, इसे reliably अलग करने का कोई तरीका नहीं दिखता
आपने जो स्थिति बताई, उसके मोटे तौर पर तीन outcomes हैं। पहला, field ठीक उसी तरह useful हो जाता जैसे शुरुआत में implement किया गया था। दूसरा, feature implement होता है लेकिन किसी दूसरे field या अलग implementation से बनता है। तीसरा, feature implement ही नहीं होता
तीनों विकल्पों की probability बराबर मानें, तो शुरुआत से बना कर रखना जीत सिर्फ एक-तिहाई cases में है। अगर उसे हटाया नहीं गया होता, तो इस बीच implement किए गए दूसरे features metadata column के साथ ठीक से काम करते हैं या नहीं, यह verify करने में कितनी cognitive cost लगी होती, यह भी सोचना चाहिए
इस बार आपका judgement सही था और project की समझ बेहतरीन थी, इसका मतलब है; लेकिन decision सही था या नहीं, यह बाद की सारी जानकारी जानने की स्थिति से नहीं, बल्कि उस समय उपलब्ध जानकारी से judge करना चाहिए
“कंपनी के अंदर हुई वोटिंग में 10 में से 7 लोगों ने माना कि calculator वाला version बेहतर होगा” वाला हिस्सा दिलचस्प है और एक typical dynamic दिखाता है
कुल मिलाकर लेख अच्छा था, लेकिन यह point और ज़्यादा highlight होने लायक था। अगर जुड़े हुए लोगों में से 30% calculator को खराब मानते हैं, तो भले ही majority को वह ठीक लगे, यह potentially बड़ी समस्या का संकेत है
यहां politics से सावधान रहना चाहिए। लोग आम तौर पर बिना किसी राजनीतिक लाभ के दूसरी team की आलोचना नहीं करना चाहते। इसलिए अगर कंपनी से पूछा जाए, “हमारी team ने जो यह बनाया है, क्या इसका net positive असर है?”, तो default जवाब अक्सर “हां” हो जाता है, क्योंकि लोग बेवजह विवाद नहीं खड़ा करना चाहते
ऐसे में अगर 30% लोगों ने value destruction की संभावना जताई, तो यह जितना दिखता है उससे कहीं ज़्यादा महत्वपूर्ण है। उन्होंने ऐसा क्यों सोचा, इसे काफी गहराई से जांचना चाहिए। इस मामले में सचमुच इस बात का ध्यान रखा गया और अंत अच्छा रहा, लेकिन यह voting result शुरुआत से ही एक गंभीर समस्या का सबूत था
जब stakeholders के हित मिल जाते हैं, तो बात और जटिल हो जाती है। Sales हर तरह के dark patterns चालू करना चाहेगी, और customer support cart में extended warranty अपने-आप add होने के कारण refunds handle करते-करते तंग आ सकता है
लेख में यह कहना मजेदार था कि calculator हटाने से ज़्यादा sales complete होंगी, इसलिए शायद user के लिए बेहतर हो। शायद सही विकल्प यह था कि user को उचित price shock लगे और वह चला जाए, लेकिन इसे ignore कर दिया गया
कल्पना कीजिए कि calculator का code project के बाकी हिस्से की तुलना में खराब है, पुरानी libraries इस्तेमाल करता है, update करने पर टूट जाता है, उसमें security vulnerabilities हो सकती हैं, resources असामान्य रूप से बहुत ज़्यादा खाता है, और build system बिगाड़ देता है। कोई भी उससे निपटना नहीं चाहता
ऐसी स्थिति में अगर पूछा जाए कि क्या यह अच्छा idea है, तो अधिकतर लोग “नहीं” कहेंगे और चाहेंगे कि उस mess को हटा दिया जाए। तब 70% बहुत अच्छा number है। इसके उलट अगर यह ऐसा feature है जिस पर लोग काम करना पसंद करते हैं, तो 70% वाकई खराब number बन जाता है
बेशक वे ऐसा सोचते भी हो सकते थे, लेकिन यह काफी बड़ा leap है। हो सकता है उन्हें लगा हो कि कोई खास फर्क नहीं पड़ेगा, या उन्होंने अनुमान लगाया हो कि calculator कभी-कभी गलत जवाब देता है इसलिए performance कम है
सामान्य message दिलचस्प है, लेकिन इस हिस्से पर थोड़ा ठिठकना पड़ता है
“थोड़ी-सी misunderstanding या गलत input से estimate 1000x तक बढ़ सकता है” — क्या इसका मतलब है कि actual use में भी metrics को थोड़ा misunderstand या गलत assess करने पर plan से 1000x cost चुकानी पड़ सकती है?
online billing systems में यह काफी realistic है। मैंने एक बार GCP prototype गलत configure कर दिया था; लगा था bill करीब 2–3 dollars होगा, लेकिन कुछ दिन ध्यान नहीं दिया तो 100 dollars से ज़्यादा का bill आ गया
slider को थोड़ा बदलने भर से expected price पागलों की तरह बढ़ता दिखे, तो customers का drop off करना समझ आता है। tool हटाने से signup में मदद मिलेगी, लेकिन बाद में ऐसे problem से जूझने वाले customers की मदद नहीं होगी
एक user ने सोचा कि queries per second को searches की संख्या × हर search का top-k करके calculate किया जाता है। top-k वह number है जितने results आप वापस पाना चाहते हैं। अगर top-k 10 मानें, तो QPS में actual से 10x ज़्यादा value डाली जाएगी और actual bill से करीब 10x ज़्यादा estimate दिखेगा
दूसरे user ने सोचा कि vectors की संख्या embeddings की संख्या × embedding dimensions की संख्या से निकाली जाती है। 1,536 एक common dimension count है, इसलिए input सचमुच 1,536x बढ़ गया। actual usage Pinecone सही तरह से calculate करता है, इसलिए इतना ज़्यादा bill नहीं आएगा
vector dimensions AI engineers के लिए basic concept है और QPS DB admins के लिए basic metric है, लेकिन Pinecone में कई users ऐसे हैं जो AI में नए हैं, या DB administration में नए हैं, या दोनों में नए हैं
लेखक को अपनी ही सलाह follow करनी चाहिए। article के बीच में घुस आने वाला “Psst... Get the next post in your inbox” हटाना चाहिए, और scroll करते समय साथ-साथ चलने वाला बेवकूफ button भी remove करना चाहिए
मैंने उस page पर subscribe करने के पांच तरीके गिने। क्या सचमुच पांचों की जरूरत है? क्या उन्हें content के बीच में, reader के चेहरे के सामने ठूंसना जरूरी है? क्या लोगों को interrupt करके और irritate करके subscribers बढ़ेंगे, ऐसा लगता है? क्या ऐसे subscribers चाहिए?
कुछ हटाना आम तौर पर साफ होता है। “और और और, पैसा कमाओ, customers खींचो” जैसी pitfall वाली सोच से बाहर निकलकर बस यह सोचना होता है कि “users का सम्मान करने के लिए सही क्या है, और उन्हें wallet निचोड़ने की चीज नहीं बल्कि इंसान मानते हुए हम कैसे मदद कर सकते हैं”
याद रखना चाहिए कि ज्यादातर businesses HN readers को pleasant experience देने के लिए नहीं, बल्कि पैसा कमाने के लिए मौजूद हैं
users का सम्मान करना क्या होता है, यह अलग सवाल है, हालांकि पूरी तरह unrelated भी नहीं
dedicated Slack channel बना, कंपनी भर की राय वाले 550 से ज़्यादा messages जमा हुए, और calculator को ठीक करने के लिए क्या और जोड़ा जाए इस पर meetings में दर्जनों घंटे और हजारों शब्द खर्च हुए — यह over-hiring का symptom है
जब लोग बहुत ज़्यादा हो जाते हैं, तो initiative गायब हो जाता है। अगर आप भूल जाते हैं कि सच में important क्या है और committee-style consensus बनाना जरूरी महसूस होता है, तो लोगों की संख्या बहुत ज़्यादा है
committee-style design भी committee के अंदर तक सीमित रहता है
क्या बेहतर नहीं होगा कि वही pricing structure हटा दिया जाए जो इतना complex है कि customers उसे usefully model ही नहीं कर सकते?
यानी जब option A x dollars का है और option B 10x dollars का, और ज्यादातर users गलती से सोचते हैं कि उन्हें B चाहिए, तो calculator misunderstanding पैदा करने वाला tool बन जाता है
मुझे “pricing पर बात करें” वाला model काफी पसंद है। जो users जल्दी से approximate price range जानना चाहते हैं, उनके लिए यह annoying है, लेकिन यह उन cases को identify करने में मदद करता है जहां standard pricing या online आसानी से explain न की जा सकने वाली pricing negotiate की जा सकती है। इससे वे situations भी पकड़ में आ सकती हैं जहां user बस आगे बढ़ जाता। बेशक, ज्यादातर e-commerce जैसे cases में यह सही नहीं है
हमारी कंपनी में करीब 250 products हैं, और उनमें से 5 products revenue के 80% के लिए जिम्मेदार हैं
उन 5 products की development teams bugs ठीक करने में भी मुश्किल से पीछे-पीछे चल पा रही हैं, और अहम नए features जोड़ने में संघर्ष कर रही हैं। चाहे request कोई भी करे, roadmap में कुछ डालना ही एक असंभव लड़ाई जैसा है
कंपनी में हजारों developers हैं, लेकिन उनमें से ज्यादातर ऐसे products पर लगे हैं जिनका revenue में योगदान लगभग न के बराबर है
आगे बढ़ने के लिए ज्यादातर products को काटकर, बची हुई मुख्य revenue products को आगे बढ़ाने के लिए teams को reorganize करना सही है—यह साफ दिखता है। लेकिन ऐसा नहीं हुआ, और ऐसा होने के कोई संकेत या अफवाह भी नहीं हैं। कंपनी की politics सच में बहुत कठोर है
ऐसा ही अनुभव रहा है। एक website पर कई products थे जो काफी मिलते-जुलते दिखते थे, और चिंता थी कि लोगों को यह तय करने में मुश्किल हो रही होगी कि क्या खरीदें, इसलिए शायद वे खरीद ही नहीं रहे होंगे
इसलिए हमने एक product recommendation applet बनाया, जिसमें user कुछ सवालों के जवाब देता था और फिर उसे सबसे उपयुक्त एक-दो products recommend किए जाते थे। इसे ठीक से बनाने में कुछ काम लगा, लेकिन पूरा होने के बाद यह अच्छी तरह काम करता था
इसे site पर डालते ही conversion rate तेजी से गिर गया। A/B test करने पर साफ हो गया कि इससे conversion rate को नुकसान हुआ। यह नुकसान क्यों हुआ, अभी भी नहीं पता, लेकिन हुआ जरूर। इसलिए हमने इसे homepage से FAQ section में शिफ्ट कर दिया, और फिर लगभग किसी ने इसे इस्तेमाल नहीं किया
हो सकता है लोग indecisive थे, और इसने उन्हें खुद इधर-उधर try करके समझने की मेहनत से बचा दिया
अगर यह कोई service थी, तो शायद Amazon Prime जैसी strategy काम कर जाती: भरोसा न हो फिर भी पहले sign up कर लो, और बाद में sunk cost fallacy का फायदा उठाओ। या applet न होता तो वे यह उम्मीद करके sign up कर लेते कि सबसे सस्ता version उनके लिए काफी होगा, लेकिन applet ने वह उम्मीद तुरंत तोड़ दी होगी
अगर यह physical product था, तो शायद इसने उन्हें खराब खरीदारी से बचाने में मदद की
मुझे उम्मीद नहीं है कि लोग इसे FAQ में ढूंढेंगे। Footer में हो तो शायद, लेकिन FAQ में नहीं
यह एक दिलचस्प case study है, लेकिन इसके व्यापक implications को लेकर मैं skeptical हूं। Pinecone दूसरे vector database services की तुलना में महंगा होने के लिए जाना जाता है। अगर horizontal price comparison करें, तो market में कई बेहतर विकल्प मौजूद हैं
calculator हटाने से core problem हल नहीं होती। यह बस cost को धुंधला बनाता है, और users के लिए शुरुआत से ही options compare करना मुश्किल कर देता है। मेरे नजरिए से, यह comparison step को कम करके, अधिक कम-जानकारी वाले users को price impact पूरी तरह समझे बिना data upload करने की ओर ले जा सकता है
simplification कभी-कभी valuable होती है, लेकिन इस मामले में यह users की तुलना में company के लिए ज्यादा फायदेमंद लगती है। calculator को पूरी तरह हटाने के बजाय उसकी accuracy और usability सुधारना बेहतर हो सकता था। खासकर ऐसे B2B services में, जहां cost तेजी से बढ़ सकती है, price transparency महत्वपूर्ण है