Backlog का आकार ग्राहकों के साथ बातचीत की आवृत्ति के व्युत्क्रमानुपाती होता है

 (bitbytebit.substack.com)
13 पॉइंट द्वारा GN⁺ 2024-01-24 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • ग्राहकों से जितनी अधिक बार बातचीत होगी, backlog का आकार उतना ही कम होगा
  • planning time की जगह ग्राहकों के साथ बातचीत को देना महत्वपूर्ण है
  • डेवलपर्स और ग्राहकों के बीच जितने अधिक मध्यस्थ होंगे, उतनी ही अधिक संभावना है कि product ग्राहकों की ज़रूरतों को पूरा नहीं कर पाएगा
  • बड़ा backlog यह दर्शाता है कि उसमें कई अप्रमाणित धारणाएँ हैं और उसके customer value पैदा करने की संभावना कम है

UI डिज़ाइन के बजाय तकनीकी components के डिज़ाइन पर ध्यान दें

  • UI डिज़ाइन पर बहुत अधिक समय खर्च न करें; एक बुनियादी UI को जल्दी जारी करना और ग्राहक feedback के आधार पर UI में सुधार करना अधिक महत्वपूर्ण है
  • technical debt को कम बनाए रखना चाहिए ताकि ग्राहकों को जिन बदलावों की ज़रूरत है, उन्हें तेज़ी से लागू किया जा सके

लोग सोचते हैं कि वे app का उपयोग जिस तरह करेंगे, वास्तविक उपयोग उससे अलग होता है

  • ग्राहकों को app इस्तेमाल करते हुए देखना महत्वपूर्ण है
  • उपयोगकर्ता के व्यवहार को सीधे देखने से ऐसे insights मिल सकते हैं जो केवल quantitative metrics से समझ में नहीं आते

account spoofing का implementation

  • यह समझने के लिए कि कोई विशेष ग्राहक वास्तव में कौन-सी screen देख रहा है, account spoofing feature में निवेश करना महत्वपूर्ण है
    • account spoofing: ऐसा feature जिसमें admin किसी विशेष production user की तरह app का उपयोग कर सकता है
  • इसके ज़रिए समस्याओं का प्रभावी ढंग से निदान किया जा सकता है और test data पर निर्भरता कम की जा सकती है

पहले page का महत्व

  • app में पहली बार आने वाले ग्राहक को सबसे प्रासंगिक जानकारी संक्षेप में देनी चाहिए
  • पहले page पर बहुत अधिक जानकारी भरने की कोशिश उपयोगकर्ता पर cognitive load बढ़ाती है

ग्राहक सबसे महत्वपूर्ण marketer हैं

  • NPS(Net Promoter Score) यह दिखाने वाला अच्छा metric है कि ग्राहक product को recommend करने लायक मज़बूत सकारात्मक भावना रखते हैं या नहीं
  • विज्ञापन पर पैसा खर्च किया जा सकता है, लेकिन संतुष्ट ग्राहकों से शुरुआत करना अधिक प्रभावी marketing strategy है

MVP बिना iterative improvement के अर्थहीन है

  • MVP केवल deadline pressure के नाम पर खराब customer experience देने का बहाना नहीं बनना चाहिए
  • MVP यह तय करने में मदद करता है कि आगे और iteration की ज़रूरत है या नहीं, और यदि है तो किन बिंदुओं में सुधार करना चाहिए

GN⁺ की राय

  • इस लेख का सबसे महत्वपूर्ण बिंदु यह है कि ग्राहकों के साथ लगातार संवाद के माध्यम से वास्तविक उपयोगकर्ताओं की ज़रूरतों को दर्शाने वाले product development का महत्व बहुत बड़ा है
  • यह ग्राहक feedback को तेज़ी से शामिल कर सकने वाले flexible UI डिज़ाइन और तकनीकी components के महत्व पर ज़ोर देता है
  • यह दिखाता है कि MVP से आगे बढ़कर product को लगातार बेहतर बनाना और ग्राहक संतुष्टि बढ़ाना दीर्घकालिक सफलता तक ले जा सकता है
  • यह लेख startup जीवन से मिले सबक साझा करता है और founders तथा developers को व्यावहारिक insights प्रदान करता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-01-24
