لدى فريقك playbooks فريق Founders & PMs — الأنظمة المُجرَّبة لتحويل فكرة غامضة إلى spec، وبناء prototype قابل للنقر تقرّر به، وتلخيص الملاحظات، وكتابة التحديث الأسبوعي. تلك تُخبر الناس ماذا يفعلون. وهذا الدليل هو الطبقة التي تحتها: نموذج التشغيل الذي يُبقي قرارات المنتج سليمة وآمنة وقابلة للدفاع عنها وهم ينجزونها. وهو مكتوب لمؤسِّس أو رئيس منتج يُطلق Claude عبر مؤسسة منتج، لا لمجرّب منفرد — ويفترض تطبيق Claude Desktop، لا Terminal.
الخطأ الوحيد الذي يحوّل إطلاق ذكاء اصطناعي إلى حادثة ليس prompt سيّئًا — بل غياب قاعدة بشأن البيانات والادّعاءات ومن يتّخذ القرار. لا شيء مما يلي إجراءات ثقيلة. إنها حفنة الضوابط التي تتيح لفريقك التحرّك بسرعة لأن الحدود واضحة.
نموذج التشغيل: Claude يكتب المسودّات، وأنت تقرّر
ابدأ بالمبدأ الذي يتعلّق به كل شيء آخر: Claude يكتب المسودّات؛ والبشر يقرّرون. إنه أسرع junior PM ومحلّل عرفته يومًا — لا يكلّ في المسودّات الأولى والـ specs والتلخيص والـ prototypes ومذكّرات القرار — ولا حُكم لديه، ولا مساءلة، وله عادة في ذكر وقائع خاطئة وتقديرات هشّة بثقة تامة.
لذا فإن تقسيم العمل ثابت:
- Claude يتولّى عمل الصفر-إلى-مسودة: تحويل طلب غامض إلى spec بإصدار أوّل، وتلخيص تصدير ملاحظات إلى محاور، وإقامة prototype قابل للنقر تتفاعل معه، وكتابة مسودّة مذكّرة القرار، ووضع مخطّط سرد الـ board، وقراءة الـ codebase لديك وشرحه بلغة واضحة.
- الشخص يتولّى القرار: تحديد النطاق، وموازنة المفاضلات، واتّخاذ القرار، وملكية الـ roadmap، والضغط على النشر.
مؤسسة المنتج التي تستوعب هذا تنال السرعة دون المخاطرة. والتي تنساه تنشر spec لم يحدّد أحد نطاقه، أو تأخذ prototype واثقًا إلى عميل كأنه حقيقي. الـ playbooks كلها مبنية حول هذا الخط — توصلك إلى مسودّة قوية بسرعة ثم تُعيد إليك الحُكم عن قصد، لأن النطاق والأولويات هما بالضبط ما لا تستطيع أداةٌ أن تملكه.
ما الآمن مشاركته — وما ليس كذلك
على Desktop، المجلد هو الحدّ — لا يرى Claude إلا ما تفتحه — ونافذة Ask permissions تسأل قبل كل قراءة. وهذا يجعل قاعدة البيانات سهلة الصياغة وسهلة الاتّباع:
- آمن للمشاركة: الـ specs ووثائق الـ PRD، والمواد العلنية للسوق والمنافسين، ووثائق المنتج وملاحظات التصميم، ومقاييس المنتج الإجمالية (التفعيل، والاحتفاظ، ومعدّلات الـ funnel)، والـ codebase الخاص بك للفهم بقراءة فقط.
- أبقِها في مساحة عمل معتمدة: الـ cap table، والبيانات المالية والإيرادات غير المعلنة، وبيانات الـ PII للعملاء وقوائمهم، وأي شيء تحت NDA أو حظر نشر، ومواد الـ board.
عادتان تجعلان هذا تلقائيًا. أولًا، أدخِل ما تحتاجه المهمة فقط — تصدير مقاييس لنقاش roadmap يمكن تجريده إلى إجماليّات قبل أن يصل إلى المحادثة أصلًا؛ وملف ملاحظات يمكن نزع الأسماء والبُرُد الإلكترونية منه قبل التلخيص. ثانيًا، حين يحمل ملف بياناتٍ شخصية أو سرّية بالفعل، أبقِ المهمة كلها داخل مساحة العمل التي اعتمدتها شركتك لتلك البيانات، لا في محادثة عامة. وثمّة سطر خاص بالمنتج يستحق أن يُقال صراحةً: الـ prototype شيء قابل للرمي، لا production أبدًا — قراءة Claude للـ repo لديك كي يفهمه آمنة؛ أما معاملة أي شيء يولّده كـ code قابل للشحن فهو الخطأ الذي يجب تصميمه خارج العملية. كلٌّ من playbook اقرأ الـ codebase وتلخيص الملاحظات ينبّه إلى هذا عند الخطوة التي يهمّ فيها بالضبط.
بوّابة القرار والإطلاق
أسرع طريقة لتفقد الثقة التي تبنيها هي أن تدع السرعة تتخطّى من يملكون القرار. لذا ضَع بوّابة واحدة بين المسودّة والقرار، واجعلها صريحة — هذا هو نظير اعتماد العلامة والمراجعة القانونية في التسويق:
- الـ spec مسودّة تملكها أنت. Claude يكتب الـ user stories والـ edge cases وخط ما-هو-خارج-النطاق؛ وأنت تحدّد النطاق وتقبله. الـ spec غير المقبول نقطة بداية، لا التزام.
- الـ prototype للتفاعل معه، لا للشحن أبدًا. انقره، واشعر بالتدفّق، واقتل الفكرة بثمن زهيد إن كانت خاطئة — ثم سلّم البناء الحقيقي إلى الهندسة. هو دليل لقرار، لا ناتج القرار.
- الهندسة تملك البناء والتقدير. يستطيع Claude أن يرسم ما ستمسّه feature؛ أما الفريق الذي يشحنها فيملك الجدوى والرقم. الـ spec يكون «جاهزًا» حين يقرؤه مهندس، لا حين ينتهي Claude من كتابته.
- تحقّق من كل رقم وادّعاء يصل إلى عميل أو الفريق أو board. سيذكر Claude مقياسًا أو حجم سوق أو واقعةً عن منافس بثقة سواء أكانت صحيحة أم لا، وأنت المتحقّق من الوقائع قبل أن تغادر الغرفة.
هذه ليست بيروقراطية مُلصقة من الخارج — بل خطوة واحدة مُسمّاة في سير العمل. playbookا من الفكرة إلى الـ spec والـ prototype لاتّخاذ القرار يوجّهان العمل إلى نقطة يقبله فيها إنسان؛ وplaybook مذكّرة القرار مبنيٌّ ليُنتج شيئًا تستطيع الدفاع عنه، بالمفاضلات وأكبر مخاطرة في كل خيار على الطاولة — لأن ما يؤذي على نطاق roadmap هو قرار لا مالك له، لا قرار بطيء.
من يملك ماذا (RACI خفيف)
السرعة تموت في الغموض حول من يقرّر. لا تحتاج إلى مصفوفة RACI رسمية — تحتاج إلى أربعة أدوار مُسمّاة لأي قطعة عمل:
- يكتب المسودّة — الـ PM الذي يشغّل الـ playbook مع Claude.
- يراجع — الهندسة تملك الجدوى والتقدير؛ والخبير المختصّ يملك الوقائع (المحلّل على مقياس، والمالية على رقم، والجهة القانونية على ادّعاء).
- يقرّر — المؤسِّس أو الـ PM الذي يملك النطاق والأولويات ويستطيع أن يقول نعم.
- ينشر — شخص يملك النتيجة، ويضغط على النشر، ويستطيع أن يجيب عنها.
المقصد أن Claude ليس أيًّا من هذه الأربعة أبدًا. إنه الأداة التي يستخدمها دور «يكتب المسودّة». اكتب هذه الأسماء الأربعة مرة واحدة لكل مسار عمل — feature، أو ربع، أو دورة الـ board — فتختفي معظم حالات الطوارئ من نوع «من اعتمد هذا النطاق؟» قبل أن تبدأ.
العمل بلغتين: العربية والإنجليزية
لمؤسسة منتج في منطقة الشرق الأوسط وشمال إفريقيا، ثنائية اللغة ليست خطوة ترجمة تُلصق في النهاية — بل مسار متوازٍ، وفي هذه المنطقة علامةُ مصداقية. والقاعدة التي تهمّ: كيّف، لا تترجم.
- وثائق المنتج والنصوص الموجَّهة للعميل تنال سجلًّا عربيًا حقيقيًا، لا ترجمة آلية. الـ onboarding، والنصوص داخل المنتج، وملاحظات الإصدار، ومحتوى المساعدة ينبغي أن تُقرأ كأن كاتب منتج أصيلًا كتبها — فالعربية تحمل رسميّتها وإيقاعها وأعرافها الخاصة التي تطمسها ترجمةٌ حرفية للإنجليزية.
- قرّر وراجع باللغة التي يفكّر بها صاحب المصلحة. مذكّرة القرار أو سرد الـ board الموجَّه لجمهور يقرأ العربية أولًا يُكتب ويُختبَر بالعربية، لا أن يُكتب بالإنجليزية ويُحوَّل في اللحظة الأخيرة.
- البوّابة نفسها، باللغتين. الـ specs والنصوص العربية تجتاز مراجعة النطاق والوقائع نفسها التي يجتازها الإنجليزي — والامتثال الإقليمي ضمنها. لا تدع اللغة الثانية تتخطّى الاعتماد لأن لا أحد في سلسلة الموافقة يقرؤها؛ ابحث عن شخص يقرؤها.
حين تُعامَل هكذا، تكون العربية نِدًّا من الدرجة الأولى للإنجليزية عبر منتجك، لا فكرةً لاحقة — وهذا، في هذه المنطقة، هو الفرق بين منتج يبدو محليًا وآخر يُقرأ مترجَمًا.
مسار القدرات: من الأسس إلى التنسيق
الـ playbooks مرتّبة على شكل مسار متدرّج، لا قائمة مسطّحة، لأن المتأخّرة منها تعتمد فعلًا على المتقدّمة. شغّل فريقًا عبرها بالترتيب:
- المرحلة 1 — الأسس. ابنِ الـ context القابل لإعادة الاستخدام الذي يرثه كل شيء: وثيقة product context يستطيع Claude استخدامها فعلًا، وقراءتك لـالمشهد السوقي، والقدرة على قراءة الـ codebase الخاص بك بلغة واضحة. تجاوزها وستبدأ كل spec ومذكّرة وخطة لاحقة من تخمين.
- المرحلة 2 — أنظمة قابلة للتكرار. حوّل الأسس إلى محرّكات أسبوعية: من الفكرة إلى الـ spec، والـ prototype لاتّخاذ القرار، وتلخيص الملاحظات، ومذكّرة القرار، وتحديث أصحاب المصلحة الأسبوعي.
- المرحلة 3 — التنسيق. شغّل اللحظات الكبيرة العابرة التي تجمع كل أساس ونظام معًا: من الـ feature إلى الـ roadmap، والتخطيط الربعي، وسرد الـ board.
على مركز فريق Founders & PMs يُعرض المسار مرحلةً مرحلة مع شريط تقدّم، ويستطيع فريقك تعليم كل playbook كمُنجَز وهم يمضون — فتتحوّل عبارة «نحن نطوّر مؤسسة المنتج على Claude» إلى رقم تراه فعلًا، لا أمنية. (يُتتبَّع التقدّم على جهاز كل شخص؛ وعرضٌ مشترك على مستوى المدير للفريق هو الخطوة التالية الطبيعية بعد أن تشغّل المسار.)
إطلاقه: خطة 30/60/90
لا تُطلق كل شيء للجميع في اليوم الأول — فهكذا تخبو الإطلاقات. درّجه بالطريقة نفسها التي يتدرّج بها المسار. وإليك القوس كاملًا في صورة checklist تستطيع نسخه إلى وثيقتك:
30/60/90 — إطلاق Claude عبر مؤسسة منتج
أول 30 يومًا — الأسس
- اختر 2–3 من المستعدّين عبر المنتج والفريق المؤسِّس.
- ابنِ وثيقتَي السجلّ المرجعي: product-context.md و market-landscape.md.
- اتّفقوا على قاعدة الصفحة الواحدة: ما الآمن مشاركته، ومن يعتمد النطاق والأرقام.
- يشغّل كل شخص أول playbook حقيقي من المرحلة 1 من البداية إلى النهاية.
الأيام 30–60 — أنظمة قابلة للتكرار
- ضع الأنظمة الأسبوعية على Claude: من الفكرة إلى الـ spec، وتلخيص الملاحظات،
ومذكّرة القرار، وتحديث أصحاب المصلحة الأسبوعي.
- التقط الـ prompts الناجحة في ملف CLAUDE.md مشترك كي تتراكم المكاسب.
- سمِّ الأدوار الأربعة لكل مسار عمل: يكتب المسودّة / يراجع / يقرّر / ينشر.
الأيام 60–90 — التنسيق
- شغّل دورة تخطيط ربعي وسرد board كاملة عبر النظام.
- سمِّ الـ RACI لكل مسار عمل (feature، ربع، board) مع تدفّق العمل.
- راجع مسار القدرات: من أتمّ أي مرحلة، وأين الفجوات،
وأي المقاعد تُضيف تاليًا.الدافع إلى فرضه على الجميع دفعة واحدة هو الدافع الذي ينبغي مقاومته. التبنّي عادة تنتشر، لا مفتاح تقلبه. ابدأ بضعة أشخاص على الأسس، وامنحهم وثيقتَي المصدر وقاعدة من صفحة واحدة، ودعهم يلتقطون ما ينجح — وبحلول اليوم التسعين يكون لديك مؤسسة منتج شغّلت ربعًا حقيقيًا ودورة board عبر النظام، ومسار تستطيع الإشارة إليه، والدليل الذي تحتاجه لتوسيعه. playbook إطلاق الفريق العام يتعمّق أكثر في الآليات العابرة للأدوار حين تكون مستعدًا لتوسيعه إلى ما بعد الفريق المؤسِّس.