बिल्डिंग, और बहुत कुछ

पिछले दो वर्षों में, 31,832 लोगों ने Whatnot में प्रोडक्ट मैनेजर पद के लिए आवेदन किया। हमने एक को काम पर रखा। आपके लिए होल-इन-वन मारने की संभावना उतनी ही है जितनी कि केवल आवेदन करके नौकरी पाने की संभावना दोगुनी है।

यह प्रक्रिया की विफलता नहीं है। मैं एक दशक से अधिक समय से उत्पाद – और उत्पाद टीमें – बना रहा हूँ और लगभग 3 साल पहले Whatnot में आने का निर्णय लेने का सबसे बड़ा कारण यहाँ की बहुत ही सोचीमित उत्पाद संस्कृति थी। कोई नहीं जानता कि AI की दुनिया में PM होने का क्या मतलब है, लेकिन मैं जो कुछ भी देख रहा हूँ वह बताता है कि उद्योग हमारी ओर और हम यहाँ कैसे निर्माण करते हैं, उस ओर बढ़ रहा है - क्योंकि कोई भी कोई भी उपकरण आपको उपयोगी नहीं बनाएगा यदि आप सही काम नहीं कर रहे हैं।

पहले हमें स्वीकारना होगा: औसत PM गहराई से औसत होता है।

उत्पाद कार्य पैमाने के जवाब में उभरा – इंजीनियरिंग टीमें CEO या GM के लिए सीधे प्रबंधन करने के लिए बहुत बड़ी हो गईं, इसलिए एक व्यवसाय <> तकनीकी माध्यम की आवश्यकता थी। समय के साथ साथ हमने आलसी होकर इस भूमिका को सामान्यीकृत कर दिया "जब भी आप एक इंजीनियरिंग मैनेजर को काम पर रखते हैं, आप एक PM को काम पर रखें"। लेकिन जहाँ एक Eng Director अपने Ector अपने EMs के माध्यम से 30-40 लोगों का प्रबंधन करता था, वहीं एक PM निदेशक केवल पाँच लोगों का प्रबंधन करता था। प्रोत्साहन दुनिया को नियंत्रित करते हैं, इसलिए उन निदेशकों का काम बन गया "अपने इंजीनियरिंग भागीदारों के हेडकाउंट को बढ़ाने का औचित्य सिद्ध करना" ताकि वे बदले में VP बनने के लिए अपना हेडकाउंट बढ़ा सकें। धीरे-धीरे जूनियर PMs की भूमिका "उत्पाद के CEO" से "बटन के बेबीसिटर्स" में बदल गई और उत्पाद-दिमाग वाले इंजीनियर बचकाने ऑर्डर लेने वाले बन गए।

फिर COVID आया और उद्योग ने केवल चार वर्षों वर्षों में 500,000 नए सॉफ्टवेयर इंजीनियरों को काम पर रखा, बल्कि उनके साथ ~80,000 नए PM भी बनाए गए। वे 80,000 PM FAANG में विशाल टीमों के भीतर दबे हुए हैं, किसी भी ग्राहक से दूर, उस ज़ूम से 50 परतें दूर जहाँ यह होता है, उत्पाद स्कूल में पेंट-बाय-नंबर PM करना सिखाया गया, अर्जित जुड़ाव वृद्धि के युग में जहाँ लगभग कुछ भी काम करता था।

इसमें से महान उत्पाद प्रवृत्ति, अनुभव और दृढ़ता वाले किसी व्यक्ति के उभरने की संभावना वास्तव में होल-इन-वन मारने से भी कम लगती है।

दूसरा: हमने अपने सबसे अच्छे को और भी बुरा बना दिया।

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

लेकिन असली सच्चाई आपके सिस्टम के डेटा मॉडल में, सेल्स कॉल्स में, CX टिकट्स में, एनालिटिक्स में है – न कि उस सुंदर 2x2 में जो सब कुछ सरल बनाने के लिए बनाया गया है।

