प्रोडक्ट मैनेजमेंट अभी भी कहानियाँ सुनाने के बारे में है

Product management का मतलब है कहानियाँ सुनाना। तो आइए मैं आपको एक कहानी के ज़रिए बताऊं कि मैं product management को कैसे देखता हूँ, और AI ने इसे कैसे बदल दिया है।

वह इंटरव्यू प्रश्न जो मैं कभी नहीं भूल पाया

मेरे करियर की शुरुआत RealNetworks में एक engineer के रूप में हुई थी, और कुछ ही वर्षों में मुझे RealPlayer के लिए product और engineering टीम की ज़िम्मेदारी सौंपी गई। उस समय यह एक बहुत महत्वपूर्ण consumer product था - इसके सैकड़ों मिलियन users थे, और इसने early internet पर audio और video लाने में मदद की थी। मैं business side के लोगों के साथ meetings में बैठता था, जो अक्सर ऐसे विचार सुझाते थे, "हमें हर बार player शुरू होने पर एक ad दिखाना चाहिए।" मुझे पता था कि यह सही बात नहीं है, लेकिन उनके Excel spreadsheets के सामने मेरी कोई दलील काम नहीं करती थी जिसमें दिखाया जाता था कि हम कितना पैसा कमा सकते हैं। मैं एक असली product manager बनना चाहता था, और निष्कर्ष निकाला कि मुझे शायद business school जाना चाहिए।

मैंने Berkeley में business school शुरू किया, और वहां पहुँचने के थोड़े ही समय बाद, अपने पुराने कॉलेज के email list पर देखा कि LinkedIn hiring कर रहा है। मैंने apply किया, और खुद को Reid Hoffman के साथ एक interview में पाया। उन्होंने बैठकर मुझे एक ऐसा interview question पूछा जिसे मैं कभी नहीं भूल पाया:

"तो, तुम एक product manager बनना चाहते हो। एक product manager क्या 'artifact' (उपलब्धि/आउटपुट) बनाता है?"

उन्होंने विस्तार से समझाया। Engineers का artifact होता है: code। Business development का artifact होता है: signed contracts। Designers visual look और graphics बनाते हैं। CEO के पास org chart, funding plan, और वह vision होती है जो सबको एक साथ रखती है। तो एक product manager का क्या?

मैंने उन्हें बताया कि मुझे यकीन नहीं था कि product managers के पास वास्तव में ऐसे "artifacts" होते हैं, लेकिन जो मूल बात हम करते हैं वह है हर चीज़ को इकट्ठा करना और उसे एक spec (विशिष्टीकरण) में लिख देना। Spec ही blueprint है। यहीं पर हम requirements परिभाषित करते हैं, और यह तय करते हैं कि हमें क्या करना है, और यह कंपनी के सबसे महत्वपूर्ण दस्तावेजों में से एक बन जाता है क्योंकि यह हर टीम को वहां से build करने के लिए unlock करता है।

मैं स्पष्ट रूप से नर्वस था। मुझे लगता है कि उन्होंने इसे नोटिस किया, क्योंकि उन्होंने मुझे आश्वस्त किया कि यह एक ठीक-ठाक जवाब था। अंततः मुझे नौकरी मिल गई, मैंने LinkedIn join करने के लिए business school छोड़ दिया, और तब से मैं उस प्रश्न के बारे में सोच रहा हूँ।

Spec से Story तक का विकास

क्योंकि मैंने गलत जवाब दिया था।

यह अभी भी software बनाने का Waterfall Era था। LinkedIn पर हम एक social platform के भीतर एक jobs platform को re-imagine करने की कोशिश कर रहे थे - जहाँ hiring managers mutual connections के संदर्भ में job applications देख सकें, candidates job listings देख सकें और अपने network के माध्यम से front door तक पहुँचने के तरीके खोज सकें। इस discovery process के दौरान, मैंने पूरी experience और requirements को परिभाषित करते हुए 120 पेज का spec लिखा।

