Skill

Outcome Thinking — التفكير بالنتائج لا المخرجات

```

Install

npx claudepluginhub devmuslim/pdm-skills --plugin product-mindset

Tool Access

This skill uses the workspace's default tool permissions.

Preview

```

SKILL.md

Similar Skills

cache-components

Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.

cache-components

139.0k

claude-opus-4-5-migration

2 files

Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.

claude-opus-4-5-migration

83.2k

bmad-help

Analyzes BMad project state from catalog CSV, configs, artifacts, and query to recommend next skills or answer questions. Useful for help requests, 'what next', or starting BMad.

bmad-pro-skills

43.8k

Stats

Parent Repo Stars0

Parent Repo Forks0

Last CommitMar 9, 2026

Actions

View Source View Plugin View on GitHub View README

Outcome Thinking — التفكير بالنتائج لا المخرجات

الفرق الذي يغير كل شيء

Output Thinking (ما يفعله معظم الفرق):
"أنجزنا 47 Story Point هذا Sprint"
"أطلقنا 3 Features الشهر الماضي"
"أغلقنا 120 Ticket هذا الربع"

Outcome Thinking (ما يجب أن يفكر به فريق المنتج):
"وقت تعديل العقد انخفض من 15 دقيقة إلى 3 دقائق"
"معدل الأخطاء في الإرسال انخفض 80%"
"المستخدمون يكملون العملية بدون الاتصال بـ Support"

إطار Outcome → Output → Activity

الخطأ الشائع: البناء بالعكس
Activity → Output → (يتمنون) Outcome

الصح: ابدأ من Outcome
Outcome → Output → Activity

مثال:
Outcome المطلوب:  تقليل وقت معالجة العقد 50%
Output المناسب:   صفحة تعديل سريعة + Auto-fill + Preview
Activity المطلوبة: بناء صفحة التعديل + Integration مع DB

السؤال الذي يوقف بناء الأشياء الخاطئة:
"إذا بنينا هذا بشكل مثالي، ما الذي سيتغير للمستخدم؟"

نموذج OKR للفريق التقني

Objective (الهدف النوعي):
"نجعل تجربة تعديل العقود سلسة وسريعة"

Key Results (النتائج القابلة للقياس):
KR1: وقت إكمال التعديل < 5 دقائق (من 15 حالياً)
KR2: معدل الأخطاء < 1% (من 8% حالياً)
KR3: 90% من المستخدمين يكملون بدون Support

Features المربوطة بـ KRs:
Feature A → تخدم KR1 + KR2
Feature B → تخدم KR2 فقط
Feature C → لا تخدم أي KR ← هل نبنيها الآن؟

أسئلة تحوّل العقلية

بدلاً من "متى تنتهي؟" → "ما الذي سيتغير للمستخدم؟"
بدلاً من "هل أغلقنا الـ Ticket؟" → "هل حللنا المشكلة؟"
بدلاً من "الـ Feature جاهزة" → "هل الـ Feature تعمل للمستخدم؟"
بدلاً من "Velocity = 45" → "ما قيمة الـ 45 Point للمستخدم؟"

كيف تُقنع الفريق بهذا التحول

لا تبيع الفلسفة — بيع الألم المحلول.

مثال حقيقي يقنع:
"بنينا الـ Feature X في Sprint 5.
طلقناها. لم يستخدمها أحد.
لو كنا سألنا 'لماذا يحتاجها المستخدم؟' قبل البناء
كنا وفرنا أسبوعين من العمل."

هذه القصة تبني الاقتناع أكثر من أي Training.

مؤشرات نجاح Outcome Thinking في الفريق

🟢 علامات التحول:
- الفريق يسأل "لماذا نبني هذا؟" قبل التقدير
- Refinement يناقش القيمة لا التقنية فقط
- "لا نحتاج هذا الآن" يصبح قراراً مقبولاً
- الفريق يتابع نجاح الـ Features بعد الإطلاق

🔴 علامات لم يحدث التحول:
- الفريق يفخر بـ Velocity لا بالأثر
- لا أحد يعرف ماذا حدث للـ Feature بعد الإطلاق
- "هذا قرار PO" = لا مسؤولية مشتركة