वा।

आप प्रबंय प्रबंधन खेलने में जितना समय बिताते हैं, उसका मतलब है कि समस्याओं की आपकी सहज समझ पुरानी होती जा रही है, आपके ग्राहक के लिए आपकी प्रवृत्ति कुंद होती जा रही है, आपके सही होने की संभावना घट रही है।

एक कार्य के रूप में हमारा बल्लिंग औसत दोनों कारणों से गिरा क्योंकि हर बढ़ गया और क्योंकि इसके विस्तार का मतलब था कि सात साल पह पहले जो लोग उत्पाद में अच्छे थे, वे सभी कोई वास्तविक काम करने से पदोन्नत हो गए (या इतने अमीर हो गए कि रहने और राजनीति खेलने का प्रोत्साहन कम था)।

The Whatnot Way

अपनी शुरुआत से ही, Whatnot उत्पाद टीम एक काफी सरल आधार पर बनाई गई है: हमें खेद है कि उत्पाद प्रबंधन मौजूद है। सेल्स और इंजीनियरिंग हमारे काम पर रखे जाने से पहले ठीक से काम कर रहे थे, इसलिए जहाँ जहाँ वे कर सकते हैं, उन्हें बिना प्रक्रियात्मक गेटकीपिंग या बकवास कागजी कार्रवाई के शिप करना चाहिए। उत्पाद एक व्यापार है, योग्यता नहीं। जो कोई भी इसे अच्छी तरह से करता है उसने करके और महान लोगों के साथ काम करके सीखा है।

हाल ही में एक साक्षात्कार में किसी ने मुझे बताया कि Whatnot ऐसा लगता है जैसे Twitch और eBay का बच्चा हो - सांस्कृतिक रूप से यह इससे अधिक गलत नहीं हो सकता, लेकिन उत्पाद के दायरे के संदर्भ में यह एक अच्छी तुलना है। एक रूढ़िवादी अनुमान कहता है कि उन दोनों संगों संगठनों में मिलाकर >400 PM हैं। हमारे पास 20 हैं। 1200+ कुल कर्मचारियों के लिए 20 PM।

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

कई।

कई स्टैक्स में काम करना और विभिन्न ग्राहकों पर प्रभावों का वजन करना आसान नहीं है – इसके लिए व्यवसाय का व्यापक संदर्भ, किसी भी सुविधा में बदलावों के डाउ डाउनस्ट्रीम प्रभावों का पूर्वानुमान लगाने की क्षमता, संदर्भ स्विचिंग में कौशल, एक भागीदार के बजाय पूरे संगठन में विश्वास बनाने और खर्च करने की क्षमता की आवश्यकता होती है। यही कारण है कि हम लगभग विशेष रूप से वरिष्ठ PMs को काम पर रखते हैं। वे PM जो अंतहीन संरेखण बैठकों से ऊब चुके हैं और फिर से निर्माण करने के लिए उत्सुक हैं। या, हम होनहार सेल्स या ऑप्स लोगों को परिवर्तित करते हैं और उन्हें करके सीखने देते हैं। हम हमेशा करियर के बीच में L5/L6 होल-इन-वन हायर की तलाश में रहते हैं, लेकिन आँकड़े इस बारे में झूठ नहीं बोलते कि हम उन्हें कितनी बार पाते हैं।

अंत में, हर कोई शिप करता है, मुझे भी शामिल करते हुए। मैं हमेशा एक IC के रूप में सुविधाओं को शिप करने के लिए इंजीनियरों और डिजाइनरों की एक टीम के साथ सीधे काम कर रहा हूँ, और हमारे दोनों सह-संस्थापक भी ऐसा करते हैं। जब यह परीक्षण करने का समय था कि क्या PMs के लिए छोटी सुविधाओं को वाइबकोड करना संभव है, तो मैं गिनीपिग था। जब ऑस्ट्रेलिया में हमारे पहले विक्रेता को ऑनबोर्ड करने का समय था, तो यह हमारे सह-संस्थापक लोगान कर रहे थे। जब Zendesk ने ग्राहक टिकट गिराना शुरू किया, तो यह हमारे CEO ग्रांट थे जो उनके सपोर्ट इंजीनियर से बात कर रहे थे।

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