मैंने पिछले कई वर्षों में इसके बारे में बहुत सोचा है। क्योंकि वह spec, जाहिर है, सबसे महत्वपूर्ण artifact नहीं है। Story है।

Spec एक system का वर्णन करता है, उसे क्या करना है, और पूरा होने से पहले किन boxes को check off करना है। यह product management की कला नहीं है। Product management उन लोगों की कहानी सुनाने के बारे में है जो product का उपयोग करेंगे, और यह उनके जीवन में क्यों मायने रखेगा। यह तुरंत समझ में आनी चाहिए, चाहे आप किसी से भी बात कर रहे हों। और यह repeatable होनी चाहिए - लोगों को इसे विश्वसनीय रूप से आगे बढ़ाने में सक्षम होना चाहिए, बिना आपके कमरे में मौजूद हुए।

यह एक बिल्कुल अलग दस्तावेज है, और एक बिल्कुल अलग काम है।

दस साल पहले मैंने product management पर एक talk दी थी, और लोग आज भी मुझे वह भेजते हैं; जो या तो flattering है, या इस बात का संकेत है कि क्षेत्र आगे नहीं बढ़ा है। मैं दोनों संभावनाओं पर विचार करूंगा। खैर, पूरी talk एक वाक्य पर आकर रुक गई: "एक product manager अपनी टीम (और कंपनी) को अपने users के लिए सही product ship करने में मदद करता है।" मैंने talk का अधिकांश समय उस वाक्य को शब्द-दर-शब्द तोड़ने में बिताया।

• Helps their team. आप leader नहीं हैं। बहुत से लोग सोचते हैं कि product manager leader होता है। आप वह व्यक्ति हैं जो चीज़ को संभव बनाने में मदद करता है। जिसका मतलब है कि आपको ...
• अपनी team और अपने company को समझना होगा। आपकी team आपका domain है: आपको इसे समझना होगा! और आपको यह भी समझना होगा कि यह बड़ी तस्वीर में कहाँ फिट होती है, ताकि आप केवल अपने लक्ष्यों को नहीं, बल्कि कंपनी के लक्ष्यों को भी पूरा कर सकें।
• Ship. हम जितना चाहें बात कर सकते हैं, लेकिन अंत में, सब कुछ इस बात पर निर्भर करता है कि product को customers के सामने रखा जाए।
• The right product for your users. अंततः हम काम पर पहुँच गए हैं: यह तय करना कि "right" वास्तव में क्या मतलब रखता है।

AI की दुनिया में इसमें से कितना बदलता है?

क्या बदल रहा है

जाहिर है कि कुछ बदल गया है, वास्तव में कई चीज़ें। एक तरफ, यह बदल रहा है कि हम कैसे code करते हैं, और एक idea से चलती हुई चीज़ तक हम कितनी तेज़ी से पहुँच सकते हैं। दूसरी तरफ, यह बदल रहा है कि users एक product से क्या होने की उम्मीद करते हैं। मुझे लगता है कि हमने इसकी चोटिल भी नहीं की है, विशेष रूप से consumer में। यह कहने में सक्षम होना कि आपको क्या चाहिए और product को उसे deliver करना, शायद background में agents के साथ, बिना आपको सीखने और interface करने की ज़रूरत हुए।

यह निश्चित है कि चीज़ें बनाने की लागत गिर चुकी है। अब किसी चीज़ को scope out करना और उसे try करना इतना मुश्किल नहीं है; यह आपको अपार flexibility देता है। लेकिन judgment (निर्णय) की लागत में कोई बदलाव नहीं आया है। क्या बनाना है, यह तय करना अब कभी से अधिक महत्वपूर्ण है।

Product development एक loop है। पहले यह होता था कि किसी के पास एक idea होता था - और यह ज़रूरी नहीं कि आपका हो; एक अच्छी कंपनी में यह कहीं से भी आ सकता है। आप उसे try करते हैं। आप एक spec लिखते हैं, या एक product brief, या जो भी उस दस्तावेज का नाम हो। इसमें कुछ up-front cost होता है: scoping, designing, arguing - हर वह चीज़ जो precious engineering time खर्च करने से पहले होनी चाहिए। ये सभी rituals हमने engineering time को खराब decisions से बचाने के लिए आविष्कार किए थे। क्योंकि आपको साल में उस loop के केवल छह या आठ चक्कर लगाने को मिलते थे।