Hacker News राय

  • फ़ीचर/सुधारों को व्यवस्थित करने के तरीके पर राय

    • अनुभव के अनुसार, हर आइडिया को टिकट में बदलने की रणनीति अप्रभावी है। ऐसा करने पर ऐसे आइडियाज़ से भरा एक 'icebox' बन जाता है जिनका कभी इस्तेमाल नहीं होगा।
    • जब किसी महत्वपूर्ण deal के लिए icebox में पड़े किसी आइडिया की ज़रूरत होती भी है, तब भी अक्सर याद नहीं रहता कि वह आइडिया पहले से मौजूद है, इसलिए नया टिकट बना दिया जाता है।
    • उन टिकटों को प्राथमिकता दी जाती है जिनके अल्पकाल या मध्यम अवधि में लागू होने की संभावना हो, और बाकी आइडियाज़ को अलग रखा जाता है।
    • engineering टीम उन technical debt की सूची रखती है जिन्हें वह हल करना चाहती है, और PM project-वार संभावित सुधारों की सूची बनाए रखते हैं।
    • नए फ़ीचर/प्रोडक्ट के लिए PRD लिखा जाता है, लेकिन उसे तुरंत टिकट में नहीं बदला जाता।
    • एक बहुत बड़ा backlog, जिसका अधिकांश हिस्सा कभी निपटाया नहीं जाएगा, इस बात का संकेत है कि PM 'न' कहने से डरता है।

  • backlog के आकार और PM turnover के बीच संबंध

    • backlog का आकार PM turnover के व्युत्क्रमानुपाती होता है।
    • पुराने PM के लिए backlog, पिछले product conversations की याद दिलाने वाला सहायक साधन होता है।
    • नए PM backlog को देखकर भ्रमित हो जाते हैं और जिन चीज़ों को वे समझ नहीं पाते, उन्हें साफ़ करने की कोशिश करते हैं।

  • customer-based backlog बनाए रखने के खिलाफ़ राय

    • जो टीमें backlog बनाए रखती हैं, वे अधिकतर backlog ग्राहकों से ही प्राप्त करती हैं।
    • "ऐसे फ़ीचर खोजो जो ग्राहक की ज़िंदगी बेहतर करें और उन्हें अगला फ़ीचर बनाओ" कहना जितना आसान लगता है, उतना है नहीं।
    • अगर कई ग्राहक हों, और हर एक की ज़िंदगी बेहतर करने वाले फ़ीचर एक-दूसरे से असंबंधित और जटिल हों, तो क्या किया जाए?
    • ग्राहकों की बात हमेशा सुननी चाहिए, लेकिन वे जो माँगते हैं, उसे लगभग कभी वैसा का वैसा नहीं बनाना चाहिए।
    • ग्राहक ऐसे फ़ीचर माँगते हैं जो सिर्फ UX implementation ही नहीं, बल्कि समस्या और उनके मौजूदा work process का भी संकेत देते हैं।
    • business problem को समझना चाहिए, और UX implementation के आइडिया तथा process-specific विवरणों को छोड़ देना चाहिए।
    • उस business problem को हल करने वाला न्यूनतम फ़ीचर आर्थिक रूप से, अच्छे UX design और consistency के साथ बनाना चाहिए।

  • ग्राहक requirements दर्ज करने के लिए PM की ज़रूरत

    • PM को ग्राहक requirements दर्ज करने के लिए एक जगह चाहिए।
    • अगर dedicated tool न हो, तो requirements का अधिकांश हिस्सा Jira tickets में जाकर खत्म होता है।
    • इसके लिए ProductBoard और Jira Product Discovery जैसी दो approaches हैं।
    • ProductBoard CRM approach अपनाता है, जिसमें हर customer interaction दर्ज किया जाता है और बाद में उसे requirements और wishes में तोड़ा जाता है।
    • Jira Product Discovery ideas से शुरू होता है, इसलिए ग्राहकों से सुनी हर बात को तुरंत requirements और wishes की लंबी सूची में तोड़ना पड़ता है।
    • Jira Product Discovery का फ़ायदा यह है कि यह ideas list को developer backlog से अलग रखता है, लेकिन साथ ही एक और लंबी सूची बना देता है।
    • अगर customer conversations के आधार पर product priorities का विश्लेषण करना हो, तो ProductBoard बेहतर product discovery tool है।

  • customer feedback से refine किए गए backlog का महत्व

    • जब लगभग हर दिन ग्राहकों से बात होती है, तो backlog में मौजूद फ़ीचर और सुधार सीधे customer feedback से informed और refined होते हैं।
    • करने के लिए काम हमेशा बहुत होता है, लेकिन फ़र्क इस बात से पड़ता है कि backlog customer feedback से informed और refined है या नहीं।

  • ग्राहकों से रोज़मर्रा की बातचीत के ज़रिए backlog management

    • एक technical व्यक्ति के रूप में हर दिन ग्राहकों से बात करते हुए, यह theory आकर्षक लगती है, लेकिन इसमें कुछ समस्याएँ हैं।
    • recency bias और opportunity cost: उन problem spaces पर feedback इकट्ठा करते रहना पड़ता है जिन पर जानबूझकर काम नहीं किया जा रहा, क्योंकि दूसरी चीज़ों की priority अधिक है।
    • reactive development: अगर feedback logging छोड़ दी जाए, तो ध्यान सबसे हाल की और सबसे आसानी से उपलब्ध चीज़ों पर चला जाता है, और पुराने मुद्दे छूट जाते हैं।
    • team knowledge base: अगर feedback इकट्ठा करने और solution देने के लिए एक ही जिम्मेदार व्यक्ति हो, तो OP की बात सही हो सकती है।
    • लेकिन अगर पूरी टीम शामिल हो, तो एक shared database चाहिए जिसमें data points को asynchronous तरीके से दर्ज और खोजा जा सके।
    • backlog तेज़ी से बड़ा हो सकता है, लेकिन जटिल systems और लोगों से निपटना स्वाभाविक रूप से कठिन है।
    • एक अच्छी तरह संगठित टीम के लिए backlog का अच्छा management ज़रूरी है, जिसमें असंबंधित काम को archive करना, duplicate काम हटाना, नियमित रूप से prioritization करना और tools का सर्वोत्तम उपयोग करना शामिल है।
    • backlog को manage करना tool से ज़्यादा महत्वपूर्ण है, और backlog के ऊपर एक 'facade' की ज़रूरत हो सकती है जो ज़रूरी जानकारी सतह पर लाए और आवश्यकता पड़ने पर गहराई में जाने दे।

  • app users को observe करने का महत्व

    • ग्राहकों को app इस्तेमाल करते हुए देखना महत्वपूर्ण है।
    • आप सभी metrics track कर सकते हैं, लेकिन जब कोई user किसी चीज़ को ढूँढने के लिए scroll करता है, back button दबाता है, या ऐसी चीज़ पर click करने की कोशिश करता है जिस पर click नहीं किया जा सकता, तो उसे देखना बिल्कुल अलग अनुभव होता है।
    • काश Apple, Google जैसी सभी कंपनियाँ हर दिन कई बार users को observe करें।

  • बड़े backlog की निरर्थकता

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

  • account spoofing लागू करने पर चेतावनी

    • account spoofing production environment में समस्याओं का परीक्षण करने का आसान तरीका है, लेकिन support और development टीमों को production data पर भरोसे की आवश्यकता होती है।
    • कुछ industries में यह ग्राहकों के लिए बड़ी समस्या बन सकता है।
    • जिस startup में आख़िरी बार काम किया गया, वहाँ developers को production data तक बिल्कुल भी access नहीं दिया जाता था।
    • security के नज़रिए से इसे आख़िरी उपाय माना जाना चाहिए, और बेहतर है कि इस धारणा के साथ काम किया जाए कि customer data तक access नहीं होगा।

  • product planning की tree structure

    • product planning हमेशा tree structure में होनी चाहिए।
    • सबसे ऊपर business goals होने चाहिए, उनके नीचे product, उसके नीचे customer problems, और उसके नीचे backlog items।
    • बहुत ज़्यादा backlog items होना इस बात का संकेत हो सकता है कि सही structure सेट नहीं है और prioritized business goals की सूची मौजूद नहीं है।
    • "ग्राहकों से बात करो" ग्राहक समस्याओं को समझने में उपयोगी है, लेकिन पहले business goals पता होने चाहिए। नहीं तो उन क्षेत्रों से feedback इकट्ठा करने में समय बर्बाद होगा जिन पर वैसे भी काम नहीं किया जाएगा।