उत्पाद की रणनीति का अर्थ है उत्तर "नहीं!"

देस ट्रेयनोर द्वारा अनुवादित

यदि आप एक उत्पाद बना रहे हैं, तो आपको पूरी तरह से ना कहने में सक्षम होना चाहिए। नहीं "शायद" या "बाद में," अर्थात् नहीं। उत्पाद निर्माण के समय, आपको इसमें विकल्पों को शामिल करने की आवश्यकता नहीं है जो सैद्धांतिक रूप से उपयोगी हो सकते हैं, लेकिन अप्रत्यक्ष रूप से इससे संबंधित हैं, क्योंकि यह उत्पाद मापदंडों और इसके फोकस को सटीक रूप से निर्धारित करने में हस्तक्षेप करेगा।



जैसा कि नवीनतम Apple विज्ञापन से होता है, आपके उत्पाद के हजारों संस्करण हो सकते हैं जो विभिन्न विशेषताओं, महत्वपूर्ण और महत्वहीन के कारण दिखाई दे सकते हैं। इन संस्करणों में से अधिकांश बुरी तरह से विफल होते हैं और केवल सबसे अच्छा बाजार की सेवा कर सकता है।

हां कहने के लिए कई कारण

जब आप एक उत्पाद बनाने की प्रक्रिया में होते हैं, तो आप अच्छे विचारों के साथ जलमग्न हो जाएंगे। वे आपके ग्राहकों, सहकर्मियों और स्वयं से आएंगे। आपके पास उन्हें हां कहने के कई कारण होंगे, क्योंकि वे अच्छे हैं। यहां 12 डॉन लिंडसे -स्टाइल तर्क दिए गए हैं जो अक्सर अनावश्यक विशेषताओं को उत्पाद में लाने में मदद करते हैं।

लेकिन आंकड़े बहुत अच्छे लगते हैं

समय के साथ इंटरफेस में सुधार

"हमने परीक्षकों के एक छोटे समूह के साथ इस सुविधा का परीक्षण किया और सुधार चार्ट पर स्पष्ट रूप से दिखाई दे रहे हैं । " अक्सर यह दृष्टिकोण आंकड़ों के नमूना विश्लेषण से ग्रस्त होता है। एक उत्पाद एक जटिल प्रणाली है। भले ही आंकड़े अच्छे हों और डेटा स्थिर हो, फिर भी आपको यह सोचना चाहिए कि आपका उत्पाद क्या है, इसके लिए क्या है। अपने उत्पाद में टेट्रिस जोड़ें और आप सुधार भी देख सकते हैं, लेकिन क्या आपका उत्पाद बेहतर होगा?

लेकिन इसमें कुछ ही मिनट लगते हैं

एक छोटी सी सुविधा का परिकलित विकास समय
एक छोटी सी सुविधा का वास्तविक समय विकास

वास्तव में, रनिंग टाइम कभी भी किसी प्रोजेक्ट में कुछ भी जोड़ने का कारण नहीं होना चाहिए। हां, यह योजना में इसे जोड़ने के लायक हो सकता है, और बाद में इस पर विचार करें, लेकिन अब सब कुछ करने की कोशिश न करें।

एक उत्पाद में बहुत सारे बुरे विचारों को बहुत जल्दी मूर्त रूप दिया जा सकता है। ललचाओ मत। कोई छोटे बदलाव नहीं हैं। वैसे, एक छोटा सा परिवर्तन भी उत्पाद को जटिल कर सकता है, और इसका सरलीकरण इन " केवल 5 मिनट " में निवेश नहीं किया जाता है।

लेकिन यह ग्राहक छोड़ सकते हैं

यह ब्लैकमेल है। कोई भी ग्राहक एक अच्छे उत्पाद से अधिक महत्वपूर्ण नहीं हो सकता है। यह सड़क आपके ग्राहकों में से एक के लिए एक आदर्श उत्पाद बनाने की ओर ले जाएगी, क्योंकि आपने वही किया था जो उन्होंने कहा था। यदि आप एक ग्राहक को नजरअंदाज करते हैं, तो बाकी सभी को कम आंकें।

लेकिन हम इसे वैकल्पिक बना सकते हैं

इससे सेटिंग्स से मौत हो जाती है। वैकल्पिक विशेषताएं एप्लिकेशन की मुख्य स्क्रीन की जटिलता को छिपाती हैं, लेकिन यह जटिलता इसके अन्य सभी स्थानों में रेंगना शुरू कर देती है। इस की स्पष्ट कीमत सशर्त डिजाइन और सेटिंग्स के टन का एक पूरा गुच्छा के साथ एक घृणित इंटरफ़ेस है। छिपी हुई कीमत आपके उत्पाद के संकीर्ण फोकस के नुकसान में व्यक्त की जाती है। आपका उत्पाद "एक आयोजक है जो आपको चालान भेजने और भुगतान समन्वय करने में सक्षम लगता है, लेकिन यह वर्तमान घटनाओं की रिपोर्टिंग नहीं करता है, मुझे नहीं पता, मुझे यकीन नहीं है ।"