फिर चीज़ें बनाना absurdly सस्ता हो गया। थोड़ा सा सस्ता नहीं; एक अलग order of magnitude। और जो हुआ वह वास्तव में दिलचस्प है। वह पुराना loop अभी भी बहुत हद तक मौजूद है - बस एक नए क्रम में पुनर्व्यवस्थित हो गया है।

पुराना loop इस प्रकार था: idea, spec, costing, scoping, बाकी सब कुछ, फिर building। अब:

• सबसे पहले, idea लें और उसे AI के साथ जल्दी से build करें, सिर्फ यह देखने के लिए कि यह कैसे काम करता है और कैसा लगता है।
• आप उसके साथ play करते हैं, और यह पता लगाते हैं कि यह कैसा लगता है और overall picture में कैसे फिट होता है। Prototypes हमेशा "what-ifs" से बेहतर होते हैं।
• फिर आप इसे design करते हैं। अब जब आपने उसके साथ play किया है, तो आप जानते हैं कि यह क्या है, और आप वास्तव में इस बात पर चर्चा कर सकते हैं कि इसे prototype से आगे ले जाने के लिए क्या चाहिए। यहाँ design का मतलब दोनों अर्थों में है: visual और UX design, और साथ ही engineering design भी।
• फिर आप ship करते हैं और सीखते हैं।

यह पूरी तरह से उलट जाता है: spec-and-scope से, build-and-play की ओर। मुझे लगता है कि यह product management को अभी हो रही अन्य किसी भी चीज़ से अधिक बदल रहा है।

इसका अंततः मतलब यह है कि spec अब deliverable नहीं है; असली में। आपको एक लंबा document लिखने और कागज पर सब कुछ सही करने से शुरू करने की ज़रूरत नहीं है। यह पहले एक aspirational sense में सच था, लेकिन अब यह literal sense में स्पष्ट रूप से सच है।

लेकिन मैं सावधान रहना चाहता हूँ, क्योंकि आप एक समान और विपरीत गलती भी कर सकते हैं।

Demos अब लगभग free हैं। Working products नहीं हैं। मैं इस नए approach का दूसरा पहलू बार-बार देखता हूँ: "यह तो great है, बस इसे ship कर दो।" यह अभी भी इस तरह काम नहीं करता है। हमें अभी भी इस बात का सम्मान करना होगा कि prototype से असली चीज़ तक की दूरी तय करने में अभी भी समय लगता है।

Product managers के बारे में एक trope है, कि उनका काम मुख्य रूप से यह पूछने के बारे में है, "क्या यह schedule में फिट होता है?" उस विचार को पूरी तरह से फेंक दें। सबसे महत्वपूर्ण प्रश्न है: क्या यह product में फिट होता है?

हमारे पास सभी के पास great ideas हैं, और अब हमारे पास सभी के पास agents हैं जो हमारे लिए code कर सकते हैं। क्या बनाना है, यह आधिकारिक तौर पर एक resourcing debate नहीं है। यह एक impact debate है। "यह या वह", न कि "यह या कुछ नहीं।" Taste और curation यहाँ बहुत मायने रखते हैं, जब आपके पास एक vision हो और आप वास्तव में जानते हों कि आप दुनिया के लिए क्या करने की कोशिश कर रहे हैं। लेकिन system जिसे आप बनाते हैं, उसे अभी भी complete feel होना चाहिए।

