← LeaderboardThe Skill Leaderboard

prd-template

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

Published by mohitagw15856 ↗mohitagw15856/pm-claude-skills

Try your first task

A source-grounded starter task has not been verified for this skill yet.

SKILL.md

# machine-translated to hi from skills/prd-template/SKILL.md — review: pending. Native fixes welcome via PR.name: prd-templatedescription: "सिद्ध PM टेम्पलेट संरचना के अनुसार प्रोडक्ट आवश्यकता दस्तावेज़ बनाएँ। जब कोई किसी नए फ़ीचर या प्रोडक्ट के लिए PRD, प्रोडक्ट स्पेक, फ़ीचर विनिर्देश या आवश्यकता दस्तावेज़ लिखने को कहे, तब इसका उपयोग करें। समस्या कथन, यूज़र स्टोरी, कार्यात्मक आवश्यकताओं, तकनीकी विचारों और सफलता मेट्रिक के साथ एक पूरा PRD तैयार करता है।"version: 1.0.0

PRD टेम्पलेट स्किल

यह स्किल उद्योग की सर्वोत्तम प्रथाओं के अनुसार पेशेवर प्रोडक्ट आवश्यकता दस्तावेज़ बनाने में मदद करती है।

यह कहाँ बैठता है — रीढ़ का मध्य

प्रोडक्ट-निर्णय रीढ़ में दूसरा: /assumption-mapper → prd-template → /rice-prioritisation → /roadmap-narrative। यह /assumption-mapper से सबसे जोखिम भरी धारणा प्राप्त करता है (अगर वह चला हो, तो जोखिमों का फिर से अनुमान लगाने के बजाय उसका मानचित्र पढ़ें) और /rice-prioritisation को PRD की सफलता मेट्रिक सौंपता है — वह एक बेसलाइन वाली संख्या जो RICE का Impact बनती है। साझा शब्द (समस्या कथन, परिकल्पना, सफलता मेट्रिक, स्रोत) एक ही बार docs/craft/product-decisions.md में रहते हैं; उन्हें ठीक वैसे ही उपयोग करें।

चक्र

PRD बाहर से भीतर लिखा जाता है — समाधान से पहले समस्या, हमेशा — चार चरणों में। चरण 1 भार-वाहक है: धुँधली समस्या पर बना PRD अंत तक पॉलिश होता है और फिर भी ग़लत रहता है।

  1. समस्या कथन तय करें। एक वाक्य: किसे कौन सी समस्या है, कब, और उसे छोड़ने की लागत। कोई समाधान भाषा नहीं। नीचे का सब कुछ इसी से जुड़ना चाहिए। पूरा तब जब: समस्या कथन बिना किसी फ़ीचर का नाम लिए अकेला खड़ा हो, और एक अजनबी बता सके कि "हल हुआ" का क्या मतलब है।
  2. सफलता मेट्रिक की बेसलाइन तय करें। वह एक संख्या जो साबित करे कि समस्या हल हुई — उसकी वर्तमान बेसलाइन और वह बदलाव जो सफलता गिना जाए। /assumption-mapper का कोई भी जोखिम यहाँ खुले प्रश्न के रूप में लाएँ, मौन दाँव के रूप में नहीं। पूरा तब जब: मेट्रिक की बेसलाइन हो (या स्पष्ट रूप से बिना-बेसलाइन चिह्नित हो), और वह गतिविधि नहीं, समस्या मापे।
  3. खंडों का मसौदा बनाएँ, हर एक ऊपर तक जुड़ता हुआ। टेम्पलेट (नीचे) ऐसे भरें कि हर आवश्यकता और स्टोरी समस्या कथन तक जाए; जो न जाए उसे हटाएँ। तथ्यों को स्रोत से टैग करें — अनुमानित संख्या [hunch] है, लेबल सहित। पूरा तब जब: हर आवश्यकता समस्या कथन तक जाए, और हर दावा किया गया तथ्य [data]/[hunch]/[assumption] रखता हो।
  4. सौंपें। सफलता मेट्रिक और पहल(ओं) को सामने लाएँ ताकि /rice-prioritisation इसी मेट्रिक से Impact स्कोर कर सके, फिर से गढ़ी गई से नहीं। पूरा तब जब: PRD वह मेट्रिक और दायरा नामित करे जो /rice-prioritisation को बिना दोबारा पूछे स्कोर करने के लिए चाहिए।