तकनीकी कर्मचारियों के सदस्य

अभी "निर्माण" के बारे में बहुत शोर है... नहीं, उत्पाद आवश्यकता दस्तावेज़ मरे नहीं हैं। एक PRD केवल एक समस्या के बारे में स्पष्ट रूप से सोचने और उसे दूसरों तक पहुँचाने का एक बर्तन है। यदि आप चाहें तो अपने को इंटरैक्टिव बनाएं, किसी को कोई फर्क नहीं पड़ता। नहीं, एक बुरे उत्पाद को शिप करने की लागत शून्य शून्य नहीं हुई है, यह अभी भी आपके ग्राहकों द्वारा चुकाई जाती है। उन पर 16x तेजी से स्पेगेटी फेंकना वास्तव में एक क्रांति नहीं है, यह केवल्फ परेशान करने वाला है। और नहीं, हर कोई एक साथ S-स्तर के Eng और Designer और PM नहीं बनने वाले। कुछ लोग होंगे, लेकिन विशेषज्ञता के वही चालक – जो लोग पसंद करते हैं और जिसमें अच्छे हैं – अभी भी निर्धारित करेंगे कि हम कैसे काम करते हैं।

जो बदल रहा है वह यह अहसास है कि IC होना कई लोगों के कौशल, अनुभव और इस धरती पर सीमित समय का उपयोग करने का एक बेहतर तरीका है, बजाय उसी दस्तावेज़ को 5वीं बार फिर से लिखने के ताकि वर्तमान पांडों के पसंदीदा फॉर्मेटिंग में फिट हो सके। Whatnot में कुछ PM प्रबंधक हैं, लेकिन उनमें से प्रत्येक अपना 90%+ समय एक IC के रूप में बिताता है। हमारे शीर्षक या मुआवजे में उन लोगों के लिए कोई अंतर नहीं है जो प्रबंधन करते हैं या नहीं क्योंकि हम इसमें कोई निहित गुण नहीं देखते हैं। AI हमें अविश्वसनीय लाभ देता है – मैं विकास प्रक्रिया में लगभग हर कार्य में तेजी से आगे बढ़ सकता हूँ, चाहे वह डेटा को समझना हो जिसके लिए पहले एक डेटा वैज्ञानिक की आवश्यकता होती थी, या एक PRD को CX SOPs के हर रूपांतरांतर में बदलना हो जो सामान्यतः लॉन्च सप्ताह में कार्यालय में लंबी रातों का विषय होता था। मैं सेल्स से सप्ताह में 100 प्रश्नों को छांटने के लिए एक बॉट बना सकता हूँ या हाल के एक प्रयोग में छोड़े गए स्थानीयकरण अंतराल को खोजने के लिए।

PMs के लिए AI के बारे में सबसे विघटनकारी बात यह है कि इसने दिखाया है कि लोगों को कोचिंग देना और उनके माध्यम से काम करने का लाभ अब वह एकमात्र स्रोत नहीं रह गया है जो कभी था। खासकर यदि वे लोग – अपनी गलती के बिना – गहराई से औसत हैं। लेकिन वह लाभ केवल उन लोगों के लिए उपलब्ध है जो अभी भी काम करना जानते हैं।

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

दिखाओ, बताओ मत