AI के बारे में मेरी सबसे बड़ी चिंता यह है कि यह हमें तेज़ी से जाने देता है, और इसलिए हम सब कुछ cram कर देते हैं। हम content में "AI slop" के बारे में बात करते हैं; यह product के लिए AI slop का मतलब है। मैंने इसे कुछ जगहों पर पहले ही होते देखा है, और मुझे लगता है कि हम सभी इसके बारे में थोड़े चिंतित हैं। जब कोई भी कुछ भी बना सकता है, तो क्या बनाना है, यह तय करना ही पूरा काम है। और यह एक story problem है। आप कौन सी कहानी सुनाना चाहते हैं? आप चाहते हैं कि आपके customers कौन सी कहानी समझें? आप चाहते हैं कि उनके दिमाग में कौन सी कहानी जीवंत रहे?

एक PM के रूप में आपका काम यह spec लिखना नहीं है कि product क्या करेगा। यह एक shared understanding बनाने के बारे में है - यह कि हम क्या कर रहे हैं और क्यों, इसकी एक साझा तस्वीर। User यहाँ क्यों है? वे हर step पर क्या महसूस करते हैं, और यह क्यों मायने रखता है? यह कहाँ impressive है, और कहाँ boring? Product का कभी-कभी boring होना ठीक है, बशर्ते आप जानते हों कि कहाँ। लेकिन अगर आप एक अच्छी script नहीं लिख सकते, तो product dull रहेगा।

AI जो gift देता है वह यह है कि अब आप यह मुफ्त में पता कर सकते हैं, right up front। आप इसे जल्दी से build कर सकते हैं, इसका अनुभव ले सकते हैं, इसके साथ play कर सकते हैं, और वह एक वाक्य तय कर सकते हैं: यह product किसी के जीवन में उनके लिए क्या करता है? क्योंकि अगर आप उसका जवाब दे सकते हैं, तो आप मेरे प्रश्न का जवाब दे सकते हैं: "क्या लोग वास्तव में इसका उपयोग कर रहे हैं?" क्योंकि अब आपने कहा है कि यह क्या करता है, और आप पूछ रहे हैं कि क्या वे इसे करते हैं।

क्या नहीं बदल रहा है

अपने product के लिए एक "vision" का मतलब क्या है?

जब मैं vision कहता हूँ, तो मेरा मतलब mission statement से नहीं है। वे मायने रखते हैं, लेकिन वे vision नहीं हैं। Vision users के लिए product के अस्तित्व का end-to-end कारण है। मेरे पास इसके लिए एक सरल framework है:

• Purpose। कोई व्यक्ति अपना product क्यों उठाता है और इसे अपने जीवन में क्यों शामिल करता है?
• Core actions। जब वे इसे उठाते हैं, तो वे वास्तव में क्या कर रहे हैं? एक से अधिक चीज़ें हो सकती हैं, आपको उन्हें सबको समझना होगा।
• Cycle। उन core actions में से प्रत्येक की expected frequency क्या है?

मेरे पूरे करियर में, जैसे-जैसे मैं founders और अन्य product people से मिला हूँ, मैं उनसे पूछता हूँ: क्या लोग आपके product का उपयोग कर रहे हैं? और वे लगभग हमेशा सीधे user data पर कूद जाते हैं। "हमारा DAU/MAU ratio 50% है। हमने 10,000 signups पार कर लिए हैं। हमारे पास waitlist पर एक लाख लोग हैं। हमारा ARR एक million है। हम दिन में four billion tokens कर रहे हैं। हम App Store पर #3 पर पहुँच गए।"

क्या उनमें से कोई भी मेरे पूछे गए प्रश्न का जवाब है?

कभी-कभी मैं प्रश्न दोहराता हूँ, लेकिन एक और शब्द जोड़ता हूँ: क्या लोग वास्तव में *really* आपके product का उपयोग कर रहे हैं? और फिर, कभी-कभी, वे समझते हैं कि मैं किस बारे में पूछ रहा हूँ।

LinkedIn का purpose था find और be found। शायद कुछ लोगों के लिए, core action सिर्फ तब response देना था जब कोई reach out करता था। ज्यादातर लोगों के लिए यह daily चीज़ नहीं है; यह साल में एक या दो बार हो सकता है।