आवश्यक इनपुट

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

  • फ़ीचर या प्रोडक्ट का नाम
  • हल की जा रही समस्या (उपयोगकर्ता के नज़रिए से)
  • लक्षित उपयोगकर्ता (भूमिका, संदर्भ, वे क्या पूरा करना चाहते हैं)
  • सफलता मेट्रिक (आपको कैसे पता चलेगा कि यह काम किया?)
  • दायरा (MVP बनाम पूरी दृष्टि — क्या अंदर है और क्या बाहर)
  • मुख्य हितधारक (किसे समीक्षा और मंज़ूरी देनी है)

Brain से पढ़ता है / Brain में लिखता है

अगर कोई professional-brain (brain/) मौजूद है, तो जो संदर्भ आपके पास पहले से है उसे पूछने के बजाय उसका उपयोग करें:

  • पहले पढ़ें: context.md (प्रोडक्ट, मेट्रिक परिभाषाएँ, आवाज़), knowledge/strategy.md (प्रोडक्ट कहाँ जा रहा है), कोई संबंधित hypotheses/ और मेल खाती entities/ फ़ीचर फ़ाइल। आधारित तथ्य निकालने के लिए python3 ../professional-brain/scripts/brain_query.py ./brain "<feature>" चलाएँ, और उनके स्रोत टैग PRD में साथ लाएँ (किसी [hunch] को तय आवश्यकता की तरह पेश न करें)।
  • बाद में लिखें: फ़ीचर को entities/<feature>.md के रूप में/में सहेजें, किसी भी दायरा निर्णय को decisions/ में दर्ज करें, और नई धारणाएँ hypotheses/ में जोड़ें। हर एक को उसके स्रोत से टैग करें।

गहरी सामग्री

यह स्किल दो सहायक फ़ाइलों के साथ आती है — उपलब्ध हों तो उनका उपयोग करें:

  • templates/prd-skeleton.md — प्रति खंड "अच्छा कैसा दिखता है" संकेत वाला भरने योग्य PRD कंकाल। जब उपयोगकर्ता जनरेट किए मसौदे के बजाय खुद पूरा करने के लिए दस्तावेज़ चाहे, तब इससे शुरू करें।
  • references/success-metrics-guide.md — सफलता मेट्रिक खंड के लिए कैलिब्रेशन: चार-भाग मेट्रिक परीक्षण, मानक अपनाना/परिणाम/व्यवसाय/गार्डरेल सेट, और आम जाल। मेट्रिक तालिका लिखते या समीक्षा करते समय इसे देखें।

टेम्पलेट संरचना

हर PRD में ये खंड क्रम से शामिल होने चाहिए:

1. अवलोकन

  • समस्या कथन: हम कौन सी समस्या हल कर रहे हैं? (2-3 वाक्य)
  • प्रस्तावित समाधान: हम क्या बना रहे हैं उसका उच्च-स्तरीय विवरण (2-3 वाक्य)
  • सफलता मेट्रिक: हम सफलता कैसे मापेंगे (3-5 मुख्य मेट्रिक)

2. संदर्भ और पृष्ठभूमि

  • अभी क्यों: यह सही समय क्यों है?
  • रणनीतिक संरेखण: यह कंपनी के उद्देश्यों से कैसे जुड़ता है?
  • उपयोगकर्ता रिसर्च सारांश: रिसर्च की मुख्य अंतर्दृष्टियाँ (लागू हो तो)

3. यूज़र स्टोरी और उपयोग-मामले

प्रारूप: "एक [उपयोगकर्ता प्रकार] के रूप में, मैं [क्रिया] चाहता हूँ ताकि [लाभ]"

  • 3-7 प्राथमिक यूज़र स्टोरी शामिल करें
  • हर एक के लिए स्वीकृति मानदंड जोड़ें

4. आवश्यकताएँ

कार्यात्मक आवश्यकताएँ:

  • अनिवार्य फ़ीचर (P0)
  • होने चाहिए फ़ीचर (P1)
  • हों तो अच्छा फ़ीचर (P2)

गैर-कार्यात्मक आवश्यकताएँ:

  • प्रदर्शन अपेक्षाएँ
  • सुरक्षा संबंधी विचार
  • पहुँच-योग्यता आवश्यकताएँ

5. डिज़ाइन और उपयोगकर्ता अनुभव

  • डिज़ाइन मॉक या वायरफ़्रेम का लिंक
  • मुख्य उपयोगकर्ता प्रवाह
  • किनारे के मामले और त्रुटि स्थितियाँ