नीचे मैं (पी (पूरी तरह से) वह एक दस्तावेज़ कॉपी कर रहा हूँ जो हमारे पास है कि हम Whatnot में उत्पाद पर कैसे काम करते हैं। यदि हम एक बार भी मिले हैं, तो हैं तो आपको मुझे यह बताने की आवश्यकता नहीं होगी कि लेखक कौन है – हम इसी तरह बात करते हैं और इसी तरह काम करते हैं।

आप यह भी देख सकते हैं कि हमारी टीम में कौन काम करता है – आज टीम में कम से कम छह लोग हैं जो एक सीरीज B-C स्टार्टअप में CPO हो सकते हैं जो अपनी शाम विक्रेताओं के साथ फोन पर, एक Hex Thread में 400 क्वेरी गहरे, या कल के लॉन्च के लिए v1 संचार का मसौदा तैयार करने में बिताएंगे। ये चार पूर्व संस्थापक हैं जिन्होंने अपने जीवन में कभी भी इस बात से सहमति नहीं जताई कि कुछ उनके दायरे से बाहर है। ये चार पूर्व FAANG निदेशक हैं जो अब अपने दिन नौ बॉक्स ग्रिड में यह बहस करने में नहीं बिताते कि लोगों को कहाँ रहना चाहिए। ये छह शुरुआती चरण के PM हैं जिनके पास अविश्वसनीय स्वाद है, जिन्हें बताया जा रहा है कि उन्हें और अधिक चीजें आजमाने की जरूरत है क्योंकि हम केवल करके सीखते हैं।

मुझे संदे संदेह है कि अधिकि अधिकतम 20 PMs की हमारी पूर्व घोषणा टिकेगी – हमारे सामने Whatnot में अवसर इतना विशाल है कि हम खुद को मनमाने ढंग से सीमित नहीं करेंगे - लेकिन हम जिन्हें काम पर रखते हैं, उनके लिए बार केवल ऊपर जाएगा क्योंकि उद्योग और AI उपकरण महान ICs को लाभ के साथ पुरस्कृत करते रहेंगे। यदि आप उन लोगों में से एक हैं, और मैंने ऊपर जो वर्णन किया है वह आपको उत्साहित करता है, तो आप मुझसे संपर्क करने का तरीका निकाल लेंगे।

Whatnot में निर्माण

महान उत्पाद बनाना कठिन है। यह सिर्फ इतना नहीं है कि आपके पास समस्या के बारे में सही अंतर्ष्टि हो, विवरण सही हों, इसे सही तरीके से बाजार में ले जाएं, इसके प्रदर्शन को समझने के लिए इसे सही ढंग से मापें या इस पर जल्दी से पुनरावृत्ति करें। यह है कि आपको वे सब काम करने हों या यह काम नहीं करता। इससे भी बुरा, असफल होना महंगा है। हमारे पास कुछ टीमें हैं और हमारे सामने अवसर का एक विशाल परिमाण है - .300 बल्लेबाजी करना महान है यदि आप MLB में खेलते हैं, लेकिन हमारी आकांक्षाओं को साकार करने के लिए हमें .500 के करीब चाहिए। उच्च औसत के बिना हम या तो अल्पावधि में वृद्धि को सीमित करते हैं या हम व्यवसाय वृद्धि को हेडकाउंट वृद्धि से जोड़ते हैं और दीर्घावधि में खुद को सीमित करते हैं।

इस दस्तावेज़ के 2 भाग हैं:

1. हमारा दर्शन - यह नहीं बदलेगा
2. हमारी प्रक्रियाएँ - ये विकसित होंगी और वर्तमान SOT यहाँ रखा गया है

हम कैसे निर्माण करते हैं हमें लाभ देता है

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

यहाँ एक सफल उत्पाद का सुखद मार्ग लगातार 7 कदम चलता है:

1) यह कुछ ऐसा है जो उपयोगकर्ताओं और हमारे व्यवसाय के लिए मायने रखता है

सबसे प्रभावशाली चीजों को बेरहमी से प्राथ प्राथमिकता दें जो हमारे उपयोगकर्ताओं और व्यवसाय की जरूरतों को हल करती हैं।