लेकिन मेरे चचेरे भाई के पड़ोसी ने कहा ...

यह एक मजाक की तरह लग रहा है। यह सास कंपनियों में आम है जो यह नहीं समझ सकती हैं कि वे किस तरह का काम कर रही हैं। एक छोटे नमूने को बाहर निकालना परीक्षण, अनुसंधान, सांख्यिकी और व्यवहार के वर्षों का सही तरीका है। यह कहते हुए कि "मेरे भाई की कंपनी Google Analytics का उपयोग करती है और इसमें उन्नत सेगमेंट का उपयोग करती है" उन्नत सेगमेंट के उपयोग को जन्म दे सकती है, प्रश्नों को दरकिनार करते हुए: यह क्या है? आपका उत्पाद क्या करता है? क्या यह भाई की कंपनी ग्राहकों को चुनने में अच्छा है? क्या वे वास्तव में इसका इस्तेमाल करते हैं या ऐसा कहते हैं? क्या यह तकनीक आपके लिए सही है?

लेकिन हमारे लिए कुछ भी योजनाबद्ध नहीं है।

बेपर्दा हाथ काम की तलाश में हैं। कई, आलसी डेवलपर्स को नई सुविधाओं के साथ आते हुए देखकर, अगर केवल उन्होंने काम किया। विचारों की स्वीकृति में तेजी है - आलस्य से बचने के लिए। यह आपके उत्पाद को बेहतर बनाने का सबसे अच्छा तरीका नहीं है।

थोड़ा अतिरिक्त समय मिलने के बजाय, डेवलपर्स इसे खो देते हैं। हर कोई जो डेवलपर्स के रूप में काम करता है, जानता है: "यदि आपके पास आलस्य के लिए समय है, तो आपके पास कोड की सफाई के लिए समय है।" खाली समय संपादन कीड़े, सफाई मामलों की जांच, रीफैक्टरिंग के लिए आदर्श है। आपको सिर्फ टीम को काम पर नहीं रखना चाहिए।

लेकिन मुझे लगा कि हम जो चाहते हैं, उस पर काम करेंगे

यह तर्क एक क्लासिक बन गया है। कई बड़ी कंपनियां डेवलपर्स से वादा करती हैं कि वे उस पर काम करेंगे जो वे चाहते हैं और इसे बेचेंगे। दो इंटरचेंज हैं:

1. यह डेवलपर्स को आकर्षित करने के लिए कहा गया झूठ है। यह बहुत जल्दी स्पष्ट हो जाता है और विफल हो जाता है।
2. यह सच है, और इसका अंतिम परिणाम एक पूरी तरह से महसूस किया जाने वाला उत्पाद है जिसकी किसी को भी ज़रूरत नहीं है और आधे-अधूरे विचार हैं।

सामान्य तरीके (अच्छे) में चीजों पर काम करने के लिए एक डेवलपर की पेशकश और एक उत्पाद (खराब) में अनियोजित सुविधाओं को शामिल करने की पेशकश के बीच अंतर होता है।

लेकिन 713 हजार लोग यही चाहते हैं

उन परिस्थितियों से बचने की कोशिश करें जहां कोई कच्ची संख्या में बहाने बनाने की कोशिश कर रहा है। कोई भी, यहां तक ​​कि थोड़ा विकसित उत्पाद भी इसके उपभोक्ताओं की संख्या का पता लगाएगा। उदाहरण के लिए: "हम डोलोरेस पार्क को उन लोगों से भर सकते हैं जिन्होंने एक्सेल के साथ एकीकरण के लिए कहा था।" यह आपको प्रारंभिक पाठ्यक्रम को बंद कर देता है और भीड़ के प्रभाव के कारण "उनमें से एक" बन जाता है। क्या तुम सच में इतना क्रूर कह सकते हो न?

और आपको चाहिए। अन्यथा, आपके अधिकांश ग्राहक पीड़ित हो सकते हैं। सवाल यह नहीं है कि "क्या हम डोलोरेस पार्क को ऐसे लोगों से भर सकते हैं जिन्हें इस सुविधा की आवश्यकता है", लेकिन "क्या यह हमारे ध्यान के उत्पाद में मूल्यवान है, क्या ग्राहक इसका उपयोग करेंगे?"

लेकिन हमारे प्रतियोगियों के पास है

इसका मतलब यह नहीं है कि यह एक अच्छा विचार है। यह हो सकता है कि वे बस नई तकनीक का परीक्षण कर रहे हैं। यह विचार इतना शानदार नहीं हो सकता है। हो सकता है कि वे पहले ही इसे एप्लिकेशन से हटाने की योजना बना रहे हों। यह मानना ​​गलत है कि आपके प्रतियोगी आपसे अधिक स्मार्ट और अधिक कुशल हैं। प्रतियोगियों के विचारों के साथ जुनून आपको नीचे रख सकता है ताकि आप केवल कल की तकनीक को कल दिखा रहे हों।

लेकिन अगर हम ऐसा नहीं करेंगे, तो कोई और करेगा।