6. तकनीकी विचार

  • आर्किटेक्चर निहितार्थ
  • दूसरे सिस्टम पर निर्भरताएँ
  • तकनीकी जोखिम और शमन

7. कार्यान्वयन योजना

  • चरण 1 (MVP): पहले संस्करण में क्या जाता है
  • चरण 2: आगे क्या आता है
  • चरण 3: भविष्य के सुधार

8. खुले प्रश्न

  • जो निर्णय अभी लेने बाकी हैं
  • परामर्श के लिए हितधारक
  • आवश्यक रिसर्च

9. परिशिष्ट

  • रिसर्च लिंक
  • संबंधित दस्तावेज़
  • प्रतिस्पर्धी विश्लेषण

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

लेखन दिशानिर्देश

लहजा: स्पष्ट, संक्षिप्त, कार्रवाई योग्य श्रोता: इंजीनियर, डिज़ाइनर, हितधारक लंबाई: फ़ीचर के लिए 3-6 पृष्ठ, प्रोडक्ट के लिए 8-12 का लक्ष्य

सर्वोत्तम प्रथाएँ:

  • अमूर्तता के बजाय ठोस उदाहरण उपयोग करें
  • सिर्फ़ "क्या" नहीं, "क्यों" भी शामिल करें
  • आवश्यकताओं को परखने योग्य बनाएँ
  • सहायक सामग्री के लिंक दें
  • निर्णय होने पर अपडेट करें

अच्छा PRD किससे बनता है

✅ करें:

  • उपयोगकर्ता के नज़रिए से लिखें
  • विशिष्ट सफलता मेट्रिक शामिल करें
  • किनारे के मामलों को संबोधित करें
  • रिसर्च और डेटा के लिंक दें
  • समझौतों को स्पष्ट करें

❌ न करें:

  • कार्यान्वयन विवरण लिखना (वह टेक स्पेक है)
  • मान लेना कि सबके पास संदर्भ है
  • आवश्यकताओं को अस्पष्ट छोड़ना
  • "क्यों" छोड़ना
  • पहुँच-योग्यता भूलना

स्कोरिंग रूब्रिक (0–40)

इस स्किल का कोई भी आउटपुट सौंपने से पहले स्कोर करें; 32+ शिप-गुणवत्ता है।

आयाम0510
समस्या का आधारसमस्या कंपनी के नज़रिए से कही गई, या बिना साक्ष्य के दावाउपयोगकर्ता-केंद्रित समस्या, पर समर्थक डेटा धुँधला ("उपयोगकर्ता निराश हैं") और रिसर्च का हवाला नहींसमस्या उपयोगकर्ता की है, वर्तमान-स्थिति डेटा से परिमाणित, और "अभी क्यों" समझाता है क्या बदला; दावे उद्धृत रिसर्च तक जाते हैं
आवश्यकताओं की परख-योग्यताआवश्यकताएँ धुँधले गुण हैं ("तेज़", "सहज") जिन्हें समीक्षक सत्यापित नहीं कर सकताज़्यादातर आवश्यकताएँ ठोस, पर स्वीकृति मानदंड कमज़ोर और गैर-कार्यात्मक आवश्यकताएँ टेम्पलेट जैसीहर P0/P1/P2 आइटम और NFR सत्यापन योग्य है (सीमाएँ, पर्सेंटाइल, मानक), और हर एक किसी यूज़र स्टोरी या रिसर्च निष्कर्ष तक जाता है
मेट्रिक की कठोरतासफलता मेट्रिक गायब, या बिना बेसलाइन के प्रतिशतबेसलाइन और लक्ष्य हैं, पर मेट्रिक सिर्फ़ अपनाना मापते हैं — कुछ भी यह नहीं पकड़ेगा कि फ़ीचर सफल हो और व्यवसाय हारेहर मेट्रिक में बेसलाइन → लक्ष्य, सेट अपनाने के साथ परिणाम भी कवर करता है, और कम से कम एक गार्डरेल उपयोगकर्ता को नुक़सान पहुँचाकर मेट्रिक जीतने से बचाता है
दायरे और जोखिम की ईमानदारीMVP और भविष्य के चरण घुल-मिल जाते हैं; कोई खुला प्रश्न सूचीबद्ध नहींचरण अलग हैं, पर कटौती-रेखाओं के कारण अनुपस्थित और असहमतियाँ दबाई गईंहर चरण सीमा का घोषित कारण है, दायरे से बाहर की माँगें पुनः-प्रवेश शर्तों के साथ दर्ज, और खुले प्रश्नों में स्वामी, समयसीमा और हर उत्तर की लागत