• आपको उस मूल्य को स्पष्ट रूप से व्यक्त करने में सक्षम होना चाहिए "स्केल किए गए खुदरा विक्रेताओं को एक ही शो में कई स्थानों पर संग्रहीत उत्पादों को बेचने में सक्षम बनाएं - 'शिप्स फ्रॉम' को एक शो फील्ड के बजाय एक उत्पाद फील्ड बनाकर"
• सिस्टम के बारे में सोचें।

1. क्या यह उत्पाद लॉन्च होने पर तुरंत मूल्यवान है?
2. क्या यह अन्य चीजों के लिए एक 'बिल्डिंग ब्लॉक' है?

यदि (1) सत्य नहीं है, तो आगे न बढ़ें। यदि (1) सत्य है, तो यह काम करें कि यह समय के साथ (2) कैसे बन सकता है।

2) यहै) यह कुछ ऐसा है जो लोग चाहते हैं

उनके दर्द बिंदुओं, इच्छाओं और व्यवहारों को समझें ताकि उनके लिए एक उत्पाद बनाया जा सके।

• आप यह नहीं जानते जब तक कि आप उस उपयोगकर्ता को विस्तार से नहीं समझते जिसके लिए आप निर्माण कर रहे हैं। गुणात्मक और मात्रात्मक को एक साथ मिलाएं।
• अपने उत्पाद के बारे में मौजूदा उत्पाद कार्यप्रवाह के संदर्भ में सोचें।
• बकवास पर परत न डालें।
• किसी कार्यप्रवाह को न उड़ाएं जो समस्या B को हल करता है क्योंकि आप समस्या A पर ध्यान केंद्रित कर रहे हैं
• यदि समस्या वास्तविक है - क्या आप जानते हैं कि वे आज इसके आसपास कैसे काम कर रहे हैं?
• चमकदार वस्तुओं से सावधान रहें। खासकर चमकदार वस्तुएं जो आपने अतीत में कहीं और बनाई हैं।

3) ग्राहक की जरूरतें हमारे संगठन चार्ट के साथ संरेखित नहीं होती हैं / कभी भी एक सुविधा से पूरी नहीं होती हैं।

यदि आप स्थानीय रूप से निर्माण कर रहे हैं तो आप भोलेपन से निर्माण कर रहे हैं।

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

4) यह सबसे सरल संभव समाधान है जो समस्या को हल करता है।

तेजी से और विश्वसनीय उत्पाद बनाने की कुंजी जो उपयोगकर्ताओं को पसंद आए, अनावश्यक और गैर-प्रभावशाली काम से बचना है

• सरल न केव न केवल बनाने में तेज है, बल्कि आमतौर पर सबसे सफल भी होता है।
• सिस्टम के बारे में सोचने का मतलब पूरे सिस्टम को अग्रिम रूप से बनाना नहीं है।
• आप जितना अधिक यह जानने से पहले बनाते हैं कि आप सही हैं, जब आप गलत होते हैं तो उतना ही महंगा होता है।

5) इसे सबसे छोटे संभव दर्शकों के साथ मान्य किया गया था।

जब तक कोई इसका उपयोग नहीं कर रहा है, तब तक आप केवल अनुमान लगा रहे हैं।

• कागज या क्लिक करने योग्य प्रोटोटाइप जल्द से जल्द विक्रेताओं के हाथों में दें। स्टाफ डॉगफूडिंग बग कोडिंग बग को पकड़ने में समाधान को मान्य करने से बेहतर है क्योंकि हम अपने ग्राहक नहीं हैं।
• अपने GTM मोशन के बारे में सोचें
• विक्रेता-सामना करने वाले उत्पाद: <10 विक्रेताओं से शुरू करें, GA पर जाने से पहले या तो विक्रेताओं की संख्या से या कुछ श्रेणियों में स्केल करें।
• खरीदार-सामना करने वाले उत्पाद: या तो एक श्रेणी या एक छोटे % से शुरू करें और सिग्नल के साथ रैंप करें।
• पारिस्थितिकी तंत्र उत्पाद (दोनों को दिखाई देने वाले): या तो एक श्रेणी या एक छोटे बाजार से शुरू करें
• यदि आप मान्यता मोड में हैं, तो जागरूकता (आंतरिक या बाहरी) के लिए हल करना एक विफलता मोड है।
• यह इतना उप-पैमाने पर है कि यह वास्तव में लोगों को प्रभावित नहीं करता
• आप नहीं जानते कि यह अभी तक काम करेगा या नहीं - लोगों का समय बर्बाद न करें