उस cycle को देखें - साल में एक या दो बार। इसे समझना LinkedIn के काम करने के लिए महत्वपूर्ण था, क्योंकि network को बहुत बड़ी संख्या में लोगों की ज़रूरत थी जो found होने को तैयार हों, और कम से कम कुछ लोगों को finding करने के लिए।

LinkedIn आखिरकार एक social network था, इसलिए आप users को हर दिन actions लेने के लिए प्रोत्साहित करने के लिए tempted हो सकते हैं। हमने ऐसा नहीं किया। इसके बजाय, हमने शुरुआती दिनों में profiles को accurate रखने के लिए enormous समय बिताया। यदि आप साल में केवल एक या दो बार found होते थे, तो यह पूरी तरह से ठीक था, बशर्ते जब यह वास्तव में होता, तो आप click through करते और समझते, "कोई मुझसे reach out कर रहा है, यह great है।"

जब आप यह माप रहे होते हैं कि आपका product काम कर रहा है या नहीं, तो वे core actions ही मायने रखते हैं। Direct traffic पर ध्यान दें: उन लोगों को खोजें जो literally came to you। उनके पास app installed है और वे icon दबाते हैं, या वे अपना domain हाथ से type करते हैं; वे आपके पास अपनी मर्ज़ी से आए। वह traffic मायने रखता है, बाकी सभी तरीकों के विपरीत जिनसे आप किसी को उस क्षण में वापस ला सकते हैं।

और फिर केवल उन लोगों को वास्तव में गिनें जो core actions perform करते हैं। "App को briefly खोल लिया", नहीं, बल्कि वास्तव में engage किया। Discord पर यह होता, "live session में शामिल हुआ। वास्तव में messages पढ़े और भेजे।"

अगर आप परिभाषित नहीं कर सकते कि वे core actions क्या हैं, तो आपके पास कोई product नहीं है, क्योंकि आपके पास कोई ऐसी चीज़ नहीं है जिसे आप समझते हैं।

अब, एक चीज़ जो नई है, और जिससे मुझे प्यार है, वह यह है कि AI products में जहाँ user product से बात कर रहा है, या किसी तरह prompt कर रहा है, आपके पास अब आपके user journey का literal transcript है। आप देख सकते हैं कि लोग अपने शब्दों में क्या कह रहे हैं। आप वह exact moment देख सकते हैं जब किसी ने हार मान ली और rephrase किया। आप देख सकते हैं कि उन्होंने product से क्या करने की उम्मीद की थी जो उसने नहीं किया। इन्हें पढ़ें! AI उन चीज़ों को surface करने के लिए great है जिन्हें आपने पहले नहीं देखा होगा, लेकिन आप इसे सब कुछ summarize नहीं कर सकते, और आप इसे अपना opinion form नहीं कर सकते। अपना opinion बनाना - यह पता लगाना कि कहानी वास्तव में क्या है - product management का काम और कला है।

Onboarding

Onboarding वह single most important moment है जब आपको customer को अपनी कहानी सुनानी होती है। उन्होंने अपना product discover किया है - शायद एक ad, viral invite, article, या कुछ भी के माध्यम से। वे जानते हैं कि आप मौजूद हैं; वे curious हैं और इसे try करना चाहते हैं। आप उन्हें कभी भी इतना attention नहीं पाएंगे।

आपको याद रखना होगा, इस बिंदु पर, कि हर कोई आपके product के साथ समान motivation के साथ नहीं आता है। Eagers होते हैं। वे अंदर आना बहुत ज़्यादा चाहते हैं। वे जाने के लिए तैयार हैं। और, स्पष्टता के लिए, यदि आप कंपनी में काम करते हैं, तो आप eager-land में रहते हैं। आपके कंपनी के अंदरूनी हर व्यक्ति को एक eager की तरह treat किया जाना चाहिए; वे पहले से ही हर दिन product में डूबे हुए हैं। जब वे product पर onboard होते हैं तो वे सोचते हैं, "मुझे पता है कि मैं क्या कर रहा हूँ, यह boring है, यह step यहाँ क्यों है?"