इसका मतलब यह नहीं है कि यह आपके उत्पाद में होना चाहिए। यदि कोई और ऐसा करता है, तो क्या ग्राहक आपके उत्पाद को छोड़ देंगे? क्या वे पार करेंगे? सिर्फ यह कहना कि "कोई और करेगा" अच्छा है, लेकिन इसका कोई मतलब नहीं है। मैंने देखा कि मैं यह बहुत बार कहता हूं। इस तर्क का उपयोग उत्पाद का विस्तार करने के लिए किया जाता है, क्योंकि आप वहां एक सेकंड के लिए भी रुकना नहीं चाहते हैं। आप अपने प्रोजेक्ट की फिनिश लाइन तक पहुंचने से डरते हैं।

यहाँ एक उदाहरण है: एक विशिष्ट तिथि में एक फिल्म, रात का खाना और एक यात्रा घर शामिल है। यदि सिनेमा का मालिक लगातार इस बात को लेकर चिंतित रहता है कि अन्य व्यवसायी क्या करेंगे और अधिक लाभ प्राप्त करना चाहेंगे, तो वह अपने सिनेमा में रेस्तरां डालेंगे और लोगों को एक ला टैक्सी से लोगों को घर पहुंचाने की कंपनी बनाएंगे। और ये तीनों सेवाएं घृणित होंगी। और फिर रेस्त्रां फिल्में दिखाना शुरू कर देंगे ...

लेकिन बॉस ऐसा चाहता है

तो यकीन है, जल्दी से पाई चार्ट बनाने के लिए। उनमें से टन।

यदि बॉस एक उत्पाद प्रबंधक भी है और उसके पास स्मार्ट, समग्र निर्णय लेने का समय है, तो सब कुछ क्रम में है। लेकिन अगर कोई केवल दूसरों की नजरों में अंक अर्जित करने की कोशिश कर रहा है, तो इससे परेशानी होगी।

लेकिन वही होगा जो हमारे उत्पाद को बदल देगा

किसी उत्पाद को बदलने से आपको अच्छी तरह से लगता है कि क्या करने लायक है। आप सभी को किसी भी बदलाव के बारे में बता सकते हैं और कह सकते हैं कि यह निश्चित रूप से उत्पाद को बदल देगा, लेकिन ये सिर्फ परीकथाएं हैं। जब आप गंभीर निर्णय लेने से डरते हैं, तो आप विश्वास करना शुरू करते हैं कि "यहाँ, यह वह है, यह बहुत बात है।" आप विचारों के एक सेट और उनके कार्यान्वयन के भंडार के साथ समाप्त होंगे, लेकिन एक तैयार उत्पाद के साथ नहीं।

"नहीं" इतना महत्वपूर्ण क्यों है?

तथ्य यह है कि कोई भी विफलता की योजना नहीं बनाता है। इसकी परिभाषा और उसका काट देना काफी सरल है। लेकिन किसी गंभीर उत्पाद पर काम करते समय किए गए निर्णय इतने सरल नहीं होते हैं। वे आपको फीचर और उसके कार्यान्वयन का पूरा विवरण पढ़ने के लिए मजबूर करते हैं और कहते हैं: "यह वास्तव में एक अच्छा विचार है, मैं समझता हूं कि हमारे ग्राहक इसे क्यों पसंद करेंगे। बहुत अच्छा काम। लेकिन हम इसे उत्पाद से नहीं जोड़ेंगे ... यही हम इसके बजाय करेंगे। "

अनुवादक से: लेख आपको स्पष्ट उदाहरणों और फ़ेकैप्स को उजागर करने में सक्षम होने के लिए कई कारण बता सकता है। संक्षेप में - एक तरफ या दूसरे से उकसावे से कैसे बचें। उसी समय, लेखक ने मुख्य बात नहीं कही - जो हमें पोषित "हां" कहने की अनुमति देता है। दो बिंदु: सबसे पहले, मैं इस लेख को पढ़ने की सलाह देता हूं; दूसरी बात, मेरी स्थिति यह है: आपको पूरी तरह से उत्पाद रणनीति के साथ प्रस्तावित सुविधा को सहसंबंधित करने की आवश्यकता है। यदि विशेषता रणनीतिक लक्ष्य को प्राप्त करने में मदद नहीं करती है - ठंड में। अन्यथा, यह शुद्ध "फिशरवाद।" हम नहीं जानते हैं कि हमारे उपयोगकर्ता कौन हैं और उन्हें क्या चाहिए, इसलिए हम सब कुछ सिर्फ मामले में ही करेंगे - सभी अवसरों के लिए एक सार्वभौमिक हार्वेस्टर। यह एक मृत अंत है। मुझे आशा है कि निकट भविष्य में मुझे यैंडेक्स उत्पाद प्रबंधक के रूप में अपने अनुभव को संक्षेप में प्रस्तुत करने और इस विषय पर एक विस्तृत लेख लिखने का समय मिलेगा।

अनुवाद टॉल्स्टॉय समर कैंप और मेटाबेता स्टार्टअप स्कूल के हिस्से के रूप में किया गया था।