6) एक बार मान्य होने पर हम इस पर पागलों की तरह पुनरावृत्ति करते हैं।

एक बार ग्राहकों के लिए लाइव होने पर, हम साप्ताहिक यदि दैनिक सुधार नहीं शिप कर रहे हैं।

• यदि आप सुनते हैं "एक बार जब हम X शिप कर देते हैं तो हम Y पर जा सकते हैं" तो यह एक बड़ा लाल झंडा है।
• एक बार जब हम जानते हैं कि यह एक चीज़ होने वाली है तो आपको वापस जाकर Catex और CX के लिए हल करना होगा
• लॉन्च करें, मान्य करें, मापें, पुनरावृत्ति करें, पुनरावृत्ति करें, पुनरावृत्ति करें > फिर अगली प्राथमिकता पर जाएं।

7) एक बार बीटा में एक बार हम दीवारों से गुजरते हैं

एक चिंगारी पाना कठिन है। एक बार जब आपके पास एक होती है तो आपको उस पर ईंधन डालना होगा या वह मर जाएगी।

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

8) यह बैचलर नहीं है - सब कुछ अलग करें

एक सिस्टम को डिजाइन करते समय एक स्वाभाविक प्रवृत्ति होती है कि इसके कई हिस्सों को एक साथ शिप करने की। हमारे जैसे पर्याप्त जटिल सिस्टम में, संभावना है कि कई टीमें एक सिस्टम के घटकों पर समानांतर में काम कर रही हैं और उन्हें एक साथ शिप करना समझदारी लग सकता है ताकि यह दो के बजाय एक बड़ा बदलाव हो। यह एक जाल भी है।

• जब तक प्रत्येक टुकड़ा स्वतंत्र रूप से व्यवहार्य और ग्राहकों के लिए लाभदायक है, उन्हें जल्द से जल्द लॉन्च करें
• यह हमें प्रत्येक को अधिक प्रभावी ढंग से मापने और उनके सापेक्ष योगदान को समझने देता है
• लाभदायक उत्पादों को दूसरे के लिए स्टेजिंग में प्रतीक्षा करना छोड़ना ग्राहकों के लिए बुरा है

समीक्षाओं और प्रतिक्रिया की भूमिका

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

1. एक जटिल सिस्टम में आपको वास्तव में सही उत्तर तक पहुंचने के लिए आपकी सोच से कहीं अधिक संरेख की आवश्यकता होती है। क्योंकि उस शब्द की गलत व्याख्या की जा सकती है:
2. संरेखण का कभी मतलब सहमति नहीं होता। सहमति अच्छे निर्णय लेने की दुश्मन है।
3. संरेखण का मतलब कार्यप्रवाह को जोड़ना नहीं है। समन्वय गति का दुश्मन है।
4. संरेखण का लिटमस टेस्ट - एक लिखित योजना। यदि Grant एक मांग रहा है, तो हम संरेखित नहीं हैं।
5. Whatnot में स्वायत्तता कार्यान्वयन की स्वायत्तता है। किसी के पास रणनीति की स्वायत्तता नहीं है या उसकी उम्मीद नहीं करनी चाहिए। संरेखण के बिना स्वायत्तता बर्बाद हो जाती है।

Whatnot में अपेक्षाओं को पूरा करने के लिए एक PM या Designer