दूसरी तरफ Fly-bys होते हैं। वे आपमें इतने interested नहीं हैं। उन्होंने इसके बारे में सुना, इसे check किया, लेकिन message land नहीं हुआ, और वे bail करने वाले हैं।

Users के ये दो kinds distribution के edges हैं। बीच में एक बड़ा fuzzy middle है। ये वे लोग हैं जो एक कारण से आए थे: वे curious हैं! वे और अधिक जानना चाहते हैं! और आप वास्तव में उन्हें अपने product के core users में convert कर सकते हैं। ये वे लोग हैं जिनके चारों ओर आपको build करना है। Eagers तो आपको anyway मिल जाएंगे। Middle को समझना है।

मान लें कि आपके users motivated और curious हैं। Product को introduce करने के लिए समय लें, step by step। More simple steps beat fewer complex ones. मैंने पिछले वर्षों में कई कंपनियों में A/B tests के ज़रिए इसे साबित किया है। यदि हर step discrete और simple है, और यह स्पष्ट है कि आप क्या पूछ रहे हैं और क्या सिखा रहे हैं, तो यह single large screens, या steps की संख्या कम रखने के लिए complex choices से बेहतर है। हर बार।

तो आप वास्तव में उसे कैसे बनाते हैं?

Core message को दोहराकर शुरू करें: Here’s what this is for. Context को product के अंदर state करें। Basics मांगना ठीक है - email, password, phone। बाकी सबके लिए, समझाएं कि आप क्यों पूछ रहे हैं, और यह कैसे संबंधित है। फिर अपने product को its key concepts में तोड़ें, प्रत्येक के साथ user के लिए एक clear action हो।

AI products ने इसे आसान नहीं, बल्कि कठिन बना दिया है। आपको blank prompt box मिलता है। कुछ मायनों में यह अब तक का सबसे बुरा onboarding screen है। यह एक magic box है। यह कुछ भी कर सकता है। तो... आप क्या करना चाहते हैं?

आजकल बहुत से products इस प्रकार शुरू होते हैं, "Hi, I’m here to help, ask me anything!" मेरे लिए बोलते हुए, उस क्षण में मैं सबसे articulate या creative व्यक्ति नहीं हूँ। आपको capabilities को concept by concept सिखाना होता है। "अगर आप इस तरह कुछ पूछते हैं, तो मैं इसे कर सकता हूँ।" और फिर product को इसे करने दें। User को जल्दी से कम से कम एक valuable use case तक पहुँचाएं, आदर्श रूप से उनके own data के साथ, ताकि यह उनके लिए वास्तव में valuable हो।

लोग मुझसे कभी-कभी पूछते हैं: एक longer flow के साथ, क्या अधिक लोग drop off करेंगे? हाँ! लेकिन जो लोग pass करते हैं, वे आपके product का वास्तव में उपयोग करने की कहीं अधिक संभावना रखते हैं। यदि आप दो अलग-अलग onboarding flows को A/B test कर रहे हैं, तो यह मत देखें कि कितने लोग flow के अंत तक पहुँचे। देखें कि अगले दिन, या अगले हफ्ते कितने लोग वापस आते हैं, और कितनों ने core action लिया। यदि आप उस क्षण में उनसे पूछें, "यह product क्या है?" तो उन्हें लगभग सही जवाब देना चाहिए। इस बिंदु से आगे, आपका retention data आपका report card है।

Twitter से एक कहानी

मैं Twitter से एक कहानी सुनाकर इस सबको एक साथ wrap कर दूंगा।

मैंने late 2009 में Twitter join किया। हमारे पास एक growth problem थी - हालांकि यह वास्तव में growth problem नहीं थी। Twitter लगातार news में रहता था। लोग इसके बारे में blog कर रहे थे, media इसके बारे में बात कर रहा था, और बहुत से लोग पूछ रहे थे: "यह Twitter क्या चीज़ है? मुझे इसे figure out करना है और sign up करना है।" और फिर उनमें से millions ने किया। लेकिन वे कभी वापस नहीं आए।

