हर ग्राहक एक समुदाय चाहता है: निर्माण से पहले स्कोप करने की गाइड

सारांश

पहली किकऑफ कॉल पर, लगभग हर सदस्यता ग्राहक कहता है "हम एक समुदाय चाहते हैं" — और यह वाक्यांश चुपचाप परियोजना को एक पोर्टल में बदल सकता है जिसमें फ़ोरम, इवेंट, कोर्स और लाइव रूम हों, जिन्हें लॉन्च के समय कोई उपयोग नहीं करेगा। यह लेख एजेंसियों को एक दोहराने योग्य स्कोपिंग बातचीत देता है, जो उस अस्पष्ट अनुरोध को एक छोटी, शिप की जा सकने वाली सदस्यता साइट में बदल देता है। यह वाक्य परीक्षण ("सदस्य इसलिए भुगतान करते हैं क्योंकि उन्हें ___ मिलता है") से शुरू होता है, ग्राहक को एक व्यवसाय मॉडल चुनने के लिए मजबूर करता है, समुदाय की सुविधाओं को तब तक टालता है जब तक कि वास्तविक दर्शक न हों, और हर फीचर अनुरोध को एक परिवर्तन आदेश (change order) मानता है। लेख में एक पूर्ण उदाहरण शामिल है, जिसमें एक ग्राहक पूर्ण समुदाय चाहता था और उसके स्थान पर एक खोजने योग्य संग्रह और एक मासिक लाइव प्रश्नोत्तरी लॉन्च की गई। यह जुड़ाव (engagement) का वादा करने के प्रति चेतावनी भी देता है: आप दरवाज़ा दे सकते हैं, लेकिन लोगों को उससे अंदर जाने के लिए मजबूर नहीं कर सकते। परिणाम एक रेस्क्यू मिशन के बजाय एक उत्पाद लाइन है, और ग्राहक आपको उस चीज़ के लिए धन्यवाद देते हैं जिसे आपने बनाने से मना कर दिया।

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

यह लेख उन प्रश्नों के इर्द-गिर्द बना है, जिनका उत्तर हम इस काम में लगातार देते रहते हैं। "हमें कौन सा टूल उपयोग करना चाहिए" नहीं — वह बाद में आता है — बल्कि वे प्रश्न जो तय करते हैं कि कोई परियोजना समय पर शिप होती है या नहीं, लाभदायक रहती है, और ग्राहक को ऐसा महसूस होता है कि आप जानते थे कि आप क्या कर रहे हैं।

"हम एक समुदाय चाहते हैं" — हम वास्तव में क्या बेच रहे हैं?

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

जब ग्राहक "समुदाय" कहते हैं तो वे वास्तव में जो खरीद रहे होते हैं, वह आमतौर पर चार श्रेणियों में आता है। जब हम दोहराने योग्य तरीके से स्कोप करते हैं, तो हम निर्णय को इनमें से एक में लाने के लिए बाध्य करते हैं:

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

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

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

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

लेकिन वे पहले ही सौ बार "समुदाय" कह चुके हैं

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

स्कोप बढ़ने देने से पहले एक समुदाय वास्तविकता जाँच (reality check) चलाएं। तीन प्रश्न पूछें:

1. पहले सप्ताह में, आप एक नए सदस्य से क्या विशिष्ट व्यवहार चाहते हैं? ("जुड़ें" नहीं — "एक परिचय पोस्ट करें," "एक टिप्पणी छोड़ें," "पहला पाठ पूरा करें।")
2. पहले महीने में आपकी टीम का कौन इस स्थान में समय बिताएगा, उत्तर देते हुए, मार्गदर्शन करते हुए और अव्यवस्था साफ़ करते हुए?
3. क्या पहले से ही कुछ लोग हैं जिन्हें यह समस्या है और वे एक-दूसरे को जानते हैं, या आप उम्मीद कर रहे हैं कि अजनबी वेबसाइट के अस्तित्व में आने से एक टीम बन जाएंगे?

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

सबसे छोटी चीज़ क्या है जो संभवतः काम कर सके?

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

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

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

जब अनुरोध ढेर हो जाते हैं तो क्या होता है?

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

स्थगित सुविधाओं की सूची को अपनी परियोजना में एक प्रथम श्रेणी की विपणन योग्य वस्तु (deliverable) बनाएं। इसे प्रस्ताव में रखें, इसे दृश्यमान रखें, और हर अतिरिक्त-स्कोप अनुरोध को इसमें जोड़ें। प्रत्येक आइटम को एक ट्रिगर स्थिति दें। "किसी दिन" नहीं बल्कि "यह तब शिप होता है जब 200 सक्रिय सदस्य एक महीने से स्थान में हों" या "जब ग्राहक इसे मॉडरेट करने के लिए प्रति सप्ताह दो घंटे के स्टाफ समय का वचन देता है।" आप मुश्किल नहीं बना रहे हैं; आप सुविधा को अस्तित्व का कारण दे रहे हैं।

इस तरह आप हर ग्राहक के लिए एक ही सदस्यता साइट को दोबारा बनाना बंद करते हैं: हर नए ग्राहक को एक ऐसे कंकाल के विन्यास के रूप में मानकर जिसे आप पहले ही शिप कर चुके हैं, और ऐसी चीज़ों की सूची के साथ जिन्हें आपने जानबूझकर नहीं बनाया। यदि कोई सुविधा स्थगित सूची में है, तो वह भविष्य की परियोजना है, जो भविष्य का राजस्व भी है। इसे इस तरह प्रस्तुत करें और ग्राहक आमतौर पर सहमत होंगे।

हम ग्राहक को खाली फ़ोरम के लिए हमें दोष देने से कैसे रोकें?

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

यह मायने रखता है क्योंकि ग्राहक लॉन्च के तीन सप्ताह बाद चुपचाप पूछने लगेंगे कि "समुदाय" शांत क्यों है। यदि आप शुरू से सीमा निर्धारित करते हैं, तो आप प्रोत्साहनों और सीडिंग (seeding) के बारे में एक उपयोगी बातचीत कर सकते हैं। यदि आपने नहीं किया, तो आप एक ऐसे प्लेटफ़ॉर्म को डीबग कर रहे होंगे जो टूटा नहीं है। इसे औपचारिक बनाने का एक व्यावहारिक तरीका: अपने रखरखाव रिटेनर में "समुदाय होस्टिंग और सीडिंग" के लिए एक अलग लाइन आइटम शामिल करें, या ग्राहक को एक सीडिंग चेकलिस्ट दें जो उनकी परियोजना किकऑफ़ में रहती है। मुद्दा श्रम विभाजन को स्पष्ट करना है। उपकरण प्रतिधारण रणनीति नहीं है; सदस्यता साइट मिथक आमतौर पर दोषी होते हैं जब लोग उम्मीद करते हैं कि एक प्लेटफ़ॉर्म उनकी ओर से बिक्री करेगा।

जब वे फिर भी समुदाय पर जोर देते हैं, तो हम क्या चालू करते हैं?

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

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

हम इसकी कीमत कैसे तय करें ताकि यह एक उत्पाद लाइन हो, न कि बचाव मिशन?

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

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

वह हिस्सा जो कोई नहीं सुनना चाहता

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

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