गुणवत्ता जाँच

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

एंटी-पैटर्न

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

उदाहरण PRD की शुरुआत

# PRD: मल्टी-चैनल ग्राहक सहायता डैशबोर्ड

## अवलोकन

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

**प्रस्तावित समाधान**: एक एकीकृत डैशबोर्ड बनाएँ जो सभी चैनलों की ग्राहक पूछताछ को एक इंटरफ़ेस में इकट्ठा करे, चैनलों के आर-पार बातचीत का इतिहास बनाए रखे, और एजेंट की विशेषज्ञता और उपलब्धता के आधार पर बुद्धिमान रूटिंग दे।

**सफलता मेट्रिक**:
- औसत प्रतिक्रिया समय 4 घंटे से 1 घंटा करें
- टूल बदलने का समय 80% घटाएँ (2.3 से <0.5 घंटे)
- ग्राहक संतुष्टि स्कोर 3.8 से 4.5 (5 में से) करें
- सहायता एजेंट उत्पादकता 35% बढ़ाएँ

## संदर्भ और पृष्ठभूमि

**अभी क्यों**: पिछले 6 महीनों में ग्राहक संतुष्टि 15% गिरी है, मुख्यतः धीमी प्रतिक्रिया के कारण। हमारे शीर्ष प्रतिस्पर्धी ने पिछली तिमाही एकीकृत सहायता डैशबोर्ड लॉन्च किया, और सेल्स कॉल में हम इसके बारे में सुन रहे हैं। सहायता टीम का टर्नओवर सालाना 45% है, जिसमें "टूल की जटिलता" शीर्ष निराशा बताई गई।

**रणनीतिक संरेखण**: यह "ग्राहक रिटेंशन 10% सुधारें" के हमारे Q1 कंपनी उद्देश्य और "औसत हैंडल समय 25% घटाएँ" के सहायता टीम OKR से जुड़ता है।

**उपयोगकर्ता रिसर्च सारांश**: हमने 12 सहायता एजेंटों के साक्षात्कार किए और 20 घंटे के सहायता सत्र देखे। मुख्य निष्कर्ष:
- एजेंट अपना 35% समय पिछली बातचीत का संदर्भ खोजने में लगाते हैं
- 65% एस्केलेशन बातचीत के इतिहास की कमी से होते हैं
- एजेंटों ने टूल बदलने को अपनी #1 दैनिक निराशा बताया (9.2/10 दर्द)
- सहायता अनुभव का वर्तमान NPS -12 है

## यूज़र स्टोरी और उपयोग-मामले

**US1: एकीकृत इनबॉक्स**
एक सहायता एजेंट के रूप में, मैं सभी ग्राहक पूछताछ एक जगह देखना चाहता हूँ ताकि मैं अत्यावश्यक अनुरोध न चूकूँ और प्रभावी ढंग से प्राथमिकता दे सकूँ।

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

**US2: क्रॉस-चैनल संदर्भ**
एक सहायता एजेंट के रूप में, मैं चैनल की परवाह किए बिना पूरी बातचीत का इतिहास देखना चाहता हूँ ताकि मैं ग्राहकों से दोहराने को कहे बिना सुसंगत, सूचित प्रतिक्रिया दे सकूँ।

स्वीकृति मानदंड:
- टाइमलाइन दृश्य सभी इंटरैक्शन कालानुक्रमिक दिखाता है
- हर इंटरैक्शन चैनल, टाइमस्टैम्प और सामग्री दिखाता है
- ग्राहक प्रोफ़ाइल जनसांख्यिकी और खाता जानकारी दिखाती है
- पिछले मुद्दे और समाधान सुलभ हैं

[कुल 5-7 यूज़र स्टोरी के साथ जारी रखें...]

उदाहरण ट्रिगर वाक्य

  • "एक PRD लिखो।"
  • "इस फ़ीचर के लिए प्रोडक्ट स्पेक लिखो।"
  • "फ़ीचर विनिर्देश लिखो।"
  • "नए फ़ीचर के लिए आवश्यकता दस्तावेज़ लिखो।"

इस स्किल को अपने ब्राउज़र में चलाएँ: https://mohitagw15856.github.io/pm-claude-skills/skill/prd-template.html