1. उन चीजों की पहचान करता है जिन्हें तुरंत संरेखण की आवश्यकता है और सक्रिय रूप से उसकी तलाश करता है
2. संरेखण से कार्यान्वयन की ओर तेजी से बढ़ता है क्योंक्योंकि वे चर्चा और संरेखण को गहराई से समझते हैं। वे चर्चाओं में 'हाँ' सुनने के लिए नहीं सुनते।
3. अपनी टीम के साथ कार्यान्वयन विवरण भर सकता है / उन निर्णयों को जल्दी से अनब्लॉक कर सकता है जो संरेखण का पालन करते हैं।

गति क्यों मायने रखती है

हमारा पूरा सिस्टम सही चीज़ को शिप करने की गति को अधिकतम करने पर आधारित है। सुखद मार्ग के 1-3 यह पता लगाने के बारे में हैं कि हमें क्या सही लगता है, 4-7 इस बारे में हैं कि हम उस चीज़ को कैसे मान्य करते हैं, पुनरावृत्ति करते हैं और स्केल करते हैं। हम ऐसा इसलिए करते हैं क्योंकि:

1) हमारे सिस्टम में सब कुछ चक्रवृद्धि होता है - अच्छा और बुरा दोनों

2025 में हमने लगभग 250 व्यावसायिक दिनों में 750 प्रयोग चलाए, जो लगभग 3 शिप/शिप न करने के निर्णय प्रति दिन है। यदि आप उनमें से प्रत्येक निर्णय को केवल 3 कैलेंडर दिन तेजी से लेने के दीर्घकालिक प्रभाव का अनुकरण करते हैं, तो 2 वर्ष के क्षितिज पर प्रभाव Whatnot विक्रेताओं के लिए >$1.1B की वृद्धिशील कमाई है। उन उत्पादों का प्रभाव नहीं, बल्कि उन निर्णयों को आंशिक रूप से तेजी से लेने का प्रभाव। सही चीज़ को शिप करने में हर देरी हमारे ग्राहकों को नुकसान पहुँचाती है, और हम जितने बड़े होते जाते हैं, गति का अवसर/लागत उतना ही अधिक होता है।

2) एक बार गति खो जाने पर वह कभी वापस नहीं आती

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

3) गति गलतियों/त्रुटियों का कारण नहीं है

समितियाँ केवल प्रगति को रोकने के उपोत्पाद के रूप में गलतियों को रोकती हैं। निर्णय ही वास्तव में गलतियों को रोकता है। अधिक बार शिप करने से हम हमारे निर्णय का निर्माण करता है - एक एथलीट की तरह हम रेप्स के माध्यमजबूत होते हैं। रेप्स बनाते समय, टीमें अधिक रेप्स और अधिक संदर्भ वाले लोगों के निर्णय का लाभ उठा सकती हैं - उत्पाद नेतृत्व से निरंतर तदर्थ मार्गदर्शन, योजना के शुरुआती चरणों में कानूनी और संचार जैसे प्रमुख जोखिम शमन के लिए दृश्यता (यदि अटलांटिक में तूफान हैं जिनसे हमें बचने की आवश्यकता है, तो हमें यह जानने की आवश्यकता है जब हम पाठ्यक्रम बना रहे हैं, न कि जब हम रवाना हो रहे हैं), श्रेणी या देश के लीड जो अनुमान लगा सकते हैं कि विशिष्ट ग्राहक कैसे प्रतिक्रिया दे सकते हैं। सकते हैं। सिस्टम के बारे में सोचने के भाग के रूप में, PMs को अपने लॉन्च के प्रभावों का अनुमान लगाने का प्रयास करना चाहिए, लेकिन उन्हें कभी भी या तो मांग करके या उन्हें मिलने वाली किसी भी प्रतिक्रिया/इनपुट लेने से रोका नहीं जाता है। उत्पाद समीक्षा ही हमारी विकास प्रक्रिया में एकमात्र गेट है।