समस्या यह थी कि कोई भी आपको नहीं बता सकता था कि Twitter *क्या* था। मैं वास्तव में इसे साबित कर सकता हूँ:

Caption: "हम अंततः number one पर पहुँच गए।"

हम जिस तरह से onboarding कर रहे थे, वह यह था कि लोग sign up करते, और "Find your friends" या "Follow 20 random people" के options देखते। ज्यादातर लोग इसे skip कर देते, और फिर एक page पर landing करते जो इस प्रकार दिखता था:

यह pretty terrible है! यह एक big empty box है। लोग इसे देखते और सोचते, "...मेरे पास कहने के लिए कुछ नहीं है।" और फिर वे चले जाते। यदि आप उस क्षण में उनसे पूछते, "Twitter क्या है?" तो वे कहते, "मुझे लगता है यह दुनिया को कुछ कहने के बारे में है? या अपने दोस्तों को खोजने के बारे में? मुझे नहीं पता।"

इसलिए हमने कुछ वर्षों में onboarding को rebuild किया, और वह चीज़ ढूंढी जो काम करती थी, जो कि Learn Flow था। हमने उन्हें Twitter सिखाया, एक concept at a time, as a story। और उस वर्ष हमने जो कुछ भी ship किया, उससे अधिक retention इसने move किया।

Learn Flow, screen by screen

सबसे पहले, नया home page: "Welcome to Twitter." हमने वहां content डालने की कोशिश नहीं की, बस: "Find out what’s happening right now with the people and organizations you care about." ईमानदारी से कहूं तो, यह Twitter का pretty good description है।

फिर: This is a tweet. यह एक short message है, up to 140 characters, और इसमें links हो सकते हैं। अब आप जानते हैं कि tweets इस चीज़ का unit हैं।

अगला आपको अपनी timeline build करनी होती है। इसलिए हमने आपको एक timeline दिखाई। हमने आपको left पर लोगों पर "follow" click करने के लिए मजबूर किया। और जब वे follow click करते हैं, तो उनके tweets right पर appear होते हैं। तो आपको पूरा idea एक ही motion में मिल जाता है: I click follow, tweets show up, that’s my timeline. जो कि Twitter का actual concept है - tweets, following, और एक timeline।

और फिर, अंत में, आपकी timeline। आप उस पर हर account को recognize कर लेते, क्योंकि आपने वास्तव में उन्हें स्वयं follow किया था।

Onboarding आपकी कहानी है।

Your users के लिए सही product

एक product manager के रूप में आपका काम अपनी टीम और अपनी कंपनी को अपने users के लिए सही product ship करने में मदद करना है। AI की दुनिया में, shipping पहले जितनी समस्या नहीं है। Right product को figuring out करना, और यह जानना कि आपके users कौन हैं, उतना ही महत्वपूर्ण है जितना कभी भी था। अगर अधिक नहीं, तो कम नहीं।

हमेशा पूछें कि क्या लोग वास्तव में आपके product का उपयोग कर रहे हैं। इसे समझें कि इसका क्या मतलब है। Purpose, core actions, और cycle के बारे में सोचें। Onboarding पर जितना reasonable लगता है उससे अधिक समय बिताएं। यह वह जगह है जहाँ आप fuzzy middle को convert करते हैं, और यह वह जगह है जहाँ आप वास्तव में अपने product की कहानी सुनाते हैं।

Prototypes पर तेज़ी से जाने के लिए AI का उपयोग करें — लेकिन अपने judgment को तेज़ न करें। अपना judgment मत छोड़ें। बस यह मत कहें, "Well, let’s test it and see." इसी तरह आप sloppy product के साथ समाप्त होते हैं। हर जगह अपना judgment बनाए रखें। काम का सबसे कठिन हिस्सा अभी भी हमारे product managers के रूप में सभी creativity को अब हमारे पास उपलब्ध सभी data के साथ balance करना है।

Good luck!