Auto-sync Thu Aug 6 11:31:13 +08 2026
This commit is contained in:
Hermes Bot
@@ -0,0 +1,138 @@
|
||||
**FATWA #1: THE PROBLEM STATEMENT — WHAT PROBLEM ARE WE SOLVING?**
|
||||
*Maqsad: Hifz al-Aql (Preservation of Mind/Clarity) → Jobs-to-be-Done*
|
||||
|
||||
---
|
||||
|
||||
### 1. THE SCENARIO
|
||||
|
||||
You’re the Product Lead at a growing fintech startup. Your CEO bursts into your weekly sync: *“Why are we building this feature? The board wants to know. The team is spinning. Just give me a PRD by Friday.”* You open your notebook. The Mujtahid in you asks: *“What is the hukm? What is the maqsad?”* The Product Lead in you asks: *“What problem are we actually solving? Is this a symptom or a root cause? User pain or business pain? Known or unknown?”* You have three days to produce a problem statement that passes both the user test and the Maqasid test. The clock is ticking.
|
||||
|
||||
---
|
||||
|
||||
### 2. DISCOVERY (ISTIQSA‘)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
“Before you write a single line of a PRD, you must discover the real problem. I use the **Problem Quadrant**. Draw a 2x2.
|
||||
- **X-axis:** Symptom ↔ Root Cause
|
||||
- **Y-axis:** User Pain ↔ Business Pain
|
||||
|
||||
Place your CEO’s feature request somewhere in that quadrant. Most requests land in ‘Symptom + Business Pain’ — urgent but shallow. Your job is to push it toward ‘Root Cause + User Pain.’ That’s where durable solutions live.
|
||||
|
||||
Start with **Continuous Discovery**. This week, do three things:
|
||||
1. **Map the Opportunity Solution Tree** — Write the desired outcome at the top (e.g., ‘Increase user activation in first 7 days’). Below it, list opportunities (user needs, pains, desires). Don’t jump to solutions yet.
|
||||
2. **Conduct 3–5 user interviews** using **Jobs-to-be-Done** language: *“When you first signed up, what job were you hiring our app to do? What made you switch from your old tool?”*
|
||||
3. **Trace the symptom chain** — Keep asking *“Why?”* five times until you hit a root cause. If the CEO says *“Users aren’t completing onboarding,”* ask: *“Why? Because they get stuck on step 3. Why? Because the KYC form asks for too much data. Why? Because we copied a bank’s template. Why? Because we never tested with real users.”* Now you have a root cause.
|
||||
|
||||
**MUJTAHID:**
|
||||
“I call this **Istiqsa‘** — exhaustive investigation of the problem space. In Usul al-Fiqh, before issuing a fatwa, a mujtahid must first define the *wāqi‘* (reality). He does not rule on a vague question. He asks: *What is the precise nature of this case? What are its borders? What maslaha (benefit) or mafsada (harm) is at stake?*
|
||||
|
||||
Apply the **Maqasid lens** to your problem. The Maqsad here is **Hifz al-Aql** — preservation of mind and clarity. This means:
|
||||
- The user’s mind must not be burdened with confusion, unnecessary steps, or deceptive flows.
|
||||
- The product’s logic must align with the user’s mental model.
|
||||
- The problem statement itself must be clear and unambiguous — no vague language like *“improve engagement.”*
|
||||
|
||||
Ask: *What is the hukm of this feature? Is it obligatory (wajib) to solve this problem? Recommended (mandub)? Permissible (mubah)? Or is it merely a desire of the CEO?* A problem that harms the user’s mental clarity (e.g., dark patterns) is haram to build. A problem that enhances clarity is a priority.
|
||||
|
||||
Also, distinguish **symptom from root cause** using the **maqasid hierarchy**:
|
||||
- **Symptom** = surface disruption (e.g., low completion rate).
|
||||
- **Root cause** = deep misalignment with user’s innate needs (fitrah). The user’s fitrah seeks clarity, efficiency, and trust. If your KYC form violates that, the root cause is a design that does not respect Hifz al-Aql.
|
||||
|
||||
Your discovery is incomplete until you can state the problem in one crisp sentence that answers: *What job is the user trying to do, and what prevents them from doing it with clarity?*”
|
||||
|
||||
---
|
||||
|
||||
### 3. EVIDENCE (ISTIDLAL)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
“Now gather **daleel** — evidence. In product, we have two types: **quantitative** (metrics, analytics, logs) and **qualitative** (interviews, observation, support tickets). Both are necessary. But they are not equal in weight. Here’s how I prioritize:
|
||||
|
||||
1. **Quantitative daleel** — Look at your funnel. Where is the drop-off? What’s the baseline? If 70% of users abandon onboarding at step 3, that’s a strong signal. But numbers alone don’t tell you *why*.
|
||||
2. **Qualitative daleel** — User interviews, session recordings, support chats. Listen for the JTBD language: *“I just wanted to send money quickly. I didn’t expect to fill out my entire life story.”*
|
||||
3. **Triangulate** — If the data says ‘low completion’ and interviews say ‘too much friction,’ you have convergent evidence. If they conflict, dig deeper.
|
||||
|
||||
Avoid **anecdote as daleel**. One CEO’s hunch is not data. One user complaint is not a trend. Require at least three independent sources before calling something a root cause. Use the **Opportunity Solution Tree**: attach evidence to each opportunity node. If an opportunity has no evidence, prune it.
|
||||
|
||||
**MUJTAHID:**
|
||||
“In Usul al-Fiqh, evidence is graded. We have:
|
||||
|
||||
- **Qaṭ‘ī al-thubūt wa qaṭ‘ī al-dalāla** (definitive transmission and definitive meaning) — e.g., a clear verse from Qur’an. In product, this is like a log that *proves* 100% of users hit an error. Very rare but powerful.
|
||||
- **Ẓannī al-thubūt wa ẓannī al-dalāla** (probable in both) — most product data falls here. It’s probable, not certain. You must treat it as a hypothesis, not a fact.
|
||||
- **Istishāb** (presumption of continuity) — assume the current state remains until proven otherwise. If you don’t have evidence that users hate the KYC form, presume they accept it. The burden of proof is on the one claiming change.
|
||||
|
||||
Your evidence must be **maqṣūd** (relevant) and **kāfī** (sufficient). One user interview is not sufficient — that’s like one witness in a court. You need multiple witnesses (users) whose testimony converges.
|
||||
|
||||
Ask: *Is this evidence ‘ānim* (general) or *khāṣṣ* (specific)? A general metric like ‘NPS dropped’ is too broad. Specific evidence like ‘85% of users who abandon onboarding do so at the document upload step’ is actionable.
|
||||
|
||||
Finally, distinguish between **‘illa** (effective cause) and **sabab** (mere occasion). The *sabab* is the trigger (e.g., user clicks ‘Cancel’). The *‘illa* is the underlying reason (e.g., form asks for photo ID but user doesn’t have one handy). The *‘illa* is what you must address. That is the root cause.”
|
||||
|
||||
---
|
||||
|
||||
### 4. SHURA
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
“Shura — consultation — is not a rubber stamp. It’s a structured process to surface blind spots. Call a **cross-functional sync** with engineering, design, data, and customer support. But don’t just ask *“What do you think?”* Use a **stakeholder map**:
|
||||
- Who owns the outcome? (PM, execs)
|
||||
- Who owns the output? (engineers, designers)
|
||||
- Who has context? (support, sales)
|
||||
- Who is affected? (users, compliance)
|
||||
|
||||
For each stakeholder, ask: *“What evidence do you have that this problem exists? What evidence refutes it?”* Record dissent explicitly. If the engineer says *“This problem is not real, users just need better education,”* write it down. That hypothesis can be tested.
|
||||
|
||||
Then conduct **user shura**: run a small co-creation session with 3–5 users. Show them the draft problem statement: *“We believe users abandon onboarding because the KYC form is too long. Does that match your experience?”* Let them correct you. Their voice is the strongest daleel.
|
||||
|
||||
**MUJTAHID:**
|
||||
“Shura in Islam is not majority vote. It is a method to reach the best *ijtihād*. The Prophet ﷺ consulted his companions even when he knew the answer — to train them and to surface hidden wisdom.
|
||||
|
||||
Your shura must have **ādāb** (etiquettes):
|
||||
- **Ikhlāṣ** (sincerity) — consult to find the truth, not to confirm your bias.
|
||||
- **Inṣāf** (fairness) — give each stakeholder’s evidence its due weight. The support rep who hears complaints daily has **ẓannī** evidence that may outweigh the CEO’s hunch.
|
||||
- **Tadwīn** (recording) — document every opinion, especially dissenting ones. This is your *majlis al-shura* record.
|
||||
|
||||
Weight the input using **marātib al-ijtihād**:
|
||||
- A stakeholder with direct user contact (support, UX researcher) → higher weight for qualitative evidence.
|
||||
- A stakeholder with system-level data (data scientist) → higher weight for quantitative evidence.
|
||||
- A stakeholder with strategic vision (CEO) → weight only after user evidence is clear.
|
||||
|
||||
If there is **ikhtilāf** (disagreement), do not suppress it. Mark it as a **riwāya** (variant opinion) and test it in the next discovery cycle. The goal is not unanimity — it is clarity.”
|
||||
|
||||
---
|
||||
|
||||
*End of Part 1. Continue with Fatwa, Protocol, and Muhasaba in the next section.*## THE FATWA (HUKM)
|
||||
|
||||
**HUKM:** We will frame the problem as *“Customers abandon the checkout flow because they cannot predict the total cost before entering payment details”* — and we will **not** build a “guest checkout” or “one-click purchase” until we validate that this root cause is solved.
|
||||
|
||||
**DALEEL:** Continuous discovery interviews (n=23) showed 78% of drop‑offs occur on the payment screen after unexpected fees appear; quantitative funnel analysis confirms a 34% exit rate at that step. This is a **zanni** (probable) but actionable signal—the pain is real (Hifz al‑Mal: loss of money through surprise fees; Hifz al‑Aql: cognitive load of uncertainty). The *maqsad* of clarity (al‑Aql) is violated by hidden costs, creating a “job” of *predicting total cost before committing*.
|
||||
|
||||
**MAQSAD:** Hifz al‑Aql (preservation of clarity and sound decision‑making) — the user’s mind is burdened by ambiguity. The JTBD is: *“Help me know the exact price before I decide to pay.”* Serving this maqsad also indirectly protects Hifz al‑Mal (avoiding financial regret) and Hifz al‑Nasl (trust in the transaction for future use).
|
||||
|
||||
**SHURUT:**
|
||||
- **Condition 1:** The solution must surface the *all‑inclusive* total (tax, shipping, discounts) before the user enters any payment information.
|
||||
- **Condition 2:** Feature must ship with an A/B test measuring checkout completion rate (North Star: +15% relative improvement within 2 weeks).
|
||||
- **Condition 3:** Rollout initially to 10% of traffic; if confidence interval for detriment exceeds 5%, pause and revert.
|
||||
- **Condition 4:** Legal must approve fee‑transparency wording to avoid false claims (Hifz al‑Din: honesty in business).
|
||||
|
||||
**MUNKATHIRAT (Nullifiers):**
|
||||
- If after 2 weeks the checkout completion rate does not improve by at least 5% (statistically significant), the fatwa is revoked and we return to discovery.
|
||||
- If user interviews reveal the real job is *speed*, not *clarity* (e.g., they want one‑click checkout even with surprise fees), then this problem statement is invalid and we pivot.
|
||||
- If engineering cost exceeds 4 sprints, the fatwa is nullified because the *maslaha* does not outweigh the delay to other work.
|
||||
|
||||
---
|
||||
|
||||
## THE PROTOCOL
|
||||
|
||||
**STEP 1: Prototype the “total cost preview” on the cart page.**
|
||||
This sprint: design a single‑screen mockup that shows the final price with a breakdown (subtotal + tax + shipping). Test with 5 users via moderated interviews. *Deadline: End of Week 1.*
|
||||
|
||||
**STEP 2: Validate the JTBD with a concierge MVP.**
|
||||
For 2 days, manually message every user who reaches the payment screen with a pop‑up: “Your total will be $X. Continue?” Measure how many complete vs. abandon. *Deadline: Week 2, Days 1–2.*
|
||||
|
||||
**STEP 3: Decide to build or kill.**
|
||||
Based on Step 2 data (if >70% of users who see the total proceed), write the engineering ticket for the full feature. If not, return to discovery and reframe the problem. *Deadline: Week 2, End of Day 5.*
|
||||
|
||||
---
|
||||
|
||||
## MUHASABA (RETROSPECTIVE)
|
||||
|
||||
**What would we have missed if we had jumped straight to building “guest checkout” without first isolating the real cost‑clarity job?**
|
||||
|
||||
This question forces the team to confront the most common product fallacy: mistaking a symptom (low conversion) for a root cause (unexpected fees). If we had shipped guest checkout, we might have seen a small bump from reduced friction—but the core trust issue would remain, and churn would resurface. The *muhasaba* must ask: *Did we truly distinguish the user’s “job” from our own assumptions?* If the answer is “no,” then next time we need to spend more time in the Problem Quadrant before writing a single line of code.
|
||||
@@ -0,0 +1,100 @@
|
||||
**FATWA #1: THE PROBLEM STATEMENT — WHAT PROBLEM ARE WE SOLVING?**
|
||||
*Maqsad: Hifz al-Aql (Preservation of Mind/Clarity) → Jobs-to-be-Done*
|
||||
|
||||
---
|
||||
|
||||
### 1. THE SCENARIO
|
||||
|
||||
You’re the Product Lead at a growing fintech startup. Your CEO bursts into your weekly sync: *“Why are we building this feature? The board wants to know. The team is spinning. Just give me a PRD by Friday.”* You open your notebook. The Mujtahid in you asks: *“What is the hukm? What is the maqsad?”* The Product Lead in you asks: *“What problem are we actually solving? Is this a symptom or a root cause? User pain or business pain? Known or unknown?”* You have three days to produce a problem statement that passes both the user test and the Maqasid test. The clock is ticking.
|
||||
|
||||
---
|
||||
|
||||
### 2. DISCOVERY (ISTIQSA‘)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
“Before you write a single line of a PRD, you must discover the real problem. I use the **Problem Quadrant**. Draw a 2x2.
|
||||
- **X-axis:** Symptom ↔ Root Cause
|
||||
- **Y-axis:** User Pain ↔ Business Pain
|
||||
|
||||
Place your CEO’s feature request somewhere in that quadrant. Most requests land in ‘Symptom + Business Pain’ — urgent but shallow. Your job is to push it toward ‘Root Cause + User Pain.’ That’s where durable solutions live.
|
||||
|
||||
Start with **Continuous Discovery**. This week, do three things:
|
||||
1. **Map the Opportunity Solution Tree** — Write the desired outcome at the top (e.g., ‘Increase user activation in first 7 days’). Below it, list opportunities (user needs, pains, desires). Don’t jump to solutions yet.
|
||||
2. **Conduct 3–5 user interviews** using **Jobs-to-be-Done** language: *“When you first signed up, what job were you hiring our app to do? What made you switch from your old tool?”*
|
||||
3. **Trace the symptom chain** — Keep asking *“Why?”* five times until you hit a root cause. If the CEO says *“Users aren’t completing onboarding,”* ask: *“Why? Because they get stuck on step 3. Why? Because the KYC form asks for too much data. Why? Because we copied a bank’s template. Why? Because we never tested with real users.”* Now you have a root cause.
|
||||
|
||||
**MUJTAHID:**
|
||||
“I call this **Istiqsa‘** — exhaustive investigation of the problem space. In Usul al-Fiqh, before issuing a fatwa, a mujtahid must first define the *wāqi‘* (reality). He does not rule on a vague question. He asks: *What is the precise nature of this case? What are its borders? What maslaha (benefit) or mafsada (harm) is at stake?*
|
||||
|
||||
Apply the **Maqasid lens** to your problem. The Maqsad here is **Hifz al-Aql** — preservation of mind and clarity. This means:
|
||||
- The user’s mind must not be burdened with confusion, unnecessary steps, or deceptive flows.
|
||||
- The product’s logic must align with the user’s mental model.
|
||||
- The problem statement itself must be clear and unambiguous — no vague language like *“improve engagement.”*
|
||||
|
||||
Ask: *What is the hukm of this feature? Is it obligatory (wajib) to solve this problem? Recommended (mandub)? Permissible (mubah)? Or is it merely a desire of the CEO?* A problem that harms the user’s mental clarity (e.g., dark patterns) is haram to build. A problem that enhances clarity is a priority.
|
||||
|
||||
Also, distinguish **symptom from root cause** using the **maqasid hierarchy**:
|
||||
- **Symptom** = surface disruption (e.g., low completion rate).
|
||||
- **Root cause** = deep misalignment with user’s innate needs (fitrah). The user’s fitrah seeks clarity, efficiency, and trust. If your KYC form violates that, the root cause is a design that does not respect Hifz al-Aql.
|
||||
|
||||
Your discovery is incomplete until you can state the problem in one crisp sentence that answers: *What job is the user trying to do, and what prevents them from doing it with clarity?*”
|
||||
|
||||
---
|
||||
|
||||
### 3. EVIDENCE (ISTIDLAL)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
“Now gather **daleel** — evidence. In product, we have two types: **quantitative** (metrics, analytics, logs) and **qualitative** (interviews, observation, support tickets). Both are necessary. But they are not equal in weight. Here’s how I prioritize:
|
||||
|
||||
1. **Quantitative daleel** — Look at your funnel. Where is the drop-off? What’s the baseline? If 70% of users abandon onboarding at step 3, that’s a strong signal. But numbers alone don’t tell you *why*.
|
||||
2. **Qualitative daleel** — User interviews, session recordings, support chats. Listen for the JTBD language: *“I just wanted to send money quickly. I didn’t expect to fill out my entire life story.”*
|
||||
3. **Triangulate** — If the data says ‘low completion’ and interviews say ‘too much friction,’ you have convergent evidence. If they conflict, dig deeper.
|
||||
|
||||
Avoid **anecdote as daleel**. One CEO’s hunch is not data. One user complaint is not a trend. Require at least three independent sources before calling something a root cause. Use the **Opportunity Solution Tree**: attach evidence to each opportunity node. If an opportunity has no evidence, prune it.
|
||||
|
||||
**MUJTAHID:**
|
||||
“In Usul al-Fiqh, evidence is graded. We have:
|
||||
|
||||
- **Qaṭ‘ī al-thubūt wa qaṭ‘ī al-dalāla** (definitive transmission and definitive meaning) — e.g., a clear verse from Qur’an. In product, this is like a log that *proves* 100% of users hit an error. Very rare but powerful.
|
||||
- **Ẓannī al-thubūt wa ẓannī al-dalāla** (probable in both) — most product data falls here. It’s probable, not certain. You must treat it as a hypothesis, not a fact.
|
||||
- **Istishāb** (presumption of continuity) — assume the current state remains until proven otherwise. If you don’t have evidence that users hate the KYC form, presume they accept it. The burden of proof is on the one claiming change.
|
||||
|
||||
Your evidence must be **maqṣūd** (relevant) and **kāfī** (sufficient). One user interview is not sufficient — that’s like one witness in a court. You need multiple witnesses (users) whose testimony converges.
|
||||
|
||||
Ask: *Is this evidence ‘ānim* (general) or *khāṣṣ* (specific)? A general metric like ‘NPS dropped’ is too broad. Specific evidence like ‘85% of users who abandon onboarding do so at the document upload step’ is actionable.
|
||||
|
||||
Finally, distinguish between **‘illa** (effective cause) and **sabab** (mere occasion). The *sabab* is the trigger (e.g., user clicks ‘Cancel’). The *‘illa* is the underlying reason (e.g., form asks for photo ID but user doesn’t have one handy). The *‘illa* is what you must address. That is the root cause.”
|
||||
|
||||
---
|
||||
|
||||
### 4. SHURA
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
“Shura — consultation — is not a rubber stamp. It’s a structured process to surface blind spots. Call a **cross-functional sync** with engineering, design, data, and customer support. But don’t just ask *“What do you think?”* Use a **stakeholder map**:
|
||||
- Who owns the outcome? (PM, execs)
|
||||
- Who owns the output? (engineers, designers)
|
||||
- Who has context? (support, sales)
|
||||
- Who is affected? (users, compliance)
|
||||
|
||||
For each stakeholder, ask: *“What evidence do you have that this problem exists? What evidence refutes it?”* Record dissent explicitly. If the engineer says *“This problem is not real, users just need better education,”* write it down. That hypothesis can be tested.
|
||||
|
||||
Then conduct **user shura**: run a small co-creation session with 3–5 users. Show them the draft problem statement: *“We believe users abandon onboarding because the KYC form is too long. Does that match your experience?”* Let them correct you. Their voice is the strongest daleel.
|
||||
|
||||
**MUJTAHID:**
|
||||
“Shura in Islam is not majority vote. It is a method to reach the best *ijtihād*. The Prophet ﷺ consulted his companions even when he knew the answer — to train them and to surface hidden wisdom.
|
||||
|
||||
Your shura must have **ādāb** (etiquettes):
|
||||
- **Ikhlāṣ** (sincerity) — consult to find the truth, not to confirm your bias.
|
||||
- **Inṣāf** (fairness) — give each stakeholder’s evidence its due weight. The support rep who hears complaints daily has **ẓannī** evidence that may outweigh the CEO’s hunch.
|
||||
- **Tadwīn** (recording) — document every opinion, especially dissenting ones. This is your *majlis al-shura* record.
|
||||
|
||||
Weight the input using **marātib al-ijtihād**:
|
||||
- A stakeholder with direct user contact (support, UX researcher) → higher weight for qualitative evidence.
|
||||
- A stakeholder with system-level data (data scientist) → higher weight for quantitative evidence.
|
||||
- A stakeholder with strategic vision (CEO) → weight only after user evidence is clear.
|
||||
|
||||
If there is **ikhtilāf** (disagreement), do not suppress it. Mark it as a **riwāya** (variant opinion) and test it in the next discovery cycle. The goal is not unanimity — it is clarity.”
|
||||
|
||||
---
|
||||
|
||||
*End of Part 1. Continue with Fatwa, Protocol, and Muhasaba in the next section.*
|
||||
@@ -0,0 +1,39 @@
|
||||
## THE FATWA (HUKM)
|
||||
|
||||
**HUKM:** We will frame the problem as *“Customers abandon the checkout flow because they cannot predict the total cost before entering payment details”* — and we will **not** build a “guest checkout” or “one-click purchase” until we validate that this root cause is solved.
|
||||
|
||||
**DALEEL:** Continuous discovery interviews (n=23) showed 78% of drop‑offs occur on the payment screen after unexpected fees appear; quantitative funnel analysis confirms a 34% exit rate at that step. This is a **zanni** (probable) but actionable signal—the pain is real (Hifz al‑Mal: loss of money through surprise fees; Hifz al‑Aql: cognitive load of uncertainty). The *maqsad* of clarity (al‑Aql) is violated by hidden costs, creating a “job” of *predicting total cost before committing*.
|
||||
|
||||
**MAQSAD:** Hifz al‑Aql (preservation of clarity and sound decision‑making) — the user’s mind is burdened by ambiguity. The JTBD is: *“Help me know the exact price before I decide to pay.”* Serving this maqsad also indirectly protects Hifz al‑Mal (avoiding financial regret) and Hifz al‑Nasl (trust in the transaction for future use).
|
||||
|
||||
**SHURUT:**
|
||||
- **Condition 1:** The solution must surface the *all‑inclusive* total (tax, shipping, discounts) before the user enters any payment information.
|
||||
- **Condition 2:** Feature must ship with an A/B test measuring checkout completion rate (North Star: +15% relative improvement within 2 weeks).
|
||||
- **Condition 3:** Rollout initially to 10% of traffic; if confidence interval for detriment exceeds 5%, pause and revert.
|
||||
- **Condition 4:** Legal must approve fee‑transparency wording to avoid false claims (Hifz al‑Din: honesty in business).
|
||||
|
||||
**MUNKATHIRAT (Nullifiers):**
|
||||
- If after 2 weeks the checkout completion rate does not improve by at least 5% (statistically significant), the fatwa is revoked and we return to discovery.
|
||||
- If user interviews reveal the real job is *speed*, not *clarity* (e.g., they want one‑click checkout even with surprise fees), then this problem statement is invalid and we pivot.
|
||||
- If engineering cost exceeds 4 sprints, the fatwa is nullified because the *maslaha* does not outweigh the delay to other work.
|
||||
|
||||
---
|
||||
|
||||
## THE PROTOCOL
|
||||
|
||||
**STEP 1: Prototype the “total cost preview” on the cart page.**
|
||||
This sprint: design a single‑screen mockup that shows the final price with a breakdown (subtotal + tax + shipping). Test with 5 users via moderated interviews. *Deadline: End of Week 1.*
|
||||
|
||||
**STEP 2: Validate the JTBD with a concierge MVP.**
|
||||
For 2 days, manually message every user who reaches the payment screen with a pop‑up: “Your total will be $X. Continue?” Measure how many complete vs. abandon. *Deadline: Week 2, Days 1–2.*
|
||||
|
||||
**STEP 3: Decide to build or kill.**
|
||||
Based on Step 2 data (if >70% of users who see the total proceed), write the engineering ticket for the full feature. If not, return to discovery and reframe the problem. *Deadline: Week 2, End of Day 5.*
|
||||
|
||||
---
|
||||
|
||||
## MUHASABA (RETROSPECTIVE)
|
||||
|
||||
**What would we have missed if we had jumped straight to building “guest checkout” without first isolating the real cost‑clarity job?**
|
||||
|
||||
This question forces the team to confront the most common product fallacy: mistaking a symptom (low conversion) for a root cause (unexpected fees). If we had shipped guest checkout, we might have seen a small bump from reduced friction—but the core trust issue would remain, and churn would resurface. The *muhasaba* must ask: *Did we truly distinguish the user’s “job” from our own assumptions?* If the answer is “no,” then next time we need to spend more time in the Problem Quadrant before writing a single line of code.
|
||||
@@ -0,0 +1,148 @@
|
||||
# FATWA #2: Evidence Gathering — Continuous Discovery as Istiqsa'
|
||||
|
||||
**Maqsad:** Hifz al-Mal (Preservation of Wealth/Data) → Continuous Discovery Habits
|
||||
|
||||
---
|
||||
|
||||
## 1. THE SCENARIO
|
||||
|
||||
You're the Product Lead at a growing Islamic fintech startup. Your CEO walks into your desk and asks: "Why are we building this *waqf*-linked investment feature? I need one sentence."
|
||||
|
||||
You open your notebook. There's a blank page where your evidence should be. The Mujtahid inside you whispers: *What is the hukm? What is the maqsad? What is the daleel?* You have user stories, but no user evidence. You have OKRs, but no outcome data. You realize: you're building on assumptions, not discovery.
|
||||
|
||||
The CEO waits. You have two weeks before the next board meeting. You need a Decision Protocol — but first, you need **Istiqsa'**: thorough investigation.
|
||||
|
||||
---
|
||||
|
||||
## 2. DISCOVERY (ISTIQSA')
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Continuous Discovery is not a meeting. It's a habit. Every week, you talk to users. Every sprint, you map an Opportunity Solution Tree. You don't start with the feature — you start with the **opportunity**: the JTBD your users are trying to accomplish.
|
||||
|
||||
Draw a tree. The root is the **outcome** (e.g., "More users complete their first waqf investment"). The branches are **opportunities** (e.g., "Users don't trust the platform," "Users don't understand the Islamic contract," "Users need help choosing a waqf category"). Under each opportunity, list **solutions** (features, experiments). Under each solution, list **assumptions** — the hypotheses you need to test.
|
||||
|
||||
Your job is not to build the solution. Your job is to **validate the opportunity** first. Talk to six users this week. Ask: "Tell me about the last time you tried to make a waqf investment. What happened?" Listen for pain, fear, confusion. Map their story onto the tree.
|
||||
|
||||
**MUJTAHID:**
|
||||
In Usul al-Fiqh, *Istiqsa'* is exhaustive investigation to uncover the **hukm** (ruling) of a situation. A Mujtahid does not issue a fatwa until he has gathered sufficient evidence from the Qur'an, Sunnah, Ijma', and Qiyas. But what is "sufficient"? It depends on the **maqsad** (objective).
|
||||
|
||||
Here, the maqsad is **Hifz al-Mal** — preserving wealth. For a fintech product, wealth is both capital and **data**. Every assumption you hold is a liability. If you build a feature on false evidence, you waste user trust and company money. That is *israf* (waste) — prohibited in Islam (Qur'an 7:31).
|
||||
|
||||
Istiqsa' in product means you must investigate **four domains**: the user's context, the user's behavior, the user's stated needs, and the user's unstated fears. You cannot rely on one source. The Sahaba (RA) would travel weeks to verify a single hadith. Can you spend six user interviews to verify a feature?
|
||||
|
||||
**Apply Maqasid:**
|
||||
- **Hifz al-Din** (Faith): Does the feature align with Shariah?
|
||||
- **Hifz al-Nafs** (Life): Does it protect users from harm (e.g., risky investments)?
|
||||
- **Hifz al-Aql** (Intellect): Is the contract clear? Does the user understand?
|
||||
- **Hifz al-Mal** (Wealth): Does this feature preserve or waste user wealth?
|
||||
- **Hifz al-Nasl** (Lineage): Does it support long-term family financial stability?
|
||||
|
||||
Your discovery must cover all five. Continuous Discovery is Istiqsa' — systematic, thorough, and outcome-driven.
|
||||
|
||||
---
|
||||
|
||||
## 3. EVIDENCE (ISTIDLAL)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Evidence comes in four flavors. Draw a 2×2 grid. Horizontal axis: **Quantitative** (numbers) vs **Qualitative** (stories). Vertical axis: **Behavioral** (what they do) vs **Attitudinal** (what they say). Four quadrants:
|
||||
|
||||
| | Quantitative | Qualitative |
|
||||
|---|---|---|
|
||||
| **Behavioral** | Analytics (conversion rates, drop-off) | Usability tests, session recordings |
|
||||
| **Attitudinal** | Surveys (NPS, CSAT) | User interviews, focus groups |
|
||||
|
||||
Most teams live in the bottom-left: attitudinal-quantitative (surveys). But the strongest evidence comes from **behavioral data** — what people actually do, not what they say. A user tells you "I want a waqf investment feature" (attitudinal). But when you run an A/B test, only 3% click the CTA (behavioral). The behavioral evidence overrides the attitudinal.
|
||||
|
||||
**The Minimum Viable Evidence Rule:**
|
||||
You don't need 500 survey responses for a fatwa-level decision. But you do need **triangulation** — at least two different evidence types pointing in the same direction. For an MVP, you need behavioral-qualitative evidence (e.g., 3 usability sessions showing the same confusion pattern) plus quantitative-behavioral (e.g., analytics showing 40% drop-off at the same step).
|
||||
|
||||
**MUJTAHID:**
|
||||
In Usul, evidence (*daleel*) is classified by **certainty** (*qati'* vs *zanni*) and **source** (*thubut* vs *dalala*). A verse from the Qur'an is *qati' al-thubut* (certain transmission) but may be *zanni al-dalala* (ambiguous meaning). A weak hadith is *zanni al-thubut* but may be *qati' al-dalala* (clear meaning).
|
||||
|
||||
Apply this to product evidence:
|
||||
|
||||
| Product Evidence Type | Thubut (Reliability of Data) | Dalala (Clarity of Interpretation) |
|
||||
|---|---|---|
|
||||
| Analytics from your own tool | High (you control logging) | Varies (correlation ≠ causation) |
|
||||
| User interview quotes | Low (small sample, bias) | High (direct quotes are clear) |
|
||||
| A/B test result (p<0.05) | High (statistically significant) | Medium (depends on context) |
|
||||
| Competitor analysis | Low (they may be wrong) | Low (their features ≠ your users' needs) |
|
||||
|
||||
**Signal vs Noise:**
|
||||
A Mujtahid weighs evidence by *ta'adul wa tarjih* (balancing and preferring). If one user says "I love the feature" but analytics show 90% abandonment, the behavioral evidence outweighs. Similarly, if a hadith contradicts a stronger source, the stronger source prevails.
|
||||
|
||||
**Minimum Viable Evidence for a Product Fatwa:**
|
||||
You need:
|
||||
1. **At least one behavioral source** (analytics or usability test)
|
||||
2. **At least one qualitative source** (interview or observation)
|
||||
3. **Triangulation** — both sources point to the same opportunity or problem
|
||||
|
||||
If you only have attitudinal data (surveys, user "requests"), you have not yet performed Istiqsa'. You are building on *zann* (speculation), and the Prophet ﷺ warned against following conjecture (Qur'an 10:36).
|
||||
|
||||
---
|
||||
|
||||
## 4. SHURA
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Shura is not a committee that votes. It's a structured consultation with **stakeholders who have skin in the game**. Map your stakeholders: users, engineering, design, Shariah board, CEO, compliance. Each brings a different lens. Your job is to collect their input, but not to average it.
|
||||
|
||||
**The Shura Session Protocol:**
|
||||
1. Present the **Opportunity Solution Tree** — not the solution.
|
||||
2. Ask each stakeholder: "What evidence do you have that this opportunity is real?"
|
||||
3. Record all evidence in the four-quadrant grid.
|
||||
4. Weight by **proximity to the user** (engineers who never talk to users get lower weight).
|
||||
5. Document dissent — especially from the Shariah board or compliance.
|
||||
|
||||
**MUJTAHID:**
|
||||
Shura in Islam is not democracy; it is **seeking counsel from those with knowledge and experience**. The Prophet ﷺ consulted the Sahaba before Badr, even though he had revelation. Why? Because consultation uncovers blind spots and builds ownership.
|
||||
|
||||
A Mujtahid consults:
|
||||
- **Ahl al-'ilm** (those with knowledge): Shariah scholars for fatwa, domain experts for product.
|
||||
- **Ahl al-ra'y** (those with sound judgment): Senior engineers, experienced PMs.
|
||||
- **Ahl al-khibra** (those with direct experience): Users, customer support.
|
||||
|
||||
**Weighting Input:**
|
||||
- A Shariah board member's input on permissibility is *qati'* and cannot be overridden.
|
||||
- A user's input on usability is *zanni* but highly relevant.
|
||||
- A CEO's input on business strategy is *zanni* and must be balanced with user evidence.
|
||||
|
||||
**Recording Dissent:**
|
||||
In classical fiqh, *mukhalif* (dissenting opinions) are recorded even if not adopted. Why? Because later evidence may shift the balance. In product, record every "no" and "why" — it becomes a risk register for rollback triggers.
|
||||
|
||||
**End of Shura:**
|
||||
You now have a consolidated evidence map. You know what's known, unknown, and disputed. You are ready to issue a **Fatwa** — the product decision. That is our next chapter.## THE FATWA (HUKM)
|
||||
|
||||
**HUKM:** We will adopt a weekly, 90-minute Continuous Discovery habit using the Evidence Quadrant as our primary tool for all product decisions, with explicit guardrails to protect engineering resources and user trust.
|
||||
|
||||
**DALEEL:**
|
||||
**PRODUCT_LEAD:** Our quantitative data shows 35% of features shipped last quarter had <20% adoption. Qualitative interviews reveal users feel “features are built for someone else.” Behavioral logs confirm low repeat usage. Attitudinal surveys show Net Promoter Score dropping 12 points in 6 months. This quadrant reveals a systemic failure to validate before building.
|
||||
**MUJTAHID:** The daleel is mixed but sufficient to establish a hukm. The quantitative data is qat‘i al-thubut (certain in transmission) but zanni al-dalala (speculative in interpretation). Qualitative evidence is zanni but corroborated. Istidlal via qiyas: the Prophet ﷺ said, “The strong believer is better and more beloved to Allah than the weak believer” (Muslim). Strength here implies disciplined use of resources. Hifz al-Mal obligates us to spend development capital only on validated problems. The maslaha (public benefit) of a discovery habit is overwhelming.
|
||||
|
||||
**MAQSAD:** Hifz al-Mal (Preservation of Wealth) – we protect engineering hours, server costs, and data assets from waste. Also Hifz al-Aql (Intellect) – we avoid cognitive bias by forcing structured evidence review. Sub-maqsad: Hifz al-Din (Religion) – trustworthiness with stakeholder and user resources.
|
||||
|
||||
**SHURUT:**
|
||||
- Each session must review evidence from all four quadrants. No session is valid if one quadrant is empty (e.g., “we have no behavioral data yet” triggers an action item, not a pass).
|
||||
- At least one user must be interviewed or observed every two weeks. Recordings or notes become part of the evidence repository.
|
||||
- The session must produce a written “Evidence Summary” (one page) that updates the Opportunity Solution Tree and is shared with the broader team.
|
||||
- Rollback condition: If after 8 consecutive sessions we have zero changes to our product roadmap (i.e., no pivots or kills), we suspend the habit and audit whether the method is being applied correctly.
|
||||
|
||||
**MUNKATHIRAT:**
|
||||
- Making a major product decision (feature go/no-go, resource allocation >1 sprint) without referencing the Evidence Quadrant.
|
||||
- Cherry-picking evidence from only the quadrant that supports a pre-existing bias.
|
||||
- Allowing “we already know this” to skip a session – the habit itself is the nullifier if broken three times without written justification.
|
||||
|
||||
## THE PROTOCOL
|
||||
|
||||
**STEP 1: This week – Build your quadrant board.**
|
||||
Create a shared Miro or whiteboard with four labeled boxes: *Quantitative* (metrics, analytics), *Qualitative* (user interview quotes, verbatims), *Behavioral* (session recordings, heatmaps, funnel drop-offs), *Attitudinal* (surveys, NPS, satisfaction scores). Populate with every piece of evidence you currently have. Identify the emptiest quadrant – that is your first discovery task.
|
||||
|
||||
**STEP 2: This sprint – Run your first discovery session.**
|
||||
Block 90 minutes on Tuesday. Invite PM, designer, lead engineer, and one rotating team member. Objective: Review each quadrant, list top 3 opportunities, and for each opportunity write a “What would have to be true?” statement. End with one decision: continue, pivot, or kill the current top feature candidate.
|
||||
|
||||
**STEP 3: Next 30 days – Build the habit and measure.**
|
||||
After 4 sessions, conduct a mini-muhasaba: How many decisions changed because of evidence? What quadrant gave us the most leverage? If no decisions changed, escalate to the rollback condition. If decisions improved, codify the session as a team ritual.
|
||||
|
||||
## MUHASABA (RETROSPECTIVE)
|
||||
|
||||
**What evidence are we most afraid to collect, and what does that fear tell us about our willingness to protect our users’ and company’s wealth?**
|
||||
The uncomfortable truth: we often avoid behavioral data because it might prove our assumptions wrong. Hifz al-Mal demands we seek that discomfort – because a wrong feature costs far more than a bruised ego. If you can’t name the evidence you’re avoiding, you haven’t truly done Istiqsa’. Go back to Discovery.
|
||||
@@ -0,0 +1,113 @@
|
||||
# FATWA #2: Evidence Gathering — Continuous Discovery as Istiqsa'
|
||||
|
||||
**Maqsad:** Hifz al-Mal (Preservation of Wealth/Data) → Continuous Discovery Habits
|
||||
|
||||
---
|
||||
|
||||
## 1. THE SCENARIO
|
||||
|
||||
You're the Product Lead at a growing Islamic fintech startup. Your CEO walks into your desk and asks: "Why are we building this *waqf*-linked investment feature? I need one sentence."
|
||||
|
||||
You open your notebook. There's a blank page where your evidence should be. The Mujtahid inside you whispers: *What is the hukm? What is the maqsad? What is the daleel?* You have user stories, but no user evidence. You have OKRs, but no outcome data. You realize: you're building on assumptions, not discovery.
|
||||
|
||||
The CEO waits. You have two weeks before the next board meeting. You need a Decision Protocol — but first, you need **Istiqsa'**: thorough investigation.
|
||||
|
||||
---
|
||||
|
||||
## 2. DISCOVERY (ISTIQSA')
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Continuous Discovery is not a meeting. It's a habit. Every week, you talk to users. Every sprint, you map an Opportunity Solution Tree. You don't start with the feature — you start with the **opportunity**: the JTBD your users are trying to accomplish.
|
||||
|
||||
Draw a tree. The root is the **outcome** (e.g., "More users complete their first waqf investment"). The branches are **opportunities** (e.g., "Users don't trust the platform," "Users don't understand the Islamic contract," "Users need help choosing a waqf category"). Under each opportunity, list **solutions** (features, experiments). Under each solution, list **assumptions** — the hypotheses you need to test.
|
||||
|
||||
Your job is not to build the solution. Your job is to **validate the opportunity** first. Talk to six users this week. Ask: "Tell me about the last time you tried to make a waqf investment. What happened?" Listen for pain, fear, confusion. Map their story onto the tree.
|
||||
|
||||
**MUJTAHID:**
|
||||
In Usul al-Fiqh, *Istiqsa'* is exhaustive investigation to uncover the **hukm** (ruling) of a situation. A Mujtahid does not issue a fatwa until he has gathered sufficient evidence from the Qur'an, Sunnah, Ijma', and Qiyas. But what is "sufficient"? It depends on the **maqsad** (objective).
|
||||
|
||||
Here, the maqsad is **Hifz al-Mal** — preserving wealth. For a fintech product, wealth is both capital and **data**. Every assumption you hold is a liability. If you build a feature on false evidence, you waste user trust and company money. That is *israf* (waste) — prohibited in Islam (Qur'an 7:31).
|
||||
|
||||
Istiqsa' in product means you must investigate **four domains**: the user's context, the user's behavior, the user's stated needs, and the user's unstated fears. You cannot rely on one source. The Sahaba (RA) would travel weeks to verify a single hadith. Can you spend six user interviews to verify a feature?
|
||||
|
||||
**Apply Maqasid:**
|
||||
- **Hifz al-Din** (Faith): Does the feature align with Shariah?
|
||||
- **Hifz al-Nafs** (Life): Does it protect users from harm (e.g., risky investments)?
|
||||
- **Hifz al-Aql** (Intellect): Is the contract clear? Does the user understand?
|
||||
- **Hifz al-Mal** (Wealth): Does this feature preserve or waste user wealth?
|
||||
- **Hifz al-Nasl** (Lineage): Does it support long-term family financial stability?
|
||||
|
||||
Your discovery must cover all five. Continuous Discovery is Istiqsa' — systematic, thorough, and outcome-driven.
|
||||
|
||||
---
|
||||
|
||||
## 3. EVIDENCE (ISTIDLAL)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Evidence comes in four flavors. Draw a 2×2 grid. Horizontal axis: **Quantitative** (numbers) vs **Qualitative** (stories). Vertical axis: **Behavioral** (what they do) vs **Attitudinal** (what they say). Four quadrants:
|
||||
|
||||
| | Quantitative | Qualitative |
|
||||
|---|---|---|
|
||||
| **Behavioral** | Analytics (conversion rates, drop-off) | Usability tests, session recordings |
|
||||
| **Attitudinal** | Surveys (NPS, CSAT) | User interviews, focus groups |
|
||||
|
||||
Most teams live in the bottom-left: attitudinal-quantitative (surveys). But the strongest evidence comes from **behavioral data** — what people actually do, not what they say. A user tells you "I want a waqf investment feature" (attitudinal). But when you run an A/B test, only 3% click the CTA (behavioral). The behavioral evidence overrides the attitudinal.
|
||||
|
||||
**The Minimum Viable Evidence Rule:**
|
||||
You don't need 500 survey responses for a fatwa-level decision. But you do need **triangulation** — at least two different evidence types pointing in the same direction. For an MVP, you need behavioral-qualitative evidence (e.g., 3 usability sessions showing the same confusion pattern) plus quantitative-behavioral (e.g., analytics showing 40% drop-off at the same step).
|
||||
|
||||
**MUJTAHID:**
|
||||
In Usul, evidence (*daleel*) is classified by **certainty** (*qati'* vs *zanni*) and **source** (*thubut* vs *dalala*). A verse from the Qur'an is *qati' al-thubut* (certain transmission) but may be *zanni al-dalala* (ambiguous meaning). A weak hadith is *zanni al-thubut* but may be *qati' al-dalala* (clear meaning).
|
||||
|
||||
Apply this to product evidence:
|
||||
|
||||
| Product Evidence Type | Thubut (Reliability of Data) | Dalala (Clarity of Interpretation) |
|
||||
|---|---|---|
|
||||
| Analytics from your own tool | High (you control logging) | Varies (correlation ≠ causation) |
|
||||
| User interview quotes | Low (small sample, bias) | High (direct quotes are clear) |
|
||||
| A/B test result (p<0.05) | High (statistically significant) | Medium (depends on context) |
|
||||
| Competitor analysis | Low (they may be wrong) | Low (their features ≠ your users' needs) |
|
||||
|
||||
**Signal vs Noise:**
|
||||
A Mujtahid weighs evidence by *ta'adul wa tarjih* (balancing and preferring). If one user says "I love the feature" but analytics show 90% abandonment, the behavioral evidence outweighs. Similarly, if a hadith contradicts a stronger source, the stronger source prevails.
|
||||
|
||||
**Minimum Viable Evidence for a Product Fatwa:**
|
||||
You need:
|
||||
1. **At least one behavioral source** (analytics or usability test)
|
||||
2. **At least one qualitative source** (interview or observation)
|
||||
3. **Triangulation** — both sources point to the same opportunity or problem
|
||||
|
||||
If you only have attitudinal data (surveys, user "requests"), you have not yet performed Istiqsa'. You are building on *zann* (speculation), and the Prophet ﷺ warned against following conjecture (Qur'an 10:36).
|
||||
|
||||
---
|
||||
|
||||
## 4. SHURA
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Shura is not a committee that votes. It's a structured consultation with **stakeholders who have skin in the game**. Map your stakeholders: users, engineering, design, Shariah board, CEO, compliance. Each brings a different lens. Your job is to collect their input, but not to average it.
|
||||
|
||||
**The Shura Session Protocol:**
|
||||
1. Present the **Opportunity Solution Tree** — not the solution.
|
||||
2. Ask each stakeholder: "What evidence do you have that this opportunity is real?"
|
||||
3. Record all evidence in the four-quadrant grid.
|
||||
4. Weight by **proximity to the user** (engineers who never talk to users get lower weight).
|
||||
5. Document dissent — especially from the Shariah board or compliance.
|
||||
|
||||
**MUJTAHID:**
|
||||
Shura in Islam is not democracy; it is **seeking counsel from those with knowledge and experience**. The Prophet ﷺ consulted the Sahaba before Badr, even though he had revelation. Why? Because consultation uncovers blind spots and builds ownership.
|
||||
|
||||
A Mujtahid consults:
|
||||
- **Ahl al-'ilm** (those with knowledge): Shariah scholars for fatwa, domain experts for product.
|
||||
- **Ahl al-ra'y** (those with sound judgment): Senior engineers, experienced PMs.
|
||||
- **Ahl al-khibra** (those with direct experience): Users, customer support.
|
||||
|
||||
**Weighting Input:**
|
||||
- A Shariah board member's input on permissibility is *qati'* and cannot be overridden.
|
||||
- A user's input on usability is *zanni* but highly relevant.
|
||||
- A CEO's input on business strategy is *zanni* and must be balanced with user evidence.
|
||||
|
||||
**Recording Dissent:**
|
||||
In classical fiqh, *mukhalif* (dissenting opinions) are recorded even if not adopted. Why? Because later evidence may shift the balance. In product, record every "no" and "why" — it becomes a risk register for rollback triggers.
|
||||
|
||||
**End of Shura:**
|
||||
You now have a consolidated evidence map. You know what's known, unknown, and disputed. You are ready to issue a **Fatwa** — the product decision. That is our next chapter.
|
||||
@@ -0,0 +1,36 @@
|
||||
## THE FATWA (HUKM)
|
||||
|
||||
**HUKM:** We will adopt a weekly, 90-minute Continuous Discovery habit using the Evidence Quadrant as our primary tool for all product decisions, with explicit guardrails to protect engineering resources and user trust.
|
||||
|
||||
**DALEEL:**
|
||||
**PRODUCT_LEAD:** Our quantitative data shows 35% of features shipped last quarter had <20% adoption. Qualitative interviews reveal users feel “features are built for someone else.” Behavioral logs confirm low repeat usage. Attitudinal surveys show Net Promoter Score dropping 12 points in 6 months. This quadrant reveals a systemic failure to validate before building.
|
||||
**MUJTAHID:** The daleel is mixed but sufficient to establish a hukm. The quantitative data is qat‘i al-thubut (certain in transmission) but zanni al-dalala (speculative in interpretation). Qualitative evidence is zanni but corroborated. Istidlal via qiyas: the Prophet ﷺ said, “The strong believer is better and more beloved to Allah than the weak believer” (Muslim). Strength here implies disciplined use of resources. Hifz al-Mal obligates us to spend development capital only on validated problems. The maslaha (public benefit) of a discovery habit is overwhelming.
|
||||
|
||||
**MAQSAD:** Hifz al-Mal (Preservation of Wealth) – we protect engineering hours, server costs, and data assets from waste. Also Hifz al-Aql (Intellect) – we avoid cognitive bias by forcing structured evidence review. Sub-maqsad: Hifz al-Din (Religion) – trustworthiness with stakeholder and user resources.
|
||||
|
||||
**SHURUT:**
|
||||
- Each session must review evidence from all four quadrants. No session is valid if one quadrant is empty (e.g., “we have no behavioral data yet” triggers an action item, not a pass).
|
||||
- At least one user must be interviewed or observed every two weeks. Recordings or notes become part of the evidence repository.
|
||||
- The session must produce a written “Evidence Summary” (one page) that updates the Opportunity Solution Tree and is shared with the broader team.
|
||||
- Rollback condition: If after 8 consecutive sessions we have zero changes to our product roadmap (i.e., no pivots or kills), we suspend the habit and audit whether the method is being applied correctly.
|
||||
|
||||
**MUNKATHIRAT:**
|
||||
- Making a major product decision (feature go/no-go, resource allocation >1 sprint) without referencing the Evidence Quadrant.
|
||||
- Cherry-picking evidence from only the quadrant that supports a pre-existing bias.
|
||||
- Allowing “we already know this” to skip a session – the habit itself is the nullifier if broken three times without written justification.
|
||||
|
||||
## THE PROTOCOL
|
||||
|
||||
**STEP 1: This week – Build your quadrant board.**
|
||||
Create a shared Miro or whiteboard with four labeled boxes: *Quantitative* (metrics, analytics), *Qualitative* (user interview quotes, verbatims), *Behavioral* (session recordings, heatmaps, funnel drop-offs), *Attitudinal* (surveys, NPS, satisfaction scores). Populate with every piece of evidence you currently have. Identify the emptiest quadrant – that is your first discovery task.
|
||||
|
||||
**STEP 2: This sprint – Run your first discovery session.**
|
||||
Block 90 minutes on Tuesday. Invite PM, designer, lead engineer, and one rotating team member. Objective: Review each quadrant, list top 3 opportunities, and for each opportunity write a “What would have to be true?” statement. End with one decision: continue, pivot, or kill the current top feature candidate.
|
||||
|
||||
**STEP 3: Next 30 days – Build the habit and measure.**
|
||||
After 4 sessions, conduct a mini-muhasaba: How many decisions changed because of evidence? What quadrant gave us the most leverage? If no decisions changed, escalate to the rollback condition. If decisions improved, codify the session as a team ritual.
|
||||
|
||||
## MUHASABA (RETROSPECTIVE)
|
||||
|
||||
**What evidence are we most afraid to collect, and what does that fear tell us about our willingness to protect our users’ and company’s wealth?**
|
||||
The uncomfortable truth: we often avoid behavioral data because it might prove our assumptions wrong. Hifz al-Mal demands we seek that discomfort – because a wrong feature costs far more than a bruised ego. If you can’t name the evidence you’re avoiding, you haven’t truly done Istiqsa’. Go back to Discovery.
|
||||
@@ -0,0 +1,128 @@
|
||||
### FATWA #3: Stakeholder Consultation — Shura as Discovery
|
||||
|
||||
**MAQSAD:** Hifz al-Karama (Preservation of Dignity) → Stakeholder Voice
|
||||
**FRAMEWORK:** Shura Quadrant: Users / Team / Business / Regulators
|
||||
|
||||
---
|
||||
|
||||
## PART 1: SCENARIO → DISCOVERY → EVIDENCE → SHURA
|
||||
|
||||
---
|
||||
|
||||
### 1. THE SCENARIO
|
||||
|
||||
You’re the Product Lead at a growing fintech startup. Your CEO storms into your weekly sync: “Why are we building this feature? Who asked for it? I want a roadmap that *actually* reflects the business priorities.”
|
||||
|
||||
You open your notebook. The Mujtahid in you whispers: *What is the hukm of this consultation? What is the maqsad? Is this Shura or a performance?* You’ve done stakeholder interviews before. But they felt like checkboxes, not real discovery. The team built features that nobody used. The CEO’s voice dominated every product council. Users complained they were never heard. Regulators sent compliance warnings that caught you off guard. Something was broken. You need a methodology for consultation that is *valid* — not just polite listening but structured, evidence-weighted, dignity-preserving Shura.
|
||||
|
||||
---
|
||||
|
||||
### 2. DISCOVERY (ISTIQSA')
|
||||
|
||||
**PRODUCT_LEAD:** Let’s start with the real problem. The CEO’s question “Why are we building this?” is actually a symptom. The deeper problem: we have no systematic way to *discover* what stakeholders actually need. We’re jumping to solutions based on the loudest voice (usually the CEO or the highest-paying customer). That’s not discovery; that’s guessing.
|
||||
|
||||
I use the Opportunity Solution Tree. Draw it: On the left, your desired outcome (e.g., “Increase active user retention by 20%”). Then branch into *opportunities* — problems, pains, desires from users. Then branch into *solution ideas*. Then *experiments*. The key is that every branch comes from user evidence, not executive intuition.
|
||||
|
||||
In your fintech case, start with user interviews. Ask: “What’s the hardest part of managing your money right now?” Not “What feature do you want?” That’s JTBD: people hire your product to get a job done. The job might be “avoid late fees” or “save for Hajj without temptation.” Your CEO might think the job is “more analytics dashboards.” But the user’s job is different.
|
||||
|
||||
Map all stakeholder groups: Users (retail customers), Team (engineers, designers), Business (CEO, sales, finance), Regulators (Sharia board, central bank). Each has a different job. Each must be heard *in their own domain*. But you can’t give equal weight to all voices for every decision. That’s where the framework gets teeth.
|
||||
|
||||
**MUJTAHID:** In Usul al-Fiqh, *Istiqsa’* is exhaustive inquiry into the reality of the matter before issuing a hukm. It is not a casual survey. It is a systematic investigation of the *‘illah* (effective cause) and *maqsad* (purpose). Before you consult, you must define the domain of consultation.
|
||||
|
||||
Shura in the Islamic tradition is not just “asking for opinions.” It is a binding methodology for collective decision-making rooted in *Hifz al-Karama* — preserving the dignity of every stakeholder by giving them a voice that is actually heard and weighed. The Prophet ﷺ consulted his companions even when revelation existed. Why? Because Shura is a *right* of the community, not a courtesy.
|
||||
|
||||
But Shura has conditions (*shurut*):
|
||||
1. The matter must be *mujtahad fih* — open to ijtihad, not fixed by explicit text.
|
||||
2. The consultor must be trustworthy and seeking truth, not validation.
|
||||
3. The consulted must be qualified (*ahl al-shura*) — knowledgeable in that domain.
|
||||
4. The consultor is not bound to follow the majority opinion; but must give it due weight and explain departure.
|
||||
|
||||
So your discovery phase is actually *Istiqsa’*: you are gathering the *wāqi‘* (reality) of the problem space. Ask: What is the *maqsad* of this feature? Is it preserving *Mal* (wealth), *Aql* (mind), *Nafs* (life)? In fintech, most features impact *Mal* directly. But they also impact *Karama* — dignity of the user (e.g., not hiding fees, not patronizing language). The *maqsad* of stakeholder voice itself is *Karama*: every stakeholder is a human whose opinion has inherent value.
|
||||
|
||||
So your Istiqsa’ must map each stakeholder’s *maqsad* in the decision. Users want fairness and transparency. Team wants clarity and autonomy. Business wants growth and risk management. Regulators want compliance and public interest (*maslaha*). Each has a legitimate *maqsad*. The discovery question becomes: *Which maqasid are at stake in this decision?*
|
||||
|
||||
Draw a Maqasid Matrix: For each stakeholder group, list the primary maqsad (e.g., Users: Hifz al-Mal + Karama; Team: Hifz al-Aql (clarity) + Karama; Business: Hifz al-Mal; Regulators: Hifz al-Din + Hifz al-Mal al-‘Amm). Then rank by weight in this specific decision. That becomes your discovery lens.
|
||||
|
||||
---
|
||||
|
||||
### 3. EVIDENCE (ISTIDLAL)
|
||||
|
||||
**PRODUCT_LEAD:** Evidence gathering is two streams: quantitative and qualitative. Quantitative: metrics, analytics, conversion funnels, NPS, churn rates. Qualitative: user interviews, support tickets, session replays, stakeholder 1:1s.
|
||||
|
||||
But the trap is treating all evidence equally. A CEO’s strong opinion is not evidence. A single user complaint is not evidence. A regression test passing is not evidence of value.
|
||||
|
||||
Use the Evidence Hierarchy:
|
||||
- **Level 1: Direct observation** (you watched a user struggle)
|
||||
- **Level 2: Behavioral data** (analytics show 80% drop-off at step 3)
|
||||
- **Level 3: Self-reported data** (user says “I want X” — weak)
|
||||
- **Level 4: Expert opinion** (CEO says “the market needs Y” — weakest)
|
||||
|
||||
In your fintech case, you might have:
|
||||
- Quantitative: 45% of users abandon onboarding after KYC step.
|
||||
- Qualitative: Users say “I don’t trust giving my ID to an app.”
|
||||
- CEO says: “We need to simplify KYC to one click.”
|
||||
- Regulator says: “KYC must have three verification steps.”
|
||||
|
||||
Conflict. How do you weigh? You go back to the *outcome*: North Star Metric is “trusted transactions per user.” The evidence from users (distrust) and regulators (compliance) both point to the same root: lack of transparency in the KYC process. The CEO’s “one click” would violate regulatory shart. So you weigh regulatory evidence heavier in this domain (their *maqsad* is Hifz al-Mal al-‘Amm, public wealth, which overrides convenience).
|
||||
|
||||
**MUJTAHID:** Istidlal is the process of deriving evidence and weighing it. In Usul al-Fiqh, evidence has a hierarchy:
|
||||
- **Qati‘ al-Thubut wa Qati‘ al-Dalala** (definitive source and definitive meaning) — e.g., a clear Qur’anic verse. In product: hard data that is beyond dispute (e.g., “server downtime is 99.9%”).
|
||||
- **Qati‘ al-Thubut wa Zanni al-Dalala** (definitive source but ambiguous meaning) — e.g., a verse with multiple interpretations. In product: a metric that is reliable but its meaning is debated (e.g., “engagement time went up” — is that good or bad?).
|
||||
- **Zanni al-Thubut wa Qati‘ al-Dalala** (probable source but clear meaning) — e.g., a strong hadith. In product: a well-conducted user interview with a clear signal.
|
||||
- **Zanni al-Thubut wa Zanni al-Dalala** (both probable) — e.g., a weak hadith or an opinion. In product: a stakeholder’s gut feeling.
|
||||
|
||||
When stakeholders conflict, you must weigh their evidence by *thubut* (reliability) and *dalala* (clarity). A regulator’s written requirement is Qati‘ al-Thubut (it’s law) and often Qati‘ al-Dalala (clear rule). A user’s complaint is Zanni al-Thubut (maybe biased, maybe sample of one) but could be Qati‘ al-Dalala if the complaint is precise (“I can’t upload my ID because the file size limit is too small”). A CEO’s vision is usually Zanni al-Thubut (no data) and Zanni al-Dalala (vague).
|
||||
|
||||
So the weight of evidence is: **Regulator > User behavioral data > User self-report > CEO opinion**. But that’s not absolute — if the CEO’s opinion is based on deep market data (e.g., competitor analysis), it moves up in thubut.
|
||||
|
||||
The Mujtahid’s rule: *Al-thubut yuqaddam ‘ala al-dalala* (reliability of source is prioritized over clarity of meaning) when sources conflict. But you must also consider *maqsad*: the purpose of the rule. If the CEO’s idea serves Hifz al-Mal (profit) but violates Hifz al-Din (compliance), the latter outweighs because *Dar’u al-mafasid muqaddam ‘ala jalb al-masalih* (preventing harm takes precedence over bringing benefit). So you rank evidence by both source reliability and maqsad weight.
|
||||
|
||||
Practical step: For each stakeholder input, assign a score: Thubut (1-3: weak, medium, strong) and Dalala (1-3: vague, clear, precise). Multiply? Or use a weighted matrix. The key is to make the weighting explicit, not silent. Write it down. Share it with stakeholders as part of Shura transparency.
|
||||
|
||||
---
|
||||
|
||||
### 4. SHURA
|
||||
|
||||
**PRODUCT_LEAD:** Shura is not a meeting. It’s a process. In practice, I run structured consultation:
|
||||
|
||||
1. **Pre-work:** Send the Opportunity Solution Tree and the evidence matrix to stakeholders a week before. Ask them to review and add their own evidence.
|
||||
2. **The Shura session:** 90 minutes, no slides. Start with the *maqsad*: “What outcome are we trying to achieve?” Then review the evidence for each opportunity. Then discuss solutions. But the rule: *each stakeholder speaks only in their domain of expertise*. The CEO does not override the engineer on technical feasibility. The user does not override the regulator on compliance. The PM synthesizes.
|
||||
3. **Recording dissent:** If a stakeholder disagrees, it is recorded and given weight in the final decision. The Prophet ﷺ would record minority opinions and sometimes follow them later. This preserves Karama — even the dissenter’s dignity is honored.
|
||||
|
||||
In your fintech case, you might have: Users want simpler KYC. Regulator wants stricter KYC. Team says they can build a tiered KYC (low risk = simple, high risk = strict). The CEO wants a single flow. The Shura session reveals that the *maqsad* is Hifz al-Mal (prevent fraud) and Hifz al-Karama (don’t humiliate users with unnecessary hurdles). The tiered solution balances both. The CEO’s single flow is rejected because it fails the maqsad of *Karama* (low-risk users would be overburdened) and *Mal* (fraud risk). The dissent is recorded: CEO disagrees, but the evidence and maqsad analysis overrides.
|
||||
|
||||
**MUJTAHID:** Shura in Usul al-Fiqh is an obligation for matters that affect the community. The Qur’an says: *“And consult them in the matter”* (3:159). The *mushawir* (consultor) must be:
|
||||
- *‘Adil* (just) — not favoring their own opinion.
|
||||
- *Khabir* (expert) — knows the domain.
|
||||
- *Amin* (trustworthy) — will not leak confidential information.
|
||||
|
||||
The *mushar* (consulted) must be:
|
||||
- *Ahl al-ray* (qualified to give opinion).
|
||||
- *Mukhlish* (sincere, not seeking personal gain).
|
||||
|
||||
How do you consult? You present the *mas’ala* (issue) and the *wāqi‘* (reality) as you have discovered it. You do not present your preferred solution first — that biases the response. Instead, you ask: “What do you see as the best path forward, given this evidence?” Then you listen. You take notes. You thank them for their input, even if you disagree. The *adab* (etiquette) of Shura requires that you never dismiss a stakeholder’## THE FATWA (HUKM)
|
||||
|
||||
**HUKM:** We will institutionalise a mandatory Shura process for all product decisions above a defined threshold (impacting >10% of users or >$50k revenue), requiring documented consultation from all four quadrants (Users, Team, Business, Regulators) before any fatwa is issued, with a clear escalation mechanism for unresolved conflicts.
|
||||
|
||||
**DALEEL:** PRODUCT_LEAD: “Continuous discovery teaches us that decisions made in isolation fail to capture the full opportunity space. Our user interviews revealed three features that were deprioritised because the team assumed they were low-value, but when we finally asked, users rated them as critical. That’s a dignity failure — we assumed their voice without giving them a seat.” MUJTAHID: “Usul al-fiqh requires istiqsa’ (comprehensive investigation) before ruling. The Shura quadrant is a tool for istiqsa’ of stakeholder reality. Daleel from the Quran (Surah Al-Shura 42:38) commands consultation in affairs. The sunnah of the Prophet ﷺ in the Battle of Uhud shows that even when the leader held a strong opinion, he honoured the Shura outcome. Here, our quantitative data showed that 70% of product failures in the last quarter were attributable to a single quadrant being ignored — usually Regulators or Team. That is a pattern of injustice (zulm) that must be remedied.”
|
||||
|
||||
**MAQSAD:** Hifz al-Karama (Preservation of Dignity) — the primary maqsad. Every stakeholder is created with inherent worth; their perspective is a trust (amanah) that must be heard and weighed. Without structured Shura, we reduce people to data points. Secondary maqsad: Hifz al-Mal — avoiding rework that costs 3x initial development; Hifz al-Aql — incorporating diverse reasoning to prevent groupthink; Hifz al-Nasl — building a culture where future product teams inherit a tradition of consultation, not dictatorship.
|
||||
|
||||
**SHURUT:**
|
||||
- **Threshold clarity:** The Shura process is mandatory for any decision on the product roadmap that affects a critical metric (e.g., North Star, OKR) or requires >2 sprints of engineering effort. Lower-impact decisions can use a lightweight version (15-min async poll).
|
||||
- **Quadrant weighting:** Each quadrant’s voice is weighted by relevance to the decision, not by seniority. A junior engineer’s technical constraint may outweigh a VP’s preference. Weighting is documented before the session and shared openly.
|
||||
- **Time-bound:** Shura sessions must conclude within 5 working days for standard decisions, 48 hours for time-sensitive ones. If no consensus, the facilitator (typically the PM) issues a fatwa with a documented rationale based on maslaha (public benefit) and istihsan (juristic preference), explicitly stating which quadrant’s input was overridden and why.
|
||||
- **Transparency:** The fatwa must be published to all participants within 24 hours of the session, including a summary of how each quadrant’s input shaped the decision. If a quadrant’s input was set aside, the rationale must cite a specific qa’idah fiqhiyyah (e.g., “al-darar yuzal” — harm must be removed — if overriding a user request to prevent a broader harm).
|
||||
|
||||
**MUNKATHIRAT:**
|
||||
- If any quadrant’s documented input is ignored without a written istihsan or maslaha justification in the fatwa, the decision is void and must be reconvened within one sprint.
|
||||
- If the Shura process is bypassed for a decision that meets the threshold (e.g., due to “urgency” that turns out to be false), the fatwa is nullified, and the responsible PM must present a tawbah (corrective action) plan to the team.
|
||||
- If new daleel emerges within two sprints that contradicts a key assumption used in the Shura, the fatwa is suspended and a mini-Shura (30-min session with the same quadrants) is called to reassess.
|
||||
|
||||
## THE PROTOCOL
|
||||
|
||||
STEP 1: **Map your NEXT product decision to the Shura Quadrant.** Within 48 hours, open a simple document (Google Doc or Notion) with four sections: Users / Team / Business / Regulators. For each quadrant, list the specific person or data source you will consult. If you cannot name at least one voice per quadrant, that is a red flag — escalate to your product lead. Example: Decision to add a new payment feature — Users: interview 3 power users; Team: lead engineer and designer; Business: CFO and sales director; Regulators: compliance officer and Shariah advisor (if fintech). Deadline: end of third day.
|
||||
|
||||
STEP 2: **Run a 60-minute Shura session using the structured agenda.** Invite all identified stakeholders. Agenda: (a) Context setting — the problem and opportunity (5 min), (b) Each quadrant presents their input in turn, uninterrupted (4 min each = 16 min), (c) Facilitated discussion — highlight trade-offs, identify conflicting daleel (20 min), (d) Decision or escalation — if consensus, document fatwa; if not, assign a decision-maker to issue a fatwa with rationale within 24 hours (19 min). Use a timer. Record all input on a shared board.
|
||||
|
||||
STEP 3: **Issue the fatwa and define Munkathirat.** Within 24 hours of the session, publish the fatwa using the five-part format (Hukm, Daleel, Maqsad, Shurut, Munkathirat). Include a one-paragraph summary of how each quadrant’s input was considered. Then, add a calendar entry for one sprint later to review the Munkathirat triggers. Example trigger: “If user adoption of the new payment feature drops below 20% in two weeks, the decision is null and we
|
||||
@@ -0,0 +1,103 @@
|
||||
### FATWA #3: Stakeholder Consultation — Shura as Discovery
|
||||
|
||||
**MAQSAD:** Hifz al-Karama (Preservation of Dignity) → Stakeholder Voice
|
||||
**FRAMEWORK:** Shura Quadrant: Users / Team / Business / Regulators
|
||||
|
||||
---
|
||||
|
||||
## PART 1: SCENARIO → DISCOVERY → EVIDENCE → SHURA
|
||||
|
||||
---
|
||||
|
||||
### 1. THE SCENARIO
|
||||
|
||||
You’re the Product Lead at a growing fintech startup. Your CEO storms into your weekly sync: “Why are we building this feature? Who asked for it? I want a roadmap that *actually* reflects the business priorities.”
|
||||
|
||||
You open your notebook. The Mujtahid in you whispers: *What is the hukm of this consultation? What is the maqsad? Is this Shura or a performance?* You’ve done stakeholder interviews before. But they felt like checkboxes, not real discovery. The team built features that nobody used. The CEO’s voice dominated every product council. Users complained they were never heard. Regulators sent compliance warnings that caught you off guard. Something was broken. You need a methodology for consultation that is *valid* — not just polite listening but structured, evidence-weighted, dignity-preserving Shura.
|
||||
|
||||
---
|
||||
|
||||
### 2. DISCOVERY (ISTIQSA')
|
||||
|
||||
**PRODUCT_LEAD:** Let’s start with the real problem. The CEO’s question “Why are we building this?” is actually a symptom. The deeper problem: we have no systematic way to *discover* what stakeholders actually need. We’re jumping to solutions based on the loudest voice (usually the CEO or the highest-paying customer). That’s not discovery; that’s guessing.
|
||||
|
||||
I use the Opportunity Solution Tree. Draw it: On the left, your desired outcome (e.g., “Increase active user retention by 20%”). Then branch into *opportunities* — problems, pains, desires from users. Then branch into *solution ideas*. Then *experiments*. The key is that every branch comes from user evidence, not executive intuition.
|
||||
|
||||
In your fintech case, start with user interviews. Ask: “What’s the hardest part of managing your money right now?” Not “What feature do you want?” That’s JTBD: people hire your product to get a job done. The job might be “avoid late fees” or “save for Hajj without temptation.” Your CEO might think the job is “more analytics dashboards.” But the user’s job is different.
|
||||
|
||||
Map all stakeholder groups: Users (retail customers), Team (engineers, designers), Business (CEO, sales, finance), Regulators (Sharia board, central bank). Each has a different job. Each must be heard *in their own domain*. But you can’t give equal weight to all voices for every decision. That’s where the framework gets teeth.
|
||||
|
||||
**MUJTAHID:** In Usul al-Fiqh, *Istiqsa’* is exhaustive inquiry into the reality of the matter before issuing a hukm. It is not a casual survey. It is a systematic investigation of the *‘illah* (effective cause) and *maqsad* (purpose). Before you consult, you must define the domain of consultation.
|
||||
|
||||
Shura in the Islamic tradition is not just “asking for opinions.” It is a binding methodology for collective decision-making rooted in *Hifz al-Karama* — preserving the dignity of every stakeholder by giving them a voice that is actually heard and weighed. The Prophet ﷺ consulted his companions even when revelation existed. Why? Because Shura is a *right* of the community, not a courtesy.
|
||||
|
||||
But Shura has conditions (*shurut*):
|
||||
1. The matter must be *mujtahad fih* — open to ijtihad, not fixed by explicit text.
|
||||
2. The consultor must be trustworthy and seeking truth, not validation.
|
||||
3. The consulted must be qualified (*ahl al-shura*) — knowledgeable in that domain.
|
||||
4. The consultor is not bound to follow the majority opinion; but must give it due weight and explain departure.
|
||||
|
||||
So your discovery phase is actually *Istiqsa’*: you are gathering the *wāqi‘* (reality) of the problem space. Ask: What is the *maqsad* of this feature? Is it preserving *Mal* (wealth), *Aql* (mind), *Nafs* (life)? In fintech, most features impact *Mal* directly. But they also impact *Karama* — dignity of the user (e.g., not hiding fees, not patronizing language). The *maqsad* of stakeholder voice itself is *Karama*: every stakeholder is a human whose opinion has inherent value.
|
||||
|
||||
So your Istiqsa’ must map each stakeholder’s *maqsad* in the decision. Users want fairness and transparency. Team wants clarity and autonomy. Business wants growth and risk management. Regulators want compliance and public interest (*maslaha*). Each has a legitimate *maqsad*. The discovery question becomes: *Which maqasid are at stake in this decision?*
|
||||
|
||||
Draw a Maqasid Matrix: For each stakeholder group, list the primary maqsad (e.g., Users: Hifz al-Mal + Karama; Team: Hifz al-Aql (clarity) + Karama; Business: Hifz al-Mal; Regulators: Hifz al-Din + Hifz al-Mal al-‘Amm). Then rank by weight in this specific decision. That becomes your discovery lens.
|
||||
|
||||
---
|
||||
|
||||
### 3. EVIDENCE (ISTIDLAL)
|
||||
|
||||
**PRODUCT_LEAD:** Evidence gathering is two streams: quantitative and qualitative. Quantitative: metrics, analytics, conversion funnels, NPS, churn rates. Qualitative: user interviews, support tickets, session replays, stakeholder 1:1s.
|
||||
|
||||
But the trap is treating all evidence equally. A CEO’s strong opinion is not evidence. A single user complaint is not evidence. A regression test passing is not evidence of value.
|
||||
|
||||
Use the Evidence Hierarchy:
|
||||
- **Level 1: Direct observation** (you watched a user struggle)
|
||||
- **Level 2: Behavioral data** (analytics show 80% drop-off at step 3)
|
||||
- **Level 3: Self-reported data** (user says “I want X” — weak)
|
||||
- **Level 4: Expert opinion** (CEO says “the market needs Y” — weakest)
|
||||
|
||||
In your fintech case, you might have:
|
||||
- Quantitative: 45% of users abandon onboarding after KYC step.
|
||||
- Qualitative: Users say “I don’t trust giving my ID to an app.”
|
||||
- CEO says: “We need to simplify KYC to one click.”
|
||||
- Regulator says: “KYC must have three verification steps.”
|
||||
|
||||
Conflict. How do you weigh? You go back to the *outcome*: North Star Metric is “trusted transactions per user.” The evidence from users (distrust) and regulators (compliance) both point to the same root: lack of transparency in the KYC process. The CEO’s “one click” would violate regulatory shart. So you weigh regulatory evidence heavier in this domain (their *maqsad* is Hifz al-Mal al-‘Amm, public wealth, which overrides convenience).
|
||||
|
||||
**MUJTAHID:** Istidlal is the process of deriving evidence and weighing it. In Usul al-Fiqh, evidence has a hierarchy:
|
||||
- **Qati‘ al-Thubut wa Qati‘ al-Dalala** (definitive source and definitive meaning) — e.g., a clear Qur’anic verse. In product: hard data that is beyond dispute (e.g., “server downtime is 99.9%”).
|
||||
- **Qati‘ al-Thubut wa Zanni al-Dalala** (definitive source but ambiguous meaning) — e.g., a verse with multiple interpretations. In product: a metric that is reliable but its meaning is debated (e.g., “engagement time went up” — is that good or bad?).
|
||||
- **Zanni al-Thubut wa Qati‘ al-Dalala** (probable source but clear meaning) — e.g., a strong hadith. In product: a well-conducted user interview with a clear signal.
|
||||
- **Zanni al-Thubut wa Zanni al-Dalala** (both probable) — e.g., a weak hadith or an opinion. In product: a stakeholder’s gut feeling.
|
||||
|
||||
When stakeholders conflict, you must weigh their evidence by *thubut* (reliability) and *dalala* (clarity). A regulator’s written requirement is Qati‘ al-Thubut (it’s law) and often Qati‘ al-Dalala (clear rule). A user’s complaint is Zanni al-Thubut (maybe biased, maybe sample of one) but could be Qati‘ al-Dalala if the complaint is precise (“I can’t upload my ID because the file size limit is too small”). A CEO’s vision is usually Zanni al-Thubut (no data) and Zanni al-Dalala (vague).
|
||||
|
||||
So the weight of evidence is: **Regulator > User behavioral data > User self-report > CEO opinion**. But that’s not absolute — if the CEO’s opinion is based on deep market data (e.g., competitor analysis), it moves up in thubut.
|
||||
|
||||
The Mujtahid’s rule: *Al-thubut yuqaddam ‘ala al-dalala* (reliability of source is prioritized over clarity of meaning) when sources conflict. But you must also consider *maqsad*: the purpose of the rule. If the CEO’s idea serves Hifz al-Mal (profit) but violates Hifz al-Din (compliance), the latter outweighs because *Dar’u al-mafasid muqaddam ‘ala jalb al-masalih* (preventing harm takes precedence over bringing benefit). So you rank evidence by both source reliability and maqsad weight.
|
||||
|
||||
Practical step: For each stakeholder input, assign a score: Thubut (1-3: weak, medium, strong) and Dalala (1-3: vague, clear, precise). Multiply? Or use a weighted matrix. The key is to make the weighting explicit, not silent. Write it down. Share it with stakeholders as part of Shura transparency.
|
||||
|
||||
---
|
||||
|
||||
### 4. SHURA
|
||||
|
||||
**PRODUCT_LEAD:** Shura is not a meeting. It’s a process. In practice, I run structured consultation:
|
||||
|
||||
1. **Pre-work:** Send the Opportunity Solution Tree and the evidence matrix to stakeholders a week before. Ask them to review and add their own evidence.
|
||||
2. **The Shura session:** 90 minutes, no slides. Start with the *maqsad*: “What outcome are we trying to achieve?” Then review the evidence for each opportunity. Then discuss solutions. But the rule: *each stakeholder speaks only in their domain of expertise*. The CEO does not override the engineer on technical feasibility. The user does not override the regulator on compliance. The PM synthesizes.
|
||||
3. **Recording dissent:** If a stakeholder disagrees, it is recorded and given weight in the final decision. The Prophet ﷺ would record minority opinions and sometimes follow them later. This preserves Karama — even the dissenter’s dignity is honored.
|
||||
|
||||
In your fintech case, you might have: Users want simpler KYC. Regulator wants stricter KYC. Team says they can build a tiered KYC (low risk = simple, high risk = strict). The CEO wants a single flow. The Shura session reveals that the *maqsad* is Hifz al-Mal (prevent fraud) and Hifz al-Karama (don’t humiliate users with unnecessary hurdles). The tiered solution balances both. The CEO’s single flow is rejected because it fails the maqsad of *Karama* (low-risk users would be overburdened) and *Mal* (fraud risk). The dissent is recorded: CEO disagrees, but the evidence and maqsad analysis overrides.
|
||||
|
||||
**MUJTAHID:** Shura in Usul al-Fiqh is an obligation for matters that affect the community. The Qur’an says: *“And consult them in the matter”* (3:159). The *mushawir* (consultor) must be:
|
||||
- *‘Adil* (just) — not favoring their own opinion.
|
||||
- *Khabir* (expert) — knows the domain.
|
||||
- *Amin* (trustworthy) — will not leak confidential information.
|
||||
|
||||
The *mushar* (consulted) must be:
|
||||
- *Ahl al-ray* (qualified to give opinion).
|
||||
- *Mukhlish* (sincere, not seeking personal gain).
|
||||
|
||||
How do you consult? You present the *mas’ala* (issue) and the *wāqi‘* (reality) as you have discovered it. You do not present your preferred solution first — that biases the response. Instead, you ask: “What do you see as the best path forward, given this evidence?” Then you listen. You take notes. You thank them for their input, even if you disagree. The *adab* (etiquette) of Shura requires that you never dismiss a stakeholder’
|
||||
@@ -0,0 +1,26 @@
|
||||
## THE FATWA (HUKM)
|
||||
|
||||
**HUKM:** We will institutionalise a mandatory Shura process for all product decisions above a defined threshold (impacting >10% of users or >$50k revenue), requiring documented consultation from all four quadrants (Users, Team, Business, Regulators) before any fatwa is issued, with a clear escalation mechanism for unresolved conflicts.
|
||||
|
||||
**DALEEL:** PRODUCT_LEAD: “Continuous discovery teaches us that decisions made in isolation fail to capture the full opportunity space. Our user interviews revealed three features that were deprioritised because the team assumed they were low-value, but when we finally asked, users rated them as critical. That’s a dignity failure — we assumed their voice without giving them a seat.” MUJTAHID: “Usul al-fiqh requires istiqsa’ (comprehensive investigation) before ruling. The Shura quadrant is a tool for istiqsa’ of stakeholder reality. Daleel from the Quran (Surah Al-Shura 42:38) commands consultation in affairs. The sunnah of the Prophet ﷺ in the Battle of Uhud shows that even when the leader held a strong opinion, he honoured the Shura outcome. Here, our quantitative data showed that 70% of product failures in the last quarter were attributable to a single quadrant being ignored — usually Regulators or Team. That is a pattern of injustice (zulm) that must be remedied.”
|
||||
|
||||
**MAQSAD:** Hifz al-Karama (Preservation of Dignity) — the primary maqsad. Every stakeholder is created with inherent worth; their perspective is a trust (amanah) that must be heard and weighed. Without structured Shura, we reduce people to data points. Secondary maqsad: Hifz al-Mal — avoiding rework that costs 3x initial development; Hifz al-Aql — incorporating diverse reasoning to prevent groupthink; Hifz al-Nasl — building a culture where future product teams inherit a tradition of consultation, not dictatorship.
|
||||
|
||||
**SHURUT:**
|
||||
- **Threshold clarity:** The Shura process is mandatory for any decision on the product roadmap that affects a critical metric (e.g., North Star, OKR) or requires >2 sprints of engineering effort. Lower-impact decisions can use a lightweight version (15-min async poll).
|
||||
- **Quadrant weighting:** Each quadrant’s voice is weighted by relevance to the decision, not by seniority. A junior engineer’s technical constraint may outweigh a VP’s preference. Weighting is documented before the session and shared openly.
|
||||
- **Time-bound:** Shura sessions must conclude within 5 working days for standard decisions, 48 hours for time-sensitive ones. If no consensus, the facilitator (typically the PM) issues a fatwa with a documented rationale based on maslaha (public benefit) and istihsan (juristic preference), explicitly stating which quadrant’s input was overridden and why.
|
||||
- **Transparency:** The fatwa must be published to all participants within 24 hours of the session, including a summary of how each quadrant’s input shaped the decision. If a quadrant’s input was set aside, the rationale must cite a specific qa’idah fiqhiyyah (e.g., “al-darar yuzal” — harm must be removed — if overriding a user request to prevent a broader harm).
|
||||
|
||||
**MUNKATHIRAT:**
|
||||
- If any quadrant’s documented input is ignored without a written istihsan or maslaha justification in the fatwa, the decision is void and must be reconvened within one sprint.
|
||||
- If the Shura process is bypassed for a decision that meets the threshold (e.g., due to “urgency” that turns out to be false), the fatwa is nullified, and the responsible PM must present a tawbah (corrective action) plan to the team.
|
||||
- If new daleel emerges within two sprints that contradicts a key assumption used in the Shura, the fatwa is suspended and a mini-Shura (30-min session with the same quadrants) is called to reassess.
|
||||
|
||||
## THE PROTOCOL
|
||||
|
||||
STEP 1: **Map your NEXT product decision to the Shura Quadrant.** Within 48 hours, open a simple document (Google Doc or Notion) with four sections: Users / Team / Business / Regulators. For each quadrant, list the specific person or data source you will consult. If you cannot name at least one voice per quadrant, that is a red flag — escalate to your product lead. Example: Decision to add a new payment feature — Users: interview 3 power users; Team: lead engineer and designer; Business: CFO and sales director; Regulators: compliance officer and Shariah advisor (if fintech). Deadline: end of third day.
|
||||
|
||||
STEP 2: **Run a 60-minute Shura session using the structured agenda.** Invite all identified stakeholders. Agenda: (a) Context setting — the problem and opportunity (5 min), (b) Each quadrant presents their input in turn, uninterrupted (4 min each = 16 min), (c) Facilitated discussion — highlight trade-offs, identify conflicting daleel (20 min), (d) Decision or escalation — if consensus, document fatwa; if not, assign a decision-maker to issue a fatwa with rationale within 24 hours (19 min). Use a timer. Record all input on a shared board.
|
||||
|
||||
STEP 3: **Issue the fatwa and define Munkathirat.** Within 24 hours of the session, publish the fatwa using the five-part format (Hukm, Daleel, Maqsad, Shurut, Munkathirat). Include a one-paragraph summary of how each quadrant’s input was considered. Then, add a calendar entry for one sprint later to review the Munkathirat triggers. Example trigger: “If user adoption of the new payment feature drops below 20% in two weeks, the decision is null and we
|
||||
@@ -0,0 +1,110 @@
|
||||
**Fatwa #4: The Product Decision — The Fatwa as Definition of Done**
|
||||
*Maqsad: Hifz al-Din (Preservation of Purpose)*
|
||||
|
||||
---
|
||||
|
||||
### 1. THE SCENARIO
|
||||
|
||||
You’re the Product Lead at a growing fintech startup. The CEO calls you into her office. “We’ve been sprinting for six weeks on the new auto-invest feature,” she says. “The engineers say it’s ‘done’ — tests pass, UI looks clean. But I’m not sure it solves the problem. Why are we building this again?”
|
||||
|
||||
You open your notebook. The Mujtahid in you asks: *What is the hukm? What is the maqsad?* The Product Lead in you asks: *What does “done” really mean?* You realize: you don’t have a Definition of Done that connects to purpose. You have a checklist, not a fatwa.
|
||||
|
||||
---
|
||||
|
||||
### 2. DISCOVERY (ISTIQSA’)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Let’s run Continuous Discovery. Open your Opportunity Solution Tree. On the left, write the *outcome*: “Increase monthly active investors by 20%.” That’s your North Star for this quarter. Now trace backward: What are the opportunities? User interviews last week showed a JTBD: “I want to invest without thinking about it.” That’s the job. The opportunity is *reducing cognitive overhead*. But your team jumped straight to a solution: auto-invest with a fixed percentage. Did you explore *why* users avoid manual investing? Did you test the assumption that auto-invest is the best way to remove friction? Discovery isn’t done until you’ve mapped at least three alternative solutions and validated the opportunity with real behavior, not just stated preferences.
|
||||
|
||||
**MUJTAHID:**
|
||||
Istiqsa’ — comprehensive investigation of the problem space. In usul al-fiqh, we don’t issue a fatwa until we fully comprehend the *maqsad* (purpose) and the *waqi’* (reality). Here, the maqsad is Hifz al-Din — preserving the purpose of the product. What is the purpose of your fintech app? Not just to move money, but to help users steward their wealth responsibly (Hifz al-Mal). If you lose that purpose, you’ve built a gambling machine, not a savings tool. So first question: *What is the hukm asl (default ruling) of an auto-invest feature?* It’s mubah — permissible — but only if it doesn’t lead to harm (gharar, riba, negligence). You must explore the *shurut* (conditions) that make it valid. Is the user giving informed consent? Is the investment halal? Does the feature encourage mindless risk? Istiqsa’ means mapping these conditions before you decide.
|
||||
|
||||
**Merged insight:**
|
||||
Both mentors agree: Discovery is not about listing features. It’s about defining the problem space so thoroughly that the decision boundary becomes clear. Use a Decision Quadrant:
|
||||
- **Reversible vs Irreversible** (Type 1 vs Type 2 decisions)
|
||||
- **High Stakes vs Low Stakes**
|
||||
- **Data-Rich vs Data-Poor**
|
||||
|
||||
Auto-invest is *reversible* (you can roll back), *moderately high stakes* (users’ money), and *data-poor* (no actual usage yet). That means you need a lightweight fatwa — a conditional go with strong monitoring. But you must still anchor to maqsad: *Does this feature preserve the user’s ability to act intentionally?* If it removes all intention, it may violate Hifz al-Din (purposeful action).
|
||||
|
||||
---
|
||||
|
||||
### 3. EVIDENCE (ISTIDLAL)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Gather daleel — evidence. Two types: quantitative and qualitative.
|
||||
- *Quantitative*: You run a smoke test. Put a “Set & Forget” button on the dashboard. Track click-through rate. 12% click — high intent. But then you run an A/B test on onboarding: users who see a “What’s your risk tolerance?” question before auto-invest vs. those who see a default allocation. The default group has 40% higher signup but 60% higher opt-out within 30 days. That’s a Zanni (speculative) signal: convenience may cause regret.
|
||||
- *Qualitative*: User interviews with 8 people. One says: “I set it and forgot it, but now I don’t know where my money is. I feel uneasy.” That’s a Qati al-Dalala (clear indication) of a problem: the feature undermines *awareness*.
|
||||
|
||||
Evidence hierarchy:
|
||||
- Qati (certain) = user behavior showing harm (e.g., high regret rate).
|
||||
- Zanni (probable) = survey scores, A/B significance.
|
||||
- Wahn (weak) = gut feel from execs.
|
||||
|
||||
**MUJTAHID:**
|
||||
In istidlal, we weigh evidence by strength and relevance. The Prophet ﷺ said, “The burden of proof is on the claimant” (al-Bayhaqi). Here, the claimant is the team arguing the feature is “done.” They claim it solves the user’s job. But the evidence shows a *mafsada* (harm): reduced user agency. This triggers Sad al-Dhara’i — blocking the means to harm. The auto-invest feature, without a periodic check-in, becomes a *dhari’ah* (pathway) to heedlessness (ghaflah). That violates Hifz al-Din — the preservation of purposeful action.
|
||||
|
||||
Your evidence threshold depends on the decision type:
|
||||
- **Reversible decision** (easy rollback): Zanni evidence is enough. Ship it, measure, iterate.
|
||||
- **Irreversible decision** (changes data model, hard to undo): Need Qati evidence or strong Zanni with multiple witnesses (tawatur of user feedback).
|
||||
|
||||
This decision is reversible — you can turn off auto-invest. So Zanni evidence suffices. But the maqsad requires you to *add a condition*: the user must confirm their risk profile every 90 days. That condition is a *shart* derived from the evidence of harm.
|
||||
|
||||
---
|
||||
|
||||
### 4. SHURA
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Call a shura — a consultation meeting. Invite: the engineer (feasibility), the designer (usability), the compliance officer (risk), and two users (via video call). Don’t ask “Should we ship?” Ask: “What would need to be true for this feature to actually help users invest intentionally?” The engineer says rollback takes one sprint. The designer says adding a quarterly check-in adds 2 days of work. The compliance officer warns that auto-invest without periodic consent may violate regulations in 3 markets. The users say: “I’d feel better if the app nudges me to review every few months.”
|
||||
|
||||
Record all dissenting opinions. In shura, the majority does not automatically bind — the *rajih* (preponderant) view is based on strength of evidence and alignment with maqsad. The compliance officer’s concern is Qati (regulatory text), so it overrides the engineer’s convenience.
|
||||
|
||||
**MUJTAHID:**
|
||||
Shura is sunnah, but it has rules. The Prophet ﷺ consulted his companions even when revelation was available — not because he needed their opinion, but to train them and to uncover blind spots. Here, you must weight each opinion by *adalah* (trustworthiness) and *khibrah* (expertise). The user’s voice carries weight because he is the *mustafti* (seeker of the ruling). His testimony is *shahadah* (witness) of the real problem. The engineer’s opinion on cost is *ra’y* (reasoned opinion), not evidence.
|
||||
|
||||
Dissent is recorded. If the compliance officer objects, note it. If you override, explain why: *maslaha* (public benefit) of shipping quickly to test learning outweighs the low-probability regulatory risk, *provided* you add the shart of quarterly review. The shura ends with a clear list of *shurut* (conditions) and *munkathirat* (nullifiers) that will trigger rollback.
|
||||
|
||||
---
|
||||
|
||||
*End of Part 1. Part 2 continues with the Fatwa, Protocol, and Muhasaba.*## THE FATWA (HUKM)
|
||||
|
||||
**HUKM:** We will ship a **private personal progress tracker** (no public leaderboard) with optional one-to-one sharing to a trusted accountability partner, and we will **not build** any social comparison features (rankings, scores, global streaks) until we have direct evidence that such features enhance the user’s core *niyyah* (intention) rather than distract from it.
|
||||
|
||||
**DALEEL:**
|
||||
- User research (n=12) and a prototype test (n=60) showed that public leaderboards increased logins by 40% but decreased reported *khushu’* (mindfulness) scores by 25%.
|
||||
- The *maqsad* of the product is *Hifz al-Din* (preservation of purpose) – helping users deepen their spiritual practice. Social comparison features introduce *riya’* (showing off), which is *haram* in intent and likely to corrupt the core JTBD ("I want to build consistent spiritual habits without ego getting in the way").
|
||||
- The decision quadrant shows this is **high stakes** (spiritual harm) and **irreversible** once public leaderboard data creates network effects; switching back would break user trust. We are **data-poor** on long-term spiritual outcomes, so the principle of *Sad al-Dhara’i’* (blocking the means to harm) applies.
|
||||
|
||||
**MAQSAD:** Hifz al-Din – preserving the product’s purpose as a tool for *ibadah* (worship) and *tazkiyah* (self-purification), not as a gamified distraction. Secondary: Hifz al-Nafs (protecting the user from spiritual harm) and Hifz al-Aql (protecting mental clarity from competitive anxiety).
|
||||
|
||||
**SHURUT (Conditions / Acceptance Criteria):**
|
||||
- The private tracker must show **absolute personal progress** (e.g., “You completed 12 out of 15 daily *adhkar* this week”) with no relative comparison to others.
|
||||
- Optional sharing must be **opt-in, one-to-one, and reversible** – user can disconnect at any time without losing data.
|
||||
- Success metric: Improvement in self-reported *niyyah* clarity score (survey at week 2 and week 6) must be ≥ +0.5 on a 5-point scale, and drop-off rate due to “feeling pressured” must be < 5%.
|
||||
- Rollout: Feature-flag with 10% of users; if the *niyyah* score drops or complaints of *riya’* emerge, we roll back within 48 hours.
|
||||
|
||||
**MUNKATHIRAT (Nullifiers / Rollback Triggers):**
|
||||
- Any user-reported incident of *riya’* (e.g., “I feel like I’m competing with my friend instead of focusing on Allah”) – immediate rollback and re-design.
|
||||
- A/B test shows that the private tracker reduces daily active usage by more than 20% compared to control (without tracker) – indicates we’ve added friction without purpose preservation.
|
||||
- Qualitative feedback from ≥2 users in the first week indicates that the feature is being used as a *trophy case* rather than a *reflection tool* – roll back and revisit JTBD.
|
||||
|
||||
---
|
||||
|
||||
## THE PROTOCOL (3 Steps – This Sprint)
|
||||
|
||||
**STEP 1: Build the private tracker MVP**
|
||||
Design a single-screen dashboard showing the user’s own 7-day streak of the three core habits (e.g., Fajr on time, daily Quran page, evening adhkar). No badges, no points, no leaderboard. Use a simple green checkmark system. Ship behind feature flag to 10% of active users. *(Time: 3 days)*
|
||||
|
||||
**STEP 2: Collect *niyyah* data**
|
||||
Add an in-app micro-survey after 2 days of use: “On a scale of 1–5, how much does this tracker help you focus on your intention (niyyah) for worship?” Also track feature usage (clicks, time spent). *(Time: 5 days continuous)*
|
||||
|
||||
**STEP 3: Review and decide on expansion**
|
||||
If the *niyyah* score is ≥4.0 and no *riya’* incidents are reported, expand to 50% of users and begin designing a “close accountability partner” sharing feature (one-to-one, non‑competitive). If score <3.5, roll back the feature and schedule a new discovery sprint to understand what users actually need. *(Time: end of sprint)*
|
||||
|
||||
---
|
||||
|
||||
## MUHASABA (RETROSPECTIVE)
|
||||
|
||||
**What did we learn about our own willingness to sacrifice user engagement metrics for preserving spiritual purpose, and where did we feel the strongest temptation to compromise because of board pressure or growth targets?**
|
||||
|
||||
The most uncomfortable insight was that our team hesitated to kill the leaderboard idea because it promised easy retention numbers. The *Fatwa* forced us to ask: “Are we building for Allah’s pleasure or for our vanity as product builders?” The next sprint, we will pre‑commit to a *Shura* check before any feature with social elements enters development.
|
||||
@@ -0,0 +1,69 @@
|
||||
**Fatwa #4: The Product Decision — The Fatwa as Definition of Done**
|
||||
*Maqsad: Hifz al-Din (Preservation of Purpose)*
|
||||
|
||||
---
|
||||
|
||||
### 1. THE SCENARIO
|
||||
|
||||
You’re the Product Lead at a growing fintech startup. The CEO calls you into her office. “We’ve been sprinting for six weeks on the new auto-invest feature,” she says. “The engineers say it’s ‘done’ — tests pass, UI looks clean. But I’m not sure it solves the problem. Why are we building this again?”
|
||||
|
||||
You open your notebook. The Mujtahid in you asks: *What is the hukm? What is the maqsad?* The Product Lead in you asks: *What does “done” really mean?* You realize: you don’t have a Definition of Done that connects to purpose. You have a checklist, not a fatwa.
|
||||
|
||||
---
|
||||
|
||||
### 2. DISCOVERY (ISTIQSA’)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Let’s run Continuous Discovery. Open your Opportunity Solution Tree. On the left, write the *outcome*: “Increase monthly active investors by 20%.” That’s your North Star for this quarter. Now trace backward: What are the opportunities? User interviews last week showed a JTBD: “I want to invest without thinking about it.” That’s the job. The opportunity is *reducing cognitive overhead*. But your team jumped straight to a solution: auto-invest with a fixed percentage. Did you explore *why* users avoid manual investing? Did you test the assumption that auto-invest is the best way to remove friction? Discovery isn’t done until you’ve mapped at least three alternative solutions and validated the opportunity with real behavior, not just stated preferences.
|
||||
|
||||
**MUJTAHID:**
|
||||
Istiqsa’ — comprehensive investigation of the problem space. In usul al-fiqh, we don’t issue a fatwa until we fully comprehend the *maqsad* (purpose) and the *waqi’* (reality). Here, the maqsad is Hifz al-Din — preserving the purpose of the product. What is the purpose of your fintech app? Not just to move money, but to help users steward their wealth responsibly (Hifz al-Mal). If you lose that purpose, you’ve built a gambling machine, not a savings tool. So first question: *What is the hukm asl (default ruling) of an auto-invest feature?* It’s mubah — permissible — but only if it doesn’t lead to harm (gharar, riba, negligence). You must explore the *shurut* (conditions) that make it valid. Is the user giving informed consent? Is the investment halal? Does the feature encourage mindless risk? Istiqsa’ means mapping these conditions before you decide.
|
||||
|
||||
**Merged insight:**
|
||||
Both mentors agree: Discovery is not about listing features. It’s about defining the problem space so thoroughly that the decision boundary becomes clear. Use a Decision Quadrant:
|
||||
- **Reversible vs Irreversible** (Type 1 vs Type 2 decisions)
|
||||
- **High Stakes vs Low Stakes**
|
||||
- **Data-Rich vs Data-Poor**
|
||||
|
||||
Auto-invest is *reversible* (you can roll back), *moderately high stakes* (users’ money), and *data-poor* (no actual usage yet). That means you need a lightweight fatwa — a conditional go with strong monitoring. But you must still anchor to maqsad: *Does this feature preserve the user’s ability to act intentionally?* If it removes all intention, it may violate Hifz al-Din (purposeful action).
|
||||
|
||||
---
|
||||
|
||||
### 3. EVIDENCE (ISTIDLAL)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Gather daleel — evidence. Two types: quantitative and qualitative.
|
||||
- *Quantitative*: You run a smoke test. Put a “Set & Forget” button on the dashboard. Track click-through rate. 12% click — high intent. But then you run an A/B test on onboarding: users who see a “What’s your risk tolerance?” question before auto-invest vs. those who see a default allocation. The default group has 40% higher signup but 60% higher opt-out within 30 days. That’s a Zanni (speculative) signal: convenience may cause regret.
|
||||
- *Qualitative*: User interviews with 8 people. One says: “I set it and forgot it, but now I don’t know where my money is. I feel uneasy.” That’s a Qati al-Dalala (clear indication) of a problem: the feature undermines *awareness*.
|
||||
|
||||
Evidence hierarchy:
|
||||
- Qati (certain) = user behavior showing harm (e.g., high regret rate).
|
||||
- Zanni (probable) = survey scores, A/B significance.
|
||||
- Wahn (weak) = gut feel from execs.
|
||||
|
||||
**MUJTAHID:**
|
||||
In istidlal, we weigh evidence by strength and relevance. The Prophet ﷺ said, “The burden of proof is on the claimant” (al-Bayhaqi). Here, the claimant is the team arguing the feature is “done.” They claim it solves the user’s job. But the evidence shows a *mafsada* (harm): reduced user agency. This triggers Sad al-Dhara’i — blocking the means to harm. The auto-invest feature, without a periodic check-in, becomes a *dhari’ah* (pathway) to heedlessness (ghaflah). That violates Hifz al-Din — the preservation of purposeful action.
|
||||
|
||||
Your evidence threshold depends on the decision type:
|
||||
- **Reversible decision** (easy rollback): Zanni evidence is enough. Ship it, measure, iterate.
|
||||
- **Irreversible decision** (changes data model, hard to undo): Need Qati evidence or strong Zanni with multiple witnesses (tawatur of user feedback).
|
||||
|
||||
This decision is reversible — you can turn off auto-invest. So Zanni evidence suffices. But the maqsad requires you to *add a condition*: the user must confirm their risk profile every 90 days. That condition is a *shart* derived from the evidence of harm.
|
||||
|
||||
---
|
||||
|
||||
### 4. SHURA
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Call a shura — a consultation meeting. Invite: the engineer (feasibility), the designer (usability), the compliance officer (risk), and two users (via video call). Don’t ask “Should we ship?” Ask: “What would need to be true for this feature to actually help users invest intentionally?” The engineer says rollback takes one sprint. The designer says adding a quarterly check-in adds 2 days of work. The compliance officer warns that auto-invest without periodic consent may violate regulations in 3 markets. The users say: “I’d feel better if the app nudges me to review every few months.”
|
||||
|
||||
Record all dissenting opinions. In shura, the majority does not automatically bind — the *rajih* (preponderant) view is based on strength of evidence and alignment with maqsad. The compliance officer’s concern is Qati (regulatory text), so it overrides the engineer’s convenience.
|
||||
|
||||
**MUJTAHID:**
|
||||
Shura is sunnah, but it has rules. The Prophet ﷺ consulted his companions even when revelation was available — not because he needed their opinion, but to train them and to uncover blind spots. Here, you must weight each opinion by *adalah* (trustworthiness) and *khibrah* (expertise). The user’s voice carries weight because he is the *mustafti* (seeker of the ruling). His testimony is *shahadah* (witness) of the real problem. The engineer’s opinion on cost is *ra’y* (reasoned opinion), not evidence.
|
||||
|
||||
Dissent is recorded. If the compliance officer objects, note it. If you override, explain why: *maslaha* (public benefit) of shipping quickly to test learning outweighs the low-probability regulatory risk, *provided* you add the shart of quarterly review. The shura ends with a clear list of *shurut* (conditions) and *munkathirat* (nullifiers) that will trigger rollback.
|
||||
|
||||
---
|
||||
|
||||
*End of Part 1. Part 2 continues with the Fatwa, Protocol, and Muhasaba.*
|
||||
@@ -0,0 +1,42 @@
|
||||
## THE FATWA (HUKM)
|
||||
|
||||
**HUKM:** We will ship a **private personal progress tracker** (no public leaderboard) with optional one-to-one sharing to a trusted accountability partner, and we will **not build** any social comparison features (rankings, scores, global streaks) until we have direct evidence that such features enhance the user’s core *niyyah* (intention) rather than distract from it.
|
||||
|
||||
**DALEEL:**
|
||||
- User research (n=12) and a prototype test (n=60) showed that public leaderboards increased logins by 40% but decreased reported *khushu’* (mindfulness) scores by 25%.
|
||||
- The *maqsad* of the product is *Hifz al-Din* (preservation of purpose) – helping users deepen their spiritual practice. Social comparison features introduce *riya’* (showing off), which is *haram* in intent and likely to corrupt the core JTBD ("I want to build consistent spiritual habits without ego getting in the way").
|
||||
- The decision quadrant shows this is **high stakes** (spiritual harm) and **irreversible** once public leaderboard data creates network effects; switching back would break user trust. We are **data-poor** on long-term spiritual outcomes, so the principle of *Sad al-Dhara’i’* (blocking the means to harm) applies.
|
||||
|
||||
**MAQSAD:** Hifz al-Din – preserving the product’s purpose as a tool for *ibadah* (worship) and *tazkiyah* (self-purification), not as a gamified distraction. Secondary: Hifz al-Nafs (protecting the user from spiritual harm) and Hifz al-Aql (protecting mental clarity from competitive anxiety).
|
||||
|
||||
**SHURUT (Conditions / Acceptance Criteria):**
|
||||
- The private tracker must show **absolute personal progress** (e.g., “You completed 12 out of 15 daily *adhkar* this week”) with no relative comparison to others.
|
||||
- Optional sharing must be **opt-in, one-to-one, and reversible** – user can disconnect at any time without losing data.
|
||||
- Success metric: Improvement in self-reported *niyyah* clarity score (survey at week 2 and week 6) must be ≥ +0.5 on a 5-point scale, and drop-off rate due to “feeling pressured” must be < 5%.
|
||||
- Rollout: Feature-flag with 10% of users; if the *niyyah* score drops or complaints of *riya’* emerge, we roll back within 48 hours.
|
||||
|
||||
**MUNKATHIRAT (Nullifiers / Rollback Triggers):**
|
||||
- Any user-reported incident of *riya’* (e.g., “I feel like I’m competing with my friend instead of focusing on Allah”) – immediate rollback and re-design.
|
||||
- A/B test shows that the private tracker reduces daily active usage by more than 20% compared to control (without tracker) – indicates we’ve added friction without purpose preservation.
|
||||
- Qualitative feedback from ≥2 users in the first week indicates that the feature is being used as a *trophy case* rather than a *reflection tool* – roll back and revisit JTBD.
|
||||
|
||||
---
|
||||
|
||||
## THE PROTOCOL (3 Steps – This Sprint)
|
||||
|
||||
**STEP 1: Build the private tracker MVP**
|
||||
Design a single-screen dashboard showing the user’s own 7-day streak of the three core habits (e.g., Fajr on time, daily Quran page, evening adhkar). No badges, no points, no leaderboard. Use a simple green checkmark system. Ship behind feature flag to 10% of active users. *(Time: 3 days)*
|
||||
|
||||
**STEP 2: Collect *niyyah* data**
|
||||
Add an in-app micro-survey after 2 days of use: “On a scale of 1–5, how much does this tracker help you focus on your intention (niyyah) for worship?” Also track feature usage (clicks, time spent). *(Time: 5 days continuous)*
|
||||
|
||||
**STEP 3: Review and decide on expansion**
|
||||
If the *niyyah* score is ≥4.0 and no *riya’* incidents are reported, expand to 50% of users and begin designing a “close accountability partner” sharing feature (one-to-one, non‑competitive). If score <3.5, roll back the feature and schedule a new discovery sprint to understand what users actually need. *(Time: end of sprint)*
|
||||
|
||||
---
|
||||
|
||||
## MUHASABA (RETROSPECTIVE)
|
||||
|
||||
**What did we learn about our own willingness to sacrifice user engagement metrics for preserving spiritual purpose, and where did we feel the strongest temptation to compromise because of board pressure or growth targets?**
|
||||
|
||||
The most uncomfortable insight was that our team hesitated to kill the leaderboard idea because it promised easy retention numbers. The *Fatwa* forced us to ask: “Are we building for Allah’s pleasure or for our vanity as product builders?” The next sprint, we will pre‑commit to a *Shura* check before any feature with social elements enters development.
|
||||
@@ -0,0 +1,141 @@
|
||||
# FATWA #5: MINIMUM VIABLE FATWA — MVP AS MINIMUM VIABLE FATWA
|
||||
|
||||
**MAQSAD:** Hifz al-Mal (Preservation of Wealth)
|
||||
**FRAMEWORK:** MVP Quadrant — Viable / Valuable / Usable / Feasible
|
||||
**MAQSAD TRANSLATION:** MVP = Minimum Viable Fatwa
|
||||
|
||||
---
|
||||
|
||||
## 1. THE SCENARIO
|
||||
|
||||
You're the Product Lead at a growing Islamic fintech startup. Your CEO bursts into your weekly sync: "Why are we spending two sprints on this feature? Just ship the basic version and iterate." You feel the tension—move fast vs. build right. Your engineering lead pushes back: "We don't even know if users want this. Let's cut scope to the bone." Your head of Shariah compliance frowns: "We can't launch an incomplete ruling. It's either halal or haram."
|
||||
|
||||
You open your notebook. The **PRODUCT_LEAD** in you thinks: *Continuous discovery, outcome over output, ship to learn.* The **MUJTAHID** in you asks: *What is the hukm? What is the maqsad? What is the minimum evidence required before a ruling is valid?*
|
||||
|
||||
You realize: the classic MVP debate is actually a classical fatwa debate. The question isn't "how little can we build?"—it's "what is the *minimum viable fatwa*?" Enough evidence. Enough confidence. Enough scope to make a decision that protects wealth (Hifz al-Mal) without wasting it on overbuilding or underbuilding.
|
||||
|
||||
---
|
||||
|
||||
## 2. DISCOVERY (ISTIQSA')
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Draw four boxes. Label them: *Viable, Valuable, Usable, Feasible.* This is the MVP Quadrant. Your job in discovery is to map the problem space onto these four boxes before you write a single line of code.
|
||||
|
||||
- **Viable:** Does this feature sustain the business? Does it align with our North Star? Will it generate the outcome we need?
|
||||
- **Valuable:** Do users actually care? What's the Job-to-be-Done? What's the unmet need?
|
||||
- **Usable:** Can users figure it out without a manual? Is the experience frictionless?
|
||||
- **Feasible:** Can we build it with our current tech, team, and timeline? What's the risk?
|
||||
|
||||
Start with an Opportunity Solution Tree. At the root: *Users are abandoning our savings product because they don't trust the profit calculation.* Branch into opportunities: *Transparency of calculation* | *Real-time visibility* | *Shariah audit trail.* Then solution ideas: *Dashboard showing daily accrual* | *Push notification for each profit event* | *PDF export of calculation methodology.*
|
||||
|
||||
Interview 5 users this week. Job story: "When I check my savings balance, I want to see exactly how my profit was calculated, so I can trust it's Shariah-compliant and not lose sleep over riba concerns."
|
||||
|
||||
**MUJTAHID:**
|
||||
Istiqsa' means exhaustive exploration of the problem domain. In Usul al-Fiqh, you don't issue a fatwa until you've fully understood the *waqi'* (reality). The Mujtahid's discovery mirrors the Product Lead's discovery—but with an explicit Maqasid lens.
|
||||
|
||||
Ask: What is the *maqsad* we are protecting? Here, Hifz al-Mal (Preservation of Wealth). The product must not waste user wealth (overbuilding) nor expose it to risk (underbuilding). The MVP must be a *minimum viable fatwa*—a ruling that is *valid enough* to act upon, knowing that a more complete ruling can follow.
|
||||
|
||||
Mapping to the MVP Quadrant:
|
||||
|
||||
- **Viable (Hifz al-Mal):** Does this feature generate or protect wealth for the company and the user? If it costs more to build than it returns, it violates Hifz al-Mal.
|
||||
- **Valuable (Hifz al-Din + Hifz al-Aql):** Does it preserve the user's religious commitment and mental clarity? If the feature is confusing or ambiguous about Shariah compliance, it harms both.
|
||||
- **Usable (Hifz al-Nafs):** Does it cause frustration or stress? A bad UX violates psychological well-being.
|
||||
- **Feasible (Hifz al-Nasl):** Does our team have the capacity? Overworking the team harms future generations of products (and future children of exhausted engineers).
|
||||
|
||||
The minimum viable fatwa is not the smallest possible feature—it's the smallest feature that *satisfies all four conditions simultaneously* with acceptable risk. In classical fatwa, a Mujtahid may issue a *fatwa mu'allaqa* (conditional ruling) when evidence is partial but sufficient for action. That's your MVP.
|
||||
|
||||
---
|
||||
|
||||
## 3. EVIDENCE (ISTIDLAL)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Gather two types of evidence: quantitative and qualitative.
|
||||
|
||||
- **Quantitative:** Analytics on the current savings product. Drop-off rate at the profit explanation screen? 72% abandonment. Average time on page? 14 seconds. That's a signal—users don't understand or don't trust.
|
||||
- **Qualitative:** User interviews. "I don't know how they calculate profit. I just hope it's halal." "I've seen other fintechs get fatwas, but I never see the math." "If I could see the calculation step-by-step, I'd put more money in."
|
||||
|
||||
Now prioritize using the Opportunity Solution Tree. Rank opportunities by *impact* and *confidence.* Highest impact: *Transparency of calculation.* Highest confidence: *Users want to see the breakdown.*
|
||||
|
||||
Run a small experiment: Show a prototype of a simple profit breakdown to 5 users. Do they understand it? Do they trust it? Measure *comprehension* and *trust score* (1-5). Baseline: 2.3 trust score. Target: 4.0. That's your validation metric.
|
||||
|
||||
**MUJTAHID:**
|
||||
In Usul al-Fiqh, daleel (evidence) is ranked by strength: *Qati' al-Thubut* (certain transmission) and *Qati' al-Dalala* (certain meaning). For an MVP, you don't need *qati'* evidence for every feature—you need *zanni* (probable) evidence sufficient for action.
|
||||
|
||||
Analogous hierarchy for product evidence:
|
||||
|
||||
- **Qati' al-Thubut (certain transmission):** Data from your own product analytics. This is direct observation. High certainty.
|
||||
- **Qati' al-Dalala (certain meaning):** A user explicitly says "I will deposit more if I see the calculation." That's a clear signal.
|
||||
- **Zanni (probable):** Survey results with 70% agreement. User behavior patterns (e.g., hovering over the profit field). Probable but not certain.
|
||||
|
||||
For the MVP, you need at least *zanni* evidence on all four MVP Quadrant dimensions. That's the minimum threshold for a *fatwa mu'allaqa*—a conditional ruling that can be revised as stronger evidence emerges.
|
||||
|
||||
*Example:* You have strong quantitative evidence (drop-off rate) but only weak qualitative evidence (2 user interviews). That's *zanni* on Valuable. You can proceed with the MVP, but you must include a mechanism to gather more evidence post-launch (e.g., A/B test, feedback widget). In classical fatwa, the Mujtahid issues the ruling *with conditions*: "This ruling stands as long as no stronger evidence contradicts it."
|
||||
|
||||
Daleel also includes *istishab* (presumption of continuity). You can presume the current behavior will continue unless evidence shows otherwise. So if users currently abandon at the profit screen, presume they will continue to abandon—and your MVP must change that.
|
||||
|
||||
---
|
||||
|
||||
## 4. SHURA
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Call a cross-functional sync. Invite: Engineering lead, Design lead, Head of Shariah, Customer support manager, your CEO. Agenda: "What is the minimum viable feature for profit transparency?"
|
||||
|
||||
Pre-work: Each stakeholder completes a one-pager: *What outcome do you need? What risk do you see? What's your non-negotiable?*
|
||||
|
||||
During Shura:
|
||||
|
||||
- **Engineering:** "We can build a static PDF with calculation methodology in 2 weeks. Anything interactive takes 6 weeks."
|
||||
- **Design:** "A static PDF is not usable. Users won't read it. We need a dynamic dashboard."
|
||||
- **Shariah:** "The calculation methodology must be reviewed by our board. We need to ensure no hidden riba. That takes 1 week."
|
||||
- **Support:** "Users are calling daily. They don't trust the numbers. Anything that shows the math will reduce tickets."
|
||||
- **CEO:** "We need to ship something in 2 weeks. Investor demo is coming."
|
||||
|
||||
You facilitate. Record each position. Weight by *maqsad* (Hifz al-Mal). The highest weight goes to *usable*? Or *viable*? You decide.
|
||||
|
||||
**MUJTAHID:**
|
||||
Shura in Usul al-Fiqh is not a democratic vote—it's a consultation of qualified experts. The Mujtahid listens to all, weighs evidence, and then issues the hukm. Dissenting opinions are recorded for future reference.
|
||||
|
||||
Your Shura here: Each stakeholder brings a *daleel* (evidence) from their domain. Engineering's daleel is *feasibility* (time/cost). Design's daleel is *usability* (user comprehension). Shariah's daleel is *validity* (compliance). Support's daleel is *user pain* (frequency of complaints). CEO's daleel is *business viability* (investor confidence).
|
||||
|
||||
You, as the Product Lead (Mujtahid), must *tarjih* (weigh) these evidences. The strongest daleel in this case? The user's voice—the one who said "I will deposit more if I see the calculation." That's *qati' al-dalala* (clear meaning) and *zanni al-thubut* (from a small sample). Combine it with the quantitative drop-off rate (*qati' al-thubut*). That's your strongest evidence.
|
||||
|
||||
Record dissent: Engineering wants to ship static PDF. Design wants interactive dashboard. You rule: *Static PDF as MVP, with a commitment to upgrade to dashboard within 4 weeks if trust score rises.* That's a conditional fatwa—binding but temporary.
|
||||
|
||||
End of Part 1. Part 2 will deliver the Fatwa (Hukm), Protocol, and Muhasaba.## THE FATWA (HUKM)
|
||||
|
||||
**HUKM:** We will ship an MVP that passes all four quadrants of the MVP Quadrant (Viable, Valuable, Usable, Feasible) with explicit shurut (conditions) for each quadrant, and we will treat this MVP as a *minimum viable fatwa* — a product decision that is Islamically sound (hukm shar‘i) only when it preserves wealth (Hifz al-Mal) by avoiding waste, and we will roll back immediately if any quadrant is invalidated.
|
||||
|
||||
**DALEEL:** Discovery interviews (istiqsa’) revealed that 70% of past MVPs failed because teams prioritized speed over viability (business model unsound) or usability (user gave up). Quantitative data showed that MVPs launched without a feasibility check cost 3x more in rework. The Shura consultation confirmed that stakeholders value a "fatwa-like" rigor: clear conditions (shurut) and nullifiers (munkathirat) to prevent reckless spending. The maqsad of Hifz al-Mal is directly served by ensuring that each quadrant's evidence is weighted as *qati‘* (certain) for viability and feasibility, and *zanni* (probable) for value and usability — we ship on zanni but with a safety net.
|
||||
|
||||
**MAQSAD:** Hifz al-Mal (Preservation of Wealth). By enforcing the MVP Quadrant as a *fatwa* with shurut and munkathirat, we prevent the waste of engineering hours, marketing budget, and user trust. This also serves Hifz al-‘Aql (Preservation of Intellect) by forcing disciplined decision-making.
|
||||
|
||||
**SHURUT (Conditions/Constraints):**
|
||||
- **Viability metric:** The MVP must demonstrate a unit economics path to sustainability (e.g., LTV > 3× CAC) within 4 weeks of launch. If not proven, the fatwa is suspended.
|
||||
- **Value metric:** At least 40% of first 100 users must reach the "aha moment" (defined as completing the core JTBD) within 7 days of signup. If < 40%, investigate and iterate; if < 20% after 2 weeks, rollback.
|
||||
- **Usability metric:** Task success rate on the primary flow must be ≥ 80% in the first 200 sessions. If < 60%, stop and fix before scaling.
|
||||
- **Feasibility metric:** The MVP must be built with ≤ 3 engineering sprints (6 weeks total). If scope creep exceeds 20% of original estimate, the team must re-evaluate the fatwa.
|
||||
|
||||
**MUNKATHIRAT (Nullifiers / Rollback Triggers):**
|
||||
- Any quadrant metric falls below the minimum threshold for two consecutive weeks → fatwa is nullified; ship revert to previous stable version.
|
||||
- A major security or data privacy issue discovered post-launch → immediate rollback (Hifz al-‘Aql and Hifz al-Mal jointly override).
|
||||
- User behavior reveals that the core JTBD is fundamentally misunderstood (e.g., < 5% repeat usage after 30 days) → fatwa is invalid; return to Discovery phase.
|
||||
|
||||
---
|
||||
|
||||
## THE PROTOCOL
|
||||
|
||||
**STEP 1: Define your four quadrant metrics (this sprint).**
|
||||
Gather the product trio (PM, designer, tech lead) and write down one measurable criterion for each quadrant: Viability (e.g., 10% week-over-week retention), Value (e.g., 50% of users share output), Usability (e.g., < 2 support tickets per 100 sessions), Feasibility (e.g., build within 4 sprints). Post these on the wall. These are your *shurut*.
|
||||
|
||||
**STEP 2: Build the MVP with a “fatwa rollback” branch (this sprint).**
|
||||
During development, treat each sprint as a *mujtahid’s review*: at the end of each sprint, check the four metrics against your shurut. If any metric is at risk, call a “Shura huddle” with stakeholders. Do not advance to the next sprint unless all four shurut are green. This is *continuous fatwa validation*.
|
||||
|
||||
**STEP 3: Launch with a 2-week “istishab” (presumption of continuity) period.**
|
||||
Ship to a 10% user segment. Set up a dashboard with the four quadrant metrics live. Every Monday morning, review as a team: are we still within our shurut? If any munkathir fires, execute the rollback script (pre‑written). After two weeks, if all metrics pass, the fatwa becomes *mu‘tamad* (adopted) and you scale to 100%. If not, you have evidence to iterate or kill.
|
||||
|
||||
---
|
||||
|
||||
## MUHASABA (RETROSPECTIVE)
|
||||
|
||||
**What did we learn about our own appetite for uncertainty when we had to define a “minimum viable fatwa” rather than a “minimum viable product”?**
|
||||
Did we actually write shurut that felt scary, or did we write safe metrics that guarantee we never have to roll back? The discomfort of a true munkathir is the point: if your nullifiers never fire, you didn’t set them tightly enough. Next time, ask: *Which of our four quadrant metrics would actually hurt if we missed it?* That’s the one that preserves our maqsad.
|
||||
@@ -0,0 +1,104 @@
|
||||
# FATWA #5: MINIMUM VIABLE FATWA — MVP AS MINIMUM VIABLE FATWA
|
||||
|
||||
**MAQSAD:** Hifz al-Mal (Preservation of Wealth)
|
||||
**FRAMEWORK:** MVP Quadrant — Viable / Valuable / Usable / Feasible
|
||||
**MAQSAD TRANSLATION:** MVP = Minimum Viable Fatwa
|
||||
|
||||
---
|
||||
|
||||
## 1. THE SCENARIO
|
||||
|
||||
You're the Product Lead at a growing Islamic fintech startup. Your CEO bursts into your weekly sync: "Why are we spending two sprints on this feature? Just ship the basic version and iterate." You feel the tension—move fast vs. build right. Your engineering lead pushes back: "We don't even know if users want this. Let's cut scope to the bone." Your head of Shariah compliance frowns: "We can't launch an incomplete ruling. It's either halal or haram."
|
||||
|
||||
You open your notebook. The **PRODUCT_LEAD** in you thinks: *Continuous discovery, outcome over output, ship to learn.* The **MUJTAHID** in you asks: *What is the hukm? What is the maqsad? What is the minimum evidence required before a ruling is valid?*
|
||||
|
||||
You realize: the classic MVP debate is actually a classical fatwa debate. The question isn't "how little can we build?"—it's "what is the *minimum viable fatwa*?" Enough evidence. Enough confidence. Enough scope to make a decision that protects wealth (Hifz al-Mal) without wasting it on overbuilding or underbuilding.
|
||||
|
||||
---
|
||||
|
||||
## 2. DISCOVERY (ISTIQSA')
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Draw four boxes. Label them: *Viable, Valuable, Usable, Feasible.* This is the MVP Quadrant. Your job in discovery is to map the problem space onto these four boxes before you write a single line of code.
|
||||
|
||||
- **Viable:** Does this feature sustain the business? Does it align with our North Star? Will it generate the outcome we need?
|
||||
- **Valuable:** Do users actually care? What's the Job-to-be-Done? What's the unmet need?
|
||||
- **Usable:** Can users figure it out without a manual? Is the experience frictionless?
|
||||
- **Feasible:** Can we build it with our current tech, team, and timeline? What's the risk?
|
||||
|
||||
Start with an Opportunity Solution Tree. At the root: *Users are abandoning our savings product because they don't trust the profit calculation.* Branch into opportunities: *Transparency of calculation* | *Real-time visibility* | *Shariah audit trail.* Then solution ideas: *Dashboard showing daily accrual* | *Push notification for each profit event* | *PDF export of calculation methodology.*
|
||||
|
||||
Interview 5 users this week. Job story: "When I check my savings balance, I want to see exactly how my profit was calculated, so I can trust it's Shariah-compliant and not lose sleep over riba concerns."
|
||||
|
||||
**MUJTAHID:**
|
||||
Istiqsa' means exhaustive exploration of the problem domain. In Usul al-Fiqh, you don't issue a fatwa until you've fully understood the *waqi'* (reality). The Mujtahid's discovery mirrors the Product Lead's discovery—but with an explicit Maqasid lens.
|
||||
|
||||
Ask: What is the *maqsad* we are protecting? Here, Hifz al-Mal (Preservation of Wealth). The product must not waste user wealth (overbuilding) nor expose it to risk (underbuilding). The MVP must be a *minimum viable fatwa*—a ruling that is *valid enough* to act upon, knowing that a more complete ruling can follow.
|
||||
|
||||
Mapping to the MVP Quadrant:
|
||||
|
||||
- **Viable (Hifz al-Mal):** Does this feature generate or protect wealth for the company and the user? If it costs more to build than it returns, it violates Hifz al-Mal.
|
||||
- **Valuable (Hifz al-Din + Hifz al-Aql):** Does it preserve the user's religious commitment and mental clarity? If the feature is confusing or ambiguous about Shariah compliance, it harms both.
|
||||
- **Usable (Hifz al-Nafs):** Does it cause frustration or stress? A bad UX violates psychological well-being.
|
||||
- **Feasible (Hifz al-Nasl):** Does our team have the capacity? Overworking the team harms future generations of products (and future children of exhausted engineers).
|
||||
|
||||
The minimum viable fatwa is not the smallest possible feature—it's the smallest feature that *satisfies all four conditions simultaneously* with acceptable risk. In classical fatwa, a Mujtahid may issue a *fatwa mu'allaqa* (conditional ruling) when evidence is partial but sufficient for action. That's your MVP.
|
||||
|
||||
---
|
||||
|
||||
## 3. EVIDENCE (ISTIDLAL)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Gather two types of evidence: quantitative and qualitative.
|
||||
|
||||
- **Quantitative:** Analytics on the current savings product. Drop-off rate at the profit explanation screen? 72% abandonment. Average time on page? 14 seconds. That's a signal—users don't understand or don't trust.
|
||||
- **Qualitative:** User interviews. "I don't know how they calculate profit. I just hope it's halal." "I've seen other fintechs get fatwas, but I never see the math." "If I could see the calculation step-by-step, I'd put more money in."
|
||||
|
||||
Now prioritize using the Opportunity Solution Tree. Rank opportunities by *impact* and *confidence.* Highest impact: *Transparency of calculation.* Highest confidence: *Users want to see the breakdown.*
|
||||
|
||||
Run a small experiment: Show a prototype of a simple profit breakdown to 5 users. Do they understand it? Do they trust it? Measure *comprehension* and *trust score* (1-5). Baseline: 2.3 trust score. Target: 4.0. That's your validation metric.
|
||||
|
||||
**MUJTAHID:**
|
||||
In Usul al-Fiqh, daleel (evidence) is ranked by strength: *Qati' al-Thubut* (certain transmission) and *Qati' al-Dalala* (certain meaning). For an MVP, you don't need *qati'* evidence for every feature—you need *zanni* (probable) evidence sufficient for action.
|
||||
|
||||
Analogous hierarchy for product evidence:
|
||||
|
||||
- **Qati' al-Thubut (certain transmission):** Data from your own product analytics. This is direct observation. High certainty.
|
||||
- **Qati' al-Dalala (certain meaning):** A user explicitly says "I will deposit more if I see the calculation." That's a clear signal.
|
||||
- **Zanni (probable):** Survey results with 70% agreement. User behavior patterns (e.g., hovering over the profit field). Probable but not certain.
|
||||
|
||||
For the MVP, you need at least *zanni* evidence on all four MVP Quadrant dimensions. That's the minimum threshold for a *fatwa mu'allaqa*—a conditional ruling that can be revised as stronger evidence emerges.
|
||||
|
||||
*Example:* You have strong quantitative evidence (drop-off rate) but only weak qualitative evidence (2 user interviews). That's *zanni* on Valuable. You can proceed with the MVP, but you must include a mechanism to gather more evidence post-launch (e.g., A/B test, feedback widget). In classical fatwa, the Mujtahid issues the ruling *with conditions*: "This ruling stands as long as no stronger evidence contradicts it."
|
||||
|
||||
Daleel also includes *istishab* (presumption of continuity). You can presume the current behavior will continue unless evidence shows otherwise. So if users currently abandon at the profit screen, presume they will continue to abandon—and your MVP must change that.
|
||||
|
||||
---
|
||||
|
||||
## 4. SHURA
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Call a cross-functional sync. Invite: Engineering lead, Design lead, Head of Shariah, Customer support manager, your CEO. Agenda: "What is the minimum viable feature for profit transparency?"
|
||||
|
||||
Pre-work: Each stakeholder completes a one-pager: *What outcome do you need? What risk do you see? What's your non-negotiable?*
|
||||
|
||||
During Shura:
|
||||
|
||||
- **Engineering:** "We can build a static PDF with calculation methodology in 2 weeks. Anything interactive takes 6 weeks."
|
||||
- **Design:** "A static PDF is not usable. Users won't read it. We need a dynamic dashboard."
|
||||
- **Shariah:** "The calculation methodology must be reviewed by our board. We need to ensure no hidden riba. That takes 1 week."
|
||||
- **Support:** "Users are calling daily. They don't trust the numbers. Anything that shows the math will reduce tickets."
|
||||
- **CEO:** "We need to ship something in 2 weeks. Investor demo is coming."
|
||||
|
||||
You facilitate. Record each position. Weight by *maqsad* (Hifz al-Mal). The highest weight goes to *usable*? Or *viable*? You decide.
|
||||
|
||||
**MUJTAHID:**
|
||||
Shura in Usul al-Fiqh is not a democratic vote—it's a consultation of qualified experts. The Mujtahid listens to all, weighs evidence, and then issues the hukm. Dissenting opinions are recorded for future reference.
|
||||
|
||||
Your Shura here: Each stakeholder brings a *daleel* (evidence) from their domain. Engineering's daleel is *feasibility* (time/cost). Design's daleel is *usability* (user comprehension). Shariah's daleel is *validity* (compliance). Support's daleel is *user pain* (frequency of complaints). CEO's daleel is *business viability* (investor confidence).
|
||||
|
||||
You, as the Product Lead (Mujtahid), must *tarjih* (weigh) these evidences. The strongest daleel in this case? The user's voice—the one who said "I will deposit more if I see the calculation." That's *qati' al-dalala* (clear meaning) and *zanni al-thubut* (from a small sample). Combine it with the quantitative drop-off rate (*qati' al-thubut*). That's your strongest evidence.
|
||||
|
||||
Record dissent: Engineering wants to ship static PDF. Design wants interactive dashboard. You rule: *Static PDF as MVP, with a commitment to upgrade to dashboard within 4 weeks if trust score rises.* That's a conditional fatwa—binding but temporary.
|
||||
|
||||
End of Part 1. Part 2 will deliver the Fatwa (Hukm), Protocol, and Muhasaba.
|
||||
@@ -0,0 +1,38 @@
|
||||
## THE FATWA (HUKM)
|
||||
|
||||
**HUKM:** We will ship an MVP that passes all four quadrants of the MVP Quadrant (Viable, Valuable, Usable, Feasible) with explicit shurut (conditions) for each quadrant, and we will treat this MVP as a *minimum viable fatwa* — a product decision that is Islamically sound (hukm shar‘i) only when it preserves wealth (Hifz al-Mal) by avoiding waste, and we will roll back immediately if any quadrant is invalidated.
|
||||
|
||||
**DALEEL:** Discovery interviews (istiqsa’) revealed that 70% of past MVPs failed because teams prioritized speed over viability (business model unsound) or usability (user gave up). Quantitative data showed that MVPs launched without a feasibility check cost 3x more in rework. The Shura consultation confirmed that stakeholders value a "fatwa-like" rigor: clear conditions (shurut) and nullifiers (munkathirat) to prevent reckless spending. The maqsad of Hifz al-Mal is directly served by ensuring that each quadrant's evidence is weighted as *qati‘* (certain) for viability and feasibility, and *zanni* (probable) for value and usability — we ship on zanni but with a safety net.
|
||||
|
||||
**MAQSAD:** Hifz al-Mal (Preservation of Wealth). By enforcing the MVP Quadrant as a *fatwa* with shurut and munkathirat, we prevent the waste of engineering hours, marketing budget, and user trust. This also serves Hifz al-‘Aql (Preservation of Intellect) by forcing disciplined decision-making.
|
||||
|
||||
**SHURUT (Conditions/Constraints):**
|
||||
- **Viability metric:** The MVP must demonstrate a unit economics path to sustainability (e.g., LTV > 3× CAC) within 4 weeks of launch. If not proven, the fatwa is suspended.
|
||||
- **Value metric:** At least 40% of first 100 users must reach the "aha moment" (defined as completing the core JTBD) within 7 days of signup. If < 40%, investigate and iterate; if < 20% after 2 weeks, rollback.
|
||||
- **Usability metric:** Task success rate on the primary flow must be ≥ 80% in the first 200 sessions. If < 60%, stop and fix before scaling.
|
||||
- **Feasibility metric:** The MVP must be built with ≤ 3 engineering sprints (6 weeks total). If scope creep exceeds 20% of original estimate, the team must re-evaluate the fatwa.
|
||||
|
||||
**MUNKATHIRAT (Nullifiers / Rollback Triggers):**
|
||||
- Any quadrant metric falls below the minimum threshold for two consecutive weeks → fatwa is nullified; ship revert to previous stable version.
|
||||
- A major security or data privacy issue discovered post-launch → immediate rollback (Hifz al-‘Aql and Hifz al-Mal jointly override).
|
||||
- User behavior reveals that the core JTBD is fundamentally misunderstood (e.g., < 5% repeat usage after 30 days) → fatwa is invalid; return to Discovery phase.
|
||||
|
||||
---
|
||||
|
||||
## THE PROTOCOL
|
||||
|
||||
**STEP 1: Define your four quadrant metrics (this sprint).**
|
||||
Gather the product trio (PM, designer, tech lead) and write down one measurable criterion for each quadrant: Viability (e.g., 10% week-over-week retention), Value (e.g., 50% of users share output), Usability (e.g., < 2 support tickets per 100 sessions), Feasibility (e.g., build within 4 sprints). Post these on the wall. These are your *shurut*.
|
||||
|
||||
**STEP 2: Build the MVP with a “fatwa rollback” branch (this sprint).**
|
||||
During development, treat each sprint as a *mujtahid’s review*: at the end of each sprint, check the four metrics against your shurut. If any metric is at risk, call a “Shura huddle” with stakeholders. Do not advance to the next sprint unless all four shurut are green. This is *continuous fatwa validation*.
|
||||
|
||||
**STEP 3: Launch with a 2-week “istishab” (presumption of continuity) period.**
|
||||
Ship to a 10% user segment. Set up a dashboard with the four quadrant metrics live. Every Monday morning, review as a team: are we still within our shurut? If any munkathir fires, execute the rollback script (pre‑written). After two weeks, if all metrics pass, the fatwa becomes *mu‘tamad* (adopted) and you scale to 100%. If not, you have evidence to iterate or kill.
|
||||
|
||||
---
|
||||
|
||||
## MUHASABA (RETROSPECTIVE)
|
||||
|
||||
**What did we learn about our own appetite for uncertainty when we had to define a “minimum viable fatwa” rather than a “minimum viable product”?**
|
||||
Did we actually write shurut that felt scary, or did we write safe metrics that guarantee we never have to roll back? The discomfort of a true munkathir is the point: if your nullifiers never fire, you didn’t set them tightly enough. Next time, ask: *Which of our four quadrant metrics would actually hurt if we missed it?* That’s the one that preserves our maqsad.
|
||||
@@ -0,0 +1,93 @@
|
||||
**FATWA #6: TECHNICAL DEBT — ISRAF VS INVESTMENT**
|
||||
*Maqasid: Hifz al-Mal (Preservation of Wealth)*
|
||||
*Framework: Debt Quadrant (Prudent / Reckless / Deliberate / Inadvertent)*
|
||||
|
||||
---
|
||||
|
||||
### 1. THE SCENARIO
|
||||
|
||||
You’re the Product Lead at a fast-growing fintech startup. The CEO bursts into your weekly sync: “Why did we spend two sprints rewriting the payment engine? We could have shipped three features in that time.” You open your notebook, but the Mujtahid in you pauses. *Is this rewrite actually Israf (waste)? Or is it an investment in Hifz al-Mal?* Your team has been accumulating debt for six months—copy-pasted modules, no tests, a hack to meet a launch deadline. Now the debt is compounding. Every new feature takes twice as long. The CEO smells waste. You smell a fatwa coming.
|
||||
|
||||
---
|
||||
|
||||
### 2. DISCOVERY (ISTIQSA’)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Don’t define technical debt yet. First, explore the problem space. Grab the Opportunity Solution Tree. Write the desired outcome on the left: *“Ship features predictably without degrading system health.”* Now branch backward: What stops us? You interview four engineers. Three say the same thing: “Every new feature requires a detour through the old payment code. We spend 40% of our time just understanding the spaghetti.” That’s the *opportunity*—reduce cognitive drag. Use Jobs-to-be-Done: The engineer’s job is *“When I add a new payment method, I want to do it in one afternoon, not two weeks, so I can stay focused on the user problem.”* The current solution (hack, copy, pray) fails the job. The debt is a symptom, not the disease.
|
||||
|
||||
**MUJTAHID:**
|
||||
*Istiqsa’* means exhaustive inquiry into the reality of the situation. Let’s define the *hukm* (ruling) on this debt. First, clarify *Israf* in Islamic finance. Allah says: *“And do not waste [israf], indeed He does not like the wasteful”* (Qur’an 7:31). Israf is spending wealth without benefit or beyond need. But is all technical debt Israf? No. The *Maqasid* principle: *Hifz al-Mal* (preservation of wealth) doesn’t forbid investment—it forbids *wasteful* consumption. So the key question: *Is this debt a consumption (Israf) or an investment (Mudaraba)?*
|
||||
Draw the **Debt Quadrant**:
|
||||
|
||||
| | **Deliberate** | **Inadvertent** |
|
||||
|----------------|-------------------------------|--------------------------------|
|
||||
| **Prudent** | Planned, time-boxed, tracked | Known but neglected |
|
||||
| **Reckless** | Unplanned, no ceiling | Unknown, compounding |
|
||||
|
||||
Your team’s debt—copy-pasted modules, no tests—falls into *Reckless Inadvertent*. That’s closest to Israf because the wealth (time, focus, future velocity) is consumed without a clear *maslaha* (benefit). The *maqsad* of Hifz al-Mal demands you classify every line of debt: Is it a *qard hasan* (benevolent loan) to buy speed? Or a *riba* (usurious debt) that compounds? Your discovery must surface the *niyya* (intention) and the *shurut* (conditions) that made the debt necessary.
|
||||
|
||||
---
|
||||
|
||||
### 3. EVIDENCE (ISTIDLAL)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Now gather daleel—evidence. Quantitative: Measure the *interest rate* of the debt. Time per story point in the payment module vs. a clean module. You pull Jira data: average cycle time for payment features is 14 days; for user profile features, 4 days. That’s a 250% penalty. Qualitative: Interview three more engineers. One says: “Every time I touch the payment code, I pray it doesn’t break. We have no test coverage—so we test in production.” That’s a *risk premium*. Also check the *compounding*: the debt grows at 20% per sprint (new shortcuts added weekly). The North Star metric for engineering health: *Time to ship a low-risk change* (ideally <1 day). Currently: 4 days for payment. That’s the *daleel qati* (conclusive evidence) of harm.
|
||||
|
||||
**MUJTAHID:**
|
||||
Hierarchy of daleel:
|
||||
1. **Qati al-Thubut wa Qati al-Dalala** (conclusive transmission and meaning): The metric above—14 vs 4 days—is *qati* in proof (data from your system) and *qati* in implication (the debt is real and measurable). This is like a *nas* (clear text).
|
||||
2. **Zanni al-Thubut wa Qati al-Dalala** (probable transmission but clear meaning): Engineer interviews—they *might* exaggerate, but the pattern is consistent. Accept as *zanni* support.
|
||||
3. **Maslaha Mursala** (unregulated public interest): Is there any *maslaha* in keeping this debt? The CEO argues: “We shipped faster to capture market.” That’s a *maslaha* claim. But apply *sadd al-dhara’i* (blocking the means to harm): The debt now *blocks* future shipping. The original *maslaha* is gone.
|
||||
Also measure the *opportunity cost* (a form of *israf*): The team spent 40% of time on workarounds. That is *zaman mu’attal* (wasted time) which is a form of *itlaf al-mal* (destruction of wealth). Use *qiyas*: If a merchant spends money on a broken cart that slows his trade, the *hukm* is he must repair it to avoid *israf*. Analogously, you must fix the debt. Evidence is clear: the debt is *munkhir* (nullifier) of future velocity.
|
||||
|
||||
---
|
||||
|
||||
### 4. SHURA
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Call a cross-functional shura. Invite: 2 engineers (from payment team), 1 QA, 1 product designer, the CEO. Agenda: “We have evidence of debt compounding. What do we do?” Listen first. Engineers say: “We can’t keep shipping like this. It’s demoralizing.” CEO says: “We need to ship the new investment feature next month. Rewriting is a distraction.” The *shura* reveals a conflict: *velocity vs. sustainability*. Use Teresa Torres’s “Opportunity Solution Tree” to map: The CEO’s opportunity is *capture high‑value investors*. The engineer’s opportunity is *reduce cognitive load*. The *shura* must find a path that serves *both* Maqasid. Record dissent: Two engineers want a full rewrite; the CEO wants a quick hack. Document all positions as *arā* (opinions) to be weighed.
|
||||
|
||||
**MUJTAHID:**
|
||||
*Shura* is *fard* (obligatory) when the matter affects the *umma* (here, the team). The *Mujtahid* does not simply count votes; he weighs *dalālat al-shar’i* (legal indications). The CEO’s opinion has *maslaha* (market capture) but the engineer’s opinion has *darūra* (necessity for system survival). Apply the *qa’ida* (legal maxim): *“Al-ḍarar yuzāl”* (Harm must be removed). The debt harm is *muḥaqqaq* (verified). The market opportunity is *ẓannī* (speculative—competitors may not move). So the *shura* must tilt toward harm removal. Record the *mukhālif* (dissenter) and his *daleel*. The *shura* concludes: “We need a measured investment—not a full rewrite, but a targeted cleanup of the highest-interest debt.” Document as *ittifāq* (consensus) with the CEO’s condition: “No more than two sprints, and must enable the investment feature.” This is a *fatwa* in the making.
|
||||
|
||||
---
|
||||
|
||||
*End of Part 1. Continue to Part 2 for the Fatwa, Protocol, and Muhasaba.*## THE FATWA (HUKM)
|
||||
|
||||
**HUKM:** We will only incur technical debt that is **Deliberate and Prudent** (as per the Debt Quadrant) and immediately recorded with a repayment plan. **Reckless and Inadvertent debt is Israf** (waste of Hifz al-Mal) and must be repaid within the same sprint. **Zero tolerance for security, compliance, or data integrity debt** – that is always haram.
|
||||
|
||||
**DALEEL:** Discovery interviews revealed that 70% of our past “speed” decisions created untracked, compounding debt that later cost 3x the original effort to fix – a clear violation of Hifz al-Mal (waste of wealth) and Hifz al-Aql (mental overload). User evidence showed no feature value from the shortcuts, only bugs. The Debt Quadrant framework (Prudent/Reckless/Deliberate/Inadvertent) confirmed that our only valid quadrant is **Deliberate + Prudent** – where we consciously choose debt with a known payoff and a written exit plan.
|
||||
|
||||
**MAQSAD:** Primary: **Hifz al-Mal** – preserving engineering budget and avoiding waste of developer time and future maintenance costs. Secondary: **Hifz al-Aql** – protecting the team’s cognitive load and decision-making ability from chaotic code. Also supports **Hifz al-Din** (trustworthiness in delivering reliable software) and **Hifz al-Nasl** (sustainable product for future users/teams).
|
||||
|
||||
**SHURUT:**
|
||||
- Every technical debt decision must be logged in a **Debt Register** with: quadrant classification, estimated repayment cost, owner, and “repay by” date.
|
||||
- **Reckless** and **Inadvertent** debt that enters the codebase (e.g., from rushed hotfixes) must be repaid within **2 sprint cycles** or escalated to the Product Lead.
|
||||
- The team must allocate **at least 20% of each sprint** to debt reduction – this is a non-negotiable Shart (condition) for any new feature work.
|
||||
- **No debt** may be incurred on: authentication, payment, user data privacy, or any feature with legal/regulatory implications. Those are Qati (certain) obligations.
|
||||
|
||||
**MUNKATHIRAT:**
|
||||
- If a debt item causes a **production incident** (P0 or P1), the entire sprint is paused to repay it immediately – that debt is now Israf.
|
||||
- If the **Debt Register grows** beyond 10 items or the total estimated repayment exceeds 2 sprint cycles, the fatwa is automatically suspended and a new Shura must be called to re-evaluate the entire backlog.
|
||||
- If the team reports **burnout or confusion** due to debt (measured in weekly health checks), the debt is nullified – Hifz al-Aql takes precedence over all other Maqasid.
|
||||
|
||||
---
|
||||
|
||||
## THE PROTOCOL (3 Steps — This Sprint)
|
||||
|
||||
**STEP 1: Audit and Classify Your Current Debt**
|
||||
This Monday, gather the entire engineering team for a **45-minute Debt Quadrant mapping session**. List every known shortcut, hack, or workaround. Place each item into one of the four quadrants (Prudent/Reckless/Deliberate/Inadvertent). Any item in Reckless or Inadvertent gets a red “Israf” label and a **2-sprint deadline** for repayment.
|
||||
|
||||
**STEP 2: Create the Debt Register**
|
||||
By Wednesday, set up a shared document or tool (e.g., a spreadsheet or a GitHub project board). For each item, record: quadrant, description, estimated cleanup effort (story points), owner, and “repay by” date. Add a column for the **Maqsad impact**: which of the five Maqasid (Din, Nafs, Aql, Mal, Nasl) is harmed if left unpaid? This makes the cost tangible.
|
||||
|
||||
**STEP 3: Reserve 20% Capacity This Sprint**
|
||||
In the current sprint planning, **slice off 20% of the team’s capacity** for debt repayment. Do not negotiate this. Use the register to pick the highest priority item (start with anything that threatens Hifz al-Aql or Hifz al-Mal). If you have no prior debt, use this capacity to build a **routing slip** for future debt decisions – a simple checklist: “Is this decision Deliberate? Is it Prudent? Have we logged it?”
|
||||
|
||||
---
|
||||
|
||||
## MUHASABA (RETROSPECTIVE)
|
||||
|
||||
**Where are we tolerating Israf in the name of speed, and what is the true cost in terms of Hifz al-Mal and Hifz al-Aql?**
|
||||
|
||||
Ask this question at your next retrospective. Sit in silence for 60 seconds before anyone speaks. Then force the team to assign a **dollar figure** to each piece of untracked debt – the cost of the bug it caused, the hours of confusion, the delayed feature. This isn’t guilt; it’s a calibration. If you cannot name the cost, you are still in Israf. The moment you name it, you are one step closer to Hifz al-Mal.
|
||||
@@ -0,0 +1,55 @@
|
||||
**FATWA #6: TECHNICAL DEBT — ISRAF VS INVESTMENT**
|
||||
*Maqasid: Hifz al-Mal (Preservation of Wealth)*
|
||||
*Framework: Debt Quadrant (Prudent / Reckless / Deliberate / Inadvertent)*
|
||||
|
||||
---
|
||||
|
||||
### 1. THE SCENARIO
|
||||
|
||||
You’re the Product Lead at a fast-growing fintech startup. The CEO bursts into your weekly sync: “Why did we spend two sprints rewriting the payment engine? We could have shipped three features in that time.” You open your notebook, but the Mujtahid in you pauses. *Is this rewrite actually Israf (waste)? Or is it an investment in Hifz al-Mal?* Your team has been accumulating debt for six months—copy-pasted modules, no tests, a hack to meet a launch deadline. Now the debt is compounding. Every new feature takes twice as long. The CEO smells waste. You smell a fatwa coming.
|
||||
|
||||
---
|
||||
|
||||
### 2. DISCOVERY (ISTIQSA’)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Don’t define technical debt yet. First, explore the problem space. Grab the Opportunity Solution Tree. Write the desired outcome on the left: *“Ship features predictably without degrading system health.”* Now branch backward: What stops us? You interview four engineers. Three say the same thing: “Every new feature requires a detour through the old payment code. We spend 40% of our time just understanding the spaghetti.” That’s the *opportunity*—reduce cognitive drag. Use Jobs-to-be-Done: The engineer’s job is *“When I add a new payment method, I want to do it in one afternoon, not two weeks, so I can stay focused on the user problem.”* The current solution (hack, copy, pray) fails the job. The debt is a symptom, not the disease.
|
||||
|
||||
**MUJTAHID:**
|
||||
*Istiqsa’* means exhaustive inquiry into the reality of the situation. Let’s define the *hukm* (ruling) on this debt. First, clarify *Israf* in Islamic finance. Allah says: *“And do not waste [israf], indeed He does not like the wasteful”* (Qur’an 7:31). Israf is spending wealth without benefit or beyond need. But is all technical debt Israf? No. The *Maqasid* principle: *Hifz al-Mal* (preservation of wealth) doesn’t forbid investment—it forbids *wasteful* consumption. So the key question: *Is this debt a consumption (Israf) or an investment (Mudaraba)?*
|
||||
Draw the **Debt Quadrant**:
|
||||
|
||||
| | **Deliberate** | **Inadvertent** |
|
||||
|----------------|-------------------------------|--------------------------------|
|
||||
| **Prudent** | Planned, time-boxed, tracked | Known but neglected |
|
||||
| **Reckless** | Unplanned, no ceiling | Unknown, compounding |
|
||||
|
||||
Your team’s debt—copy-pasted modules, no tests—falls into *Reckless Inadvertent*. That’s closest to Israf because the wealth (time, focus, future velocity) is consumed without a clear *maslaha* (benefit). The *maqsad* of Hifz al-Mal demands you classify every line of debt: Is it a *qard hasan* (benevolent loan) to buy speed? Or a *riba* (usurious debt) that compounds? Your discovery must surface the *niyya* (intention) and the *shurut* (conditions) that made the debt necessary.
|
||||
|
||||
---
|
||||
|
||||
### 3. EVIDENCE (ISTIDLAL)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Now gather daleel—evidence. Quantitative: Measure the *interest rate* of the debt. Time per story point in the payment module vs. a clean module. You pull Jira data: average cycle time for payment features is 14 days; for user profile features, 4 days. That’s a 250% penalty. Qualitative: Interview three more engineers. One says: “Every time I touch the payment code, I pray it doesn’t break. We have no test coverage—so we test in production.” That’s a *risk premium*. Also check the *compounding*: the debt grows at 20% per sprint (new shortcuts added weekly). The North Star metric for engineering health: *Time to ship a low-risk change* (ideally <1 day). Currently: 4 days for payment. That’s the *daleel qati* (conclusive evidence) of harm.
|
||||
|
||||
**MUJTAHID:**
|
||||
Hierarchy of daleel:
|
||||
1. **Qati al-Thubut wa Qati al-Dalala** (conclusive transmission and meaning): The metric above—14 vs 4 days—is *qati* in proof (data from your system) and *qati* in implication (the debt is real and measurable). This is like a *nas* (clear text).
|
||||
2. **Zanni al-Thubut wa Qati al-Dalala** (probable transmission but clear meaning): Engineer interviews—they *might* exaggerate, but the pattern is consistent. Accept as *zanni* support.
|
||||
3. **Maslaha Mursala** (unregulated public interest): Is there any *maslaha* in keeping this debt? The CEO argues: “We shipped faster to capture market.” That’s a *maslaha* claim. But apply *sadd al-dhara’i* (blocking the means to harm): The debt now *blocks* future shipping. The original *maslaha* is gone.
|
||||
Also measure the *opportunity cost* (a form of *israf*): The team spent 40% of time on workarounds. That is *zaman mu’attal* (wasted time) which is a form of *itlaf al-mal* (destruction of wealth). Use *qiyas*: If a merchant spends money on a broken cart that slows his trade, the *hukm* is he must repair it to avoid *israf*. Analogously, you must fix the debt. Evidence is clear: the debt is *munkhir* (nullifier) of future velocity.
|
||||
|
||||
---
|
||||
|
||||
### 4. SHURA
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Call a cross-functional shura. Invite: 2 engineers (from payment team), 1 QA, 1 product designer, the CEO. Agenda: “We have evidence of debt compounding. What do we do?” Listen first. Engineers say: “We can’t keep shipping like this. It’s demoralizing.” CEO says: “We need to ship the new investment feature next month. Rewriting is a distraction.” The *shura* reveals a conflict: *velocity vs. sustainability*. Use Teresa Torres’s “Opportunity Solution Tree” to map: The CEO’s opportunity is *capture high‑value investors*. The engineer’s opportunity is *reduce cognitive load*. The *shura* must find a path that serves *both* Maqasid. Record dissent: Two engineers want a full rewrite; the CEO wants a quick hack. Document all positions as *arā* (opinions) to be weighed.
|
||||
|
||||
**MUJTAHID:**
|
||||
*Shura* is *fard* (obligatory) when the matter affects the *umma* (here, the team). The *Mujtahid* does not simply count votes; he weighs *dalālat al-shar’i* (legal indications). The CEO’s opinion has *maslaha* (market capture) but the engineer’s opinion has *darūra* (necessity for system survival). Apply the *qa’ida* (legal maxim): *“Al-ḍarar yuzāl”* (Harm must be removed). The debt harm is *muḥaqqaq* (verified). The market opportunity is *ẓannī* (speculative—competitors may not move). So the *shura* must tilt toward harm removal. Record the *mukhālif* (dissenter) and his *daleel*. The *shura* concludes: “We need a measured investment—not a full rewrite, but a targeted cleanup of the highest-interest debt.” Document as *ittifāq* (consensus) with the CEO’s condition: “No more than two sprints, and must enable the investment feature.” This is a *fatwa* in the making.
|
||||
|
||||
---
|
||||
|
||||
*End of Part 1. Continue to Part 2 for the Fatwa, Protocol, and Muhasaba.*
|
||||
@@ -0,0 +1,39 @@
|
||||
## THE FATWA (HUKM)
|
||||
|
||||
**HUKM:** We will only incur technical debt that is **Deliberate and Prudent** (as per the Debt Quadrant) and immediately recorded with a repayment plan. **Reckless and Inadvertent debt is Israf** (waste of Hifz al-Mal) and must be repaid within the same sprint. **Zero tolerance for security, compliance, or data integrity debt** – that is always haram.
|
||||
|
||||
**DALEEL:** Discovery interviews revealed that 70% of our past “speed” decisions created untracked, compounding debt that later cost 3x the original effort to fix – a clear violation of Hifz al-Mal (waste of wealth) and Hifz al-Aql (mental overload). User evidence showed no feature value from the shortcuts, only bugs. The Debt Quadrant framework (Prudent/Reckless/Deliberate/Inadvertent) confirmed that our only valid quadrant is **Deliberate + Prudent** – where we consciously choose debt with a known payoff and a written exit plan.
|
||||
|
||||
**MAQSAD:** Primary: **Hifz al-Mal** – preserving engineering budget and avoiding waste of developer time and future maintenance costs. Secondary: **Hifz al-Aql** – protecting the team’s cognitive load and decision-making ability from chaotic code. Also supports **Hifz al-Din** (trustworthiness in delivering reliable software) and **Hifz al-Nasl** (sustainable product for future users/teams).
|
||||
|
||||
**SHURUT:**
|
||||
- Every technical debt decision must be logged in a **Debt Register** with: quadrant classification, estimated repayment cost, owner, and “repay by” date.
|
||||
- **Reckless** and **Inadvertent** debt that enters the codebase (e.g., from rushed hotfixes) must be repaid within **2 sprint cycles** or escalated to the Product Lead.
|
||||
- The team must allocate **at least 20% of each sprint** to debt reduction – this is a non-negotiable Shart (condition) for any new feature work.
|
||||
- **No debt** may be incurred on: authentication, payment, user data privacy, or any feature with legal/regulatory implications. Those are Qati (certain) obligations.
|
||||
|
||||
**MUNKATHIRAT:**
|
||||
- If a debt item causes a **production incident** (P0 or P1), the entire sprint is paused to repay it immediately – that debt is now Israf.
|
||||
- If the **Debt Register grows** beyond 10 items or the total estimated repayment exceeds 2 sprint cycles, the fatwa is automatically suspended and a new Shura must be called to re-evaluate the entire backlog.
|
||||
- If the team reports **burnout or confusion** due to debt (measured in weekly health checks), the debt is nullified – Hifz al-Aql takes precedence over all other Maqasid.
|
||||
|
||||
---
|
||||
|
||||
## THE PROTOCOL (3 Steps — This Sprint)
|
||||
|
||||
**STEP 1: Audit and Classify Your Current Debt**
|
||||
This Monday, gather the entire engineering team for a **45-minute Debt Quadrant mapping session**. List every known shortcut, hack, or workaround. Place each item into one of the four quadrants (Prudent/Reckless/Deliberate/Inadvertent). Any item in Reckless or Inadvertent gets a red “Israf” label and a **2-sprint deadline** for repayment.
|
||||
|
||||
**STEP 2: Create the Debt Register**
|
||||
By Wednesday, set up a shared document or tool (e.g., a spreadsheet or a GitHub project board). For each item, record: quadrant, description, estimated cleanup effort (story points), owner, and “repay by” date. Add a column for the **Maqsad impact**: which of the five Maqasid (Din, Nafs, Aql, Mal, Nasl) is harmed if left unpaid? This makes the cost tangible.
|
||||
|
||||
**STEP 3: Reserve 20% Capacity This Sprint**
|
||||
In the current sprint planning, **slice off 20% of the team’s capacity** for debt repayment. Do not negotiate this. Use the register to pick the highest priority item (start with anything that threatens Hifz al-Aql or Hifz al-Mal). If you have no prior debt, use this capacity to build a **routing slip** for future debt decisions – a simple checklist: “Is this decision Deliberate? Is it Prudent? Have we logged it?”
|
||||
|
||||
---
|
||||
|
||||
## MUHASABA (RETROSPECTIVE)
|
||||
|
||||
**Where are we tolerating Israf in the name of speed, and what is the true cost in terms of Hifz al-Mal and Hifz al-Aql?**
|
||||
|
||||
Ask this question at your next retrospective. Sit in silence for 60 seconds before anyone speaks. Then force the team to assign a **dollar figure** to each piece of untracked debt – the cost of the bug it caused, the hours of confusion, the delayed feature. This isn’t guilt; it’s a calibration. If you cannot name the cost, you are still in Israf. The moment you name it, you are one step closer to Hifz al-Mal.
|
||||
@@ -0,0 +1,125 @@
|
||||
## Fatwa #7: Pricing — *Adl* (Justice) in Pricing
|
||||
|
||||
**Maqasid:** Hifz al-Mal (Preservation of Wealth)
|
||||
**Framework:** Pricing Quadrant – Cost-Plus / Value-Based / Dynamic / Freemium
|
||||
**Maqsad:** Value-Based Pricing as *Adl*
|
||||
|
||||
---
|
||||
|
||||
### 1. THE SCENARIO
|
||||
|
||||
You’re the Product Lead at a growing fintech startup. Your CEO pulls you aside after the weekly all-hands: “We’re about to launch our premium subscription tier. The sales team wants to charge what the market will bear. Finance says cost-plus with 30% margin. Engineering wants freemium to drive adoption. What’s the right pricing model?”
|
||||
|
||||
You open your notebook. The *Mujtahid* in you asks: *What is the hukm? What is the maqsad?* Pricing isn’t just a lever for revenue—it’s a declaration of justice. Get it wrong and you violate *Hifz al-Mal* (preservation of wealth) for both the company and the customer. Get it right and you align *Adl* with sustainable growth.
|
||||
|
||||
---
|
||||
|
||||
### 2. DISCOVERY (*Istiqsa’* / Continuous Discovery)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
“We don’t start with pricing models. We start with the job the customer is hiring us to do. Open your *Opportunity Solution Tree*. Draw three boxes:
|
||||
- **Opportunity:** Why would a user pay for a premium tier? (e.g., ‘I need faster loan approvals’ or ‘I want personalized financial advice’)
|
||||
- **Problem:** What’s their current workaround? (e.g., manual spreadsheets, free tier limitations)
|
||||
- **Outcome:** What does success look like for them? (e.g., save 2 hours per week, avoid late fees)
|
||||
|
||||
Run 8 customer interviews this week. Don’t ask ‘How much would you pay?’ Ask: ‘What would you give up to get this outcome?’ That reveals *value* — not price sensitivity.”
|
||||
|
||||
**MUJTAHID:**
|
||||
“*Istiqsa’* is exhaustive inquiry into the problem space. Start by defining the *maqsad*: What is *Adl* in pricing? In Islamic law, *Adl* means giving each party what they are due. For a seller, that means a fair return. For a buyer, it means paying a price that reflects genuine value, not exploitation.
|
||||
|
||||
Define *Ghabn* (exploitation): charging a price significantly above the market norm when the buyer is unaware or desperate. This is *haram* in a *mu’amalah* (transaction). The Prophet ﷺ forbade *ghabn fahish* (gross exploitation). So our discovery must answer:
|
||||
- What is the *market norm* for this type of service? (benchmarks, competitors)
|
||||
- What is the *value delivered* to the user? (not cost, not desire)
|
||||
- Where does *fair profit* cross into *ghabn*?
|
||||
|
||||
Use *Maqasid* analysis: *Hifz al-Mal* protects both parties. Overpricing destroys trust (a form of wealth for the company). Underpricing destroys sustainability (wealth for the customer short-term but kills the product). The *maqsad* is *tawazun* (balance).”
|
||||
|
||||
---
|
||||
|
||||
### 3. EVIDENCE (*Istidlal*)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
“Gather two types of evidence: quantitative and qualitative.
|
||||
|
||||
**Quantitative:**
|
||||
- Run a Van Westendorp Price Sensitivity Meter with 200 target users. The *Indifference Price Point* (IDP) and *Optimal Price Point* (OPP) tell you the range where value perception is highest without exploitation.
|
||||
- Analyze your churn data: What price point causes the highest dropout at signup? What price point correlates with longest retention?
|
||||
- Use cohort analysis to test willingness-to-pay against actual usage. Users who use the feature daily may tolerate higher prices. Light users won’t.
|
||||
|
||||
**Qualitative:**
|
||||
- Use the *Jobs-to-be-Done Interview* script: ‘When you last decided to spend money on a financial tool, what was the trigger? What outcome did you expect? How did you evaluate fairness?’
|
||||
- Listen for language of *ghabn*: ‘I felt taken advantage of’ or ‘That was a steal.’ These are signals of justice or injustice.
|
||||
- Map the *Opportunity Solution Tree* with pricing hypotheses. For example: ‘If we charge $9.99/month, then 40% of free users will convert because they perceive high value in automated budgeting.’ Test this with a *fake door* experiment: show the price on a landing page and measure click-through to signup.”
|
||||
|
||||
**MUJTAHID:**
|
||||
“*Istidlal* requires ranking evidence by strength.
|
||||
|
||||
- **Qati’ al-Thubut wa Qati’ al-Dalala** (certain transmission, certain meaning): The explicit prohibition of *riba* and *ghabn fahish* in the Qur’an and Sunnah. These give us the boundary: profit must be from legitimate value, not from exploitation.
|
||||
- **Zanni al-Thubut, Qati’ al-Dalala** (probable transmission, certain meaning): Hadith on fair pricing. For example, the Prophet ﷺ said, “*May Allah have mercy on a man who is lenient when he sells, when he buys, and when he demands payment*” (Bukhari). This implies a *shart* (condition) of *samaha* (generosity) in pricing.
|
||||
- **Zanni al-Thubut, Zanni al-Dalala** (probable both): *Ijma’* (consensus) of scholars that a fair profit margin is one that does not exceed the *ghabn* threshold, which varies by market and type of good.
|
||||
|
||||
Apply *Qiyas* (analogy): If a tailor charges a fair price for custom work based on time + material (cost-plus), then a fintech charging based on time saved (value-based) is analogous. The *‘illa* (effective cause) is the *value received* by the customer, not the seller’s cost.
|
||||
|
||||
**Key evidence question:** How do you measure ‘willingness to pay’ without crossing into exploitation? Use the *Maqasid* test: Does this price preserve the wealth of both parties? If the price is so high that the customer feels regret (a form of *ghabn*), you’ve violated *Adl*. If it’s so low that the company cannot sustain service, you’ve violated *Hifz al-Mal* for the shareholders.”
|
||||
|
||||
---
|
||||
|
||||
### 4. SHURA (Consultation)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
“Map your stakeholders:
|
||||
- **Users:** Run a *continuous discovery* council of 5–7 power users. Meet biweekly. Show them the pricing options: cost-plus ($5/mo), value-based ($15/mo based on average time saved = $30/hr × 0.5 hrs/week), and freemium ($0 with ads or limited features).
|
||||
- **Sales team:** They want maximum price. Interview them: ‘What objections do you hear from prospects? What price makes the demo easy?’
|
||||
- **Finance:** They need minimum viable revenue. Show them the *unit economics*: at $15/mo, what’s the payback period?
|
||||
- **Engineering:** They want simplicity. Freemium adds complexity. Let them estimate cost-to-serve per user.
|
||||
|
||||
Use a *weighted decision matrix*: score each option against *Adl* (user perception of fairness), sustainability (profit margin), and adoption (conversion rate). Record all concerns in a shared doc—especially dissenting views.”
|
||||
|
||||
**MUJTAHID:**
|
||||
“*Shura* is not a vote; it’s a method to uncover *maslaha* (public benefit). The *mujtahid* consults the *ahl al-‘ilm* (experts) and *ahl al-ra’y* (stakeholders), but the final *hukm* is based on *daleel*, not majority.
|
||||
|
||||
Consult three groups:
|
||||
1. **Scholars of the market** (your finance and sales teams) – they know the *‘urf* (custom) and *ghabn* thresholds.
|
||||
2. **Scholars of the user** (your customer research and support teams) – they know the *darura* (necessity) and *haja* (need) of users.
|
||||
3. **Scholars of the product** (engineering and design) – they know the *qudra* (capability) and *taklifa* (cost) of delivering value.
|
||||
|
||||
Weight their input by *‘ilm* (expertise) and *taqwa* (integrity). Record dissenting opinions—they may reveal a *shart* (condition) you missed. For example, if the sales rep says “Users won’t pay $15 because they don’t trust us yet,” that’s a *shart* of trust that must be addressed before pricing.
|
||||
|
||||
**Shura protocol:**
|
||||
- Present the *dalail* (evidence) you’ve gathered.
|
||||
- Ask each group: “What is the *maslaha* (benefit) and *mafsada* (harm) of each pricing model?”
|
||||
- Record all responses. Do not average them. Look for *ijma’* (consensus) on the *maqsad* (Adl), not on the price number.
|
||||
- The *mujtahid* (you) synthesizes and issues the *fatwa* (decision).”## THE FATWA (HUKM)
|
||||
|
||||
**HUKM:** We will adopt value-based pricing as the default model for all new product tiers, with cost-plus as a baseline floor, and dynamic pricing only for high-demand seasonal features — and will not use freemium as a primary acquisition strategy.
|
||||
|
||||
**DALEEL:** User interviews across four segments revealed perceived injustice in uniform pricing (e.g., small teams paying the same as enterprises, though receiving less value). Willingness-to-pay data showed a 40% spread between segments. Shura with finance confirmed cost-plus alone leaves 30% revenue on the table, while freemium attracted 70% non-converting users — a waste of Hifz al-Mal. Classical qiyas on *'adl* in exchange (Qur'an 4:29, "mutual consent in trade") and *bay' murabahah* principles supports pricing that reflects actual benefit to buyer, not just seller's cost.
|
||||
|
||||
**MAQSAD:** Hifz al-Mal (Preservation of Wealth) — for both the company (sustainable revenue to continue serving) and the customer (fair price for value received, avoiding *ghabn* (deception) and *riba* (unjust increase)). Also Hifz al-'Aql (rational economic decision-making) by transparently communicating the value metric so users can make informed choices.
|
||||
|
||||
**SHURUT:**
|
||||
- Must publish a clear, measurable value metric (e.g., number of active projects, users, or outcomes delivered) and an anchor price for each tier.
|
||||
- Must offer a low-cost entry tier (no free tier) to preserve access for those with limited means (Sad al-Dhara'i against exploitation of the poor).
|
||||
- Must A/B test any price change on a <10% user segment for at least two weeks before full rollout.
|
||||
- Must define a "price fairness ratio": max 5x between lowest and highest tier to avoid *gha'ish* (excessive gouging) and preserve *maslaha* of community.
|
||||
|
||||
**MUNKATHIRAT:**
|
||||
- If customer complaints about pricing exceed 15% in any tier within 30 days of release, rollback to previous pricing and redo discovery.
|
||||
- If conversion rate from trial (paid trial, not free) drops below 5%, invalidate the tier structure and return to cost-plus until new value data is gathered.
|
||||
- If any recognized Islamic finance body issues a fatwa against the pricing model (e.g., charging for value not yet delivered = *gharar*), suspend immediately and consult.
|
||||
|
||||
---
|
||||
|
||||
## THE PROTOCOL
|
||||
|
||||
**STEP 1: Value Discovery (This Sprint)** — Conduct 10 "value-level" interviews with existing customers using the JTBD framework. Ask: "What job did you hire our product for? How much does that job cost you if not done? What would you pay to eliminate that pain?" Map answers onto a 3-level scale: Low (basic need, <$10/month), Medium (core job, $10–$25/month), High (mission-critical, $25–$60/month). Do this in 5 working days.
|
||||
|
||||
**STEP 2: Build & A/B Test Pricing Matrix (Next Sprint)** — Using the value-level data, construct three tiers: Basic ($10), Pro ($25), Enterprise ($60). Ensure lowest tier covers cost-plus floor. Set up a 2-week A/B test on 5% of new signups (control: old cost-plus pricing; variant: value-based tiers). Measure conversion rate, ARPU, and churn. Use a simple landing page with clear value metric (e.g., "Pay per active project").
|
||||
|
||||
**STEP 3: Rollout & Monitor (Week 3–4)** — If A/B test meets success criteria (conversion > control by 10%, fairness ratio ≤5x, complaints <15%), roll out to 100%. Add a 30-day money-back guarantee to preserve trust (*trust = Hifz al-'Aql*). Monitor daily for Munkathirat triggers. If any trigger fires, execute rollback within 24 hours and return to cost-plus with a note in your retrospective.
|
||||
|
||||
---
|
||||
|
||||
## MUHASABA (RETROSPECTIVE)
|
||||
|
||||
When we set the price, whose *'adl* did we truly prioritize — the company's need for sustainable revenue, or the customer's need for affordability and fairness? Did we actually understand the value we deliver, or did we just guess based on competitor benchmarks? What would it mean to price with the same rigorous discovery we apply to feature decisions? Here's the piercing question: **Would you, the product team, pay this price for your own product? If not, why are you asking your customers to?** Let that sit. Then ask: *What one change would make the pricing feel just to both sides?*
|
||||
@@ -0,0 +1,92 @@
|
||||
## Fatwa #7: Pricing — *Adl* (Justice) in Pricing
|
||||
|
||||
**Maqasid:** Hifz al-Mal (Preservation of Wealth)
|
||||
**Framework:** Pricing Quadrant – Cost-Plus / Value-Based / Dynamic / Freemium
|
||||
**Maqsad:** Value-Based Pricing as *Adl*
|
||||
|
||||
---
|
||||
|
||||
### 1. THE SCENARIO
|
||||
|
||||
You’re the Product Lead at a growing fintech startup. Your CEO pulls you aside after the weekly all-hands: “We’re about to launch our premium subscription tier. The sales team wants to charge what the market will bear. Finance says cost-plus with 30% margin. Engineering wants freemium to drive adoption. What’s the right pricing model?”
|
||||
|
||||
You open your notebook. The *Mujtahid* in you asks: *What is the hukm? What is the maqsad?* Pricing isn’t just a lever for revenue—it’s a declaration of justice. Get it wrong and you violate *Hifz al-Mal* (preservation of wealth) for both the company and the customer. Get it right and you align *Adl* with sustainable growth.
|
||||
|
||||
---
|
||||
|
||||
### 2. DISCOVERY (*Istiqsa’* / Continuous Discovery)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
“We don’t start with pricing models. We start with the job the customer is hiring us to do. Open your *Opportunity Solution Tree*. Draw three boxes:
|
||||
- **Opportunity:** Why would a user pay for a premium tier? (e.g., ‘I need faster loan approvals’ or ‘I want personalized financial advice’)
|
||||
- **Problem:** What’s their current workaround? (e.g., manual spreadsheets, free tier limitations)
|
||||
- **Outcome:** What does success look like for them? (e.g., save 2 hours per week, avoid late fees)
|
||||
|
||||
Run 8 customer interviews this week. Don’t ask ‘How much would you pay?’ Ask: ‘What would you give up to get this outcome?’ That reveals *value* — not price sensitivity.”
|
||||
|
||||
**MUJTAHID:**
|
||||
“*Istiqsa’* is exhaustive inquiry into the problem space. Start by defining the *maqsad*: What is *Adl* in pricing? In Islamic law, *Adl* means giving each party what they are due. For a seller, that means a fair return. For a buyer, it means paying a price that reflects genuine value, not exploitation.
|
||||
|
||||
Define *Ghabn* (exploitation): charging a price significantly above the market norm when the buyer is unaware or desperate. This is *haram* in a *mu’amalah* (transaction). The Prophet ﷺ forbade *ghabn fahish* (gross exploitation). So our discovery must answer:
|
||||
- What is the *market norm* for this type of service? (benchmarks, competitors)
|
||||
- What is the *value delivered* to the user? (not cost, not desire)
|
||||
- Where does *fair profit* cross into *ghabn*?
|
||||
|
||||
Use *Maqasid* analysis: *Hifz al-Mal* protects both parties. Overpricing destroys trust (a form of wealth for the company). Underpricing destroys sustainability (wealth for the customer short-term but kills the product). The *maqsad* is *tawazun* (balance).”
|
||||
|
||||
---
|
||||
|
||||
### 3. EVIDENCE (*Istidlal*)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
“Gather two types of evidence: quantitative and qualitative.
|
||||
|
||||
**Quantitative:**
|
||||
- Run a Van Westendorp Price Sensitivity Meter with 200 target users. The *Indifference Price Point* (IDP) and *Optimal Price Point* (OPP) tell you the range where value perception is highest without exploitation.
|
||||
- Analyze your churn data: What price point causes the highest dropout at signup? What price point correlates with longest retention?
|
||||
- Use cohort analysis to test willingness-to-pay against actual usage. Users who use the feature daily may tolerate higher prices. Light users won’t.
|
||||
|
||||
**Qualitative:**
|
||||
- Use the *Jobs-to-be-Done Interview* script: ‘When you last decided to spend money on a financial tool, what was the trigger? What outcome did you expect? How did you evaluate fairness?’
|
||||
- Listen for language of *ghabn*: ‘I felt taken advantage of’ or ‘That was a steal.’ These are signals of justice or injustice.
|
||||
- Map the *Opportunity Solution Tree* with pricing hypotheses. For example: ‘If we charge $9.99/month, then 40% of free users will convert because they perceive high value in automated budgeting.’ Test this with a *fake door* experiment: show the price on a landing page and measure click-through to signup.”
|
||||
|
||||
**MUJTAHID:**
|
||||
“*Istidlal* requires ranking evidence by strength.
|
||||
|
||||
- **Qati’ al-Thubut wa Qati’ al-Dalala** (certain transmission, certain meaning): The explicit prohibition of *riba* and *ghabn fahish* in the Qur’an and Sunnah. These give us the boundary: profit must be from legitimate value, not from exploitation.
|
||||
- **Zanni al-Thubut, Qati’ al-Dalala** (probable transmission, certain meaning): Hadith on fair pricing. For example, the Prophet ﷺ said, “*May Allah have mercy on a man who is lenient when he sells, when he buys, and when he demands payment*” (Bukhari). This implies a *shart* (condition) of *samaha* (generosity) in pricing.
|
||||
- **Zanni al-Thubut, Zanni al-Dalala** (probable both): *Ijma’* (consensus) of scholars that a fair profit margin is one that does not exceed the *ghabn* threshold, which varies by market and type of good.
|
||||
|
||||
Apply *Qiyas* (analogy): If a tailor charges a fair price for custom work based on time + material (cost-plus), then a fintech charging based on time saved (value-based) is analogous. The *‘illa* (effective cause) is the *value received* by the customer, not the seller’s cost.
|
||||
|
||||
**Key evidence question:** How do you measure ‘willingness to pay’ without crossing into exploitation? Use the *Maqasid* test: Does this price preserve the wealth of both parties? If the price is so high that the customer feels regret (a form of *ghabn*), you’ve violated *Adl*. If it’s so low that the company cannot sustain service, you’ve violated *Hifz al-Mal* for the shareholders.”
|
||||
|
||||
---
|
||||
|
||||
### 4. SHURA (Consultation)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
“Map your stakeholders:
|
||||
- **Users:** Run a *continuous discovery* council of 5–7 power users. Meet biweekly. Show them the pricing options: cost-plus ($5/mo), value-based ($15/mo based on average time saved = $30/hr × 0.5 hrs/week), and freemium ($0 with ads or limited features).
|
||||
- **Sales team:** They want maximum price. Interview them: ‘What objections do you hear from prospects? What price makes the demo easy?’
|
||||
- **Finance:** They need minimum viable revenue. Show them the *unit economics*: at $15/mo, what’s the payback period?
|
||||
- **Engineering:** They want simplicity. Freemium adds complexity. Let them estimate cost-to-serve per user.
|
||||
|
||||
Use a *weighted decision matrix*: score each option against *Adl* (user perception of fairness), sustainability (profit margin), and adoption (conversion rate). Record all concerns in a shared doc—especially dissenting views.”
|
||||
|
||||
**MUJTAHID:**
|
||||
“*Shura* is not a vote; it’s a method to uncover *maslaha* (public benefit). The *mujtahid* consults the *ahl al-‘ilm* (experts) and *ahl al-ra’y* (stakeholders), but the final *hukm* is based on *daleel*, not majority.
|
||||
|
||||
Consult three groups:
|
||||
1. **Scholars of the market** (your finance and sales teams) – they know the *‘urf* (custom) and *ghabn* thresholds.
|
||||
2. **Scholars of the user** (your customer research and support teams) – they know the *darura* (necessity) and *haja* (need) of users.
|
||||
3. **Scholars of the product** (engineering and design) – they know the *qudra* (capability) and *taklifa* (cost) of delivering value.
|
||||
|
||||
Weight their input by *‘ilm* (expertise) and *taqwa* (integrity). Record dissenting opinions—they may reveal a *shart* (condition) you missed. For example, if the sales rep says “Users won’t pay $15 because they don’t trust us yet,” that’s a *shart* of trust that must be addressed before pricing.
|
||||
|
||||
**Shura protocol:**
|
||||
- Present the *dalail* (evidence) you’ve gathered.
|
||||
- Ask each group: “What is the *maslaha* (benefit) and *mafsada* (harm) of each pricing model?”
|
||||
- Record all responses. Do not average them. Look for *ijma’* (consensus) on the *maqsad* (Adl), not on the price number.
|
||||
- The *mujtahid* (you) synthesizes and issues the *fatwa* (decision).”
|
||||
@@ -0,0 +1,34 @@
|
||||
## THE FATWA (HUKM)
|
||||
|
||||
**HUKM:** We will adopt value-based pricing as the default model for all new product tiers, with cost-plus as a baseline floor, and dynamic pricing only for high-demand seasonal features — and will not use freemium as a primary acquisition strategy.
|
||||
|
||||
**DALEEL:** User interviews across four segments revealed perceived injustice in uniform pricing (e.g., small teams paying the same as enterprises, though receiving less value). Willingness-to-pay data showed a 40% spread between segments. Shura with finance confirmed cost-plus alone leaves 30% revenue on the table, while freemium attracted 70% non-converting users — a waste of Hifz al-Mal. Classical qiyas on *'adl* in exchange (Qur'an 4:29, "mutual consent in trade") and *bay' murabahah* principles supports pricing that reflects actual benefit to buyer, not just seller's cost.
|
||||
|
||||
**MAQSAD:** Hifz al-Mal (Preservation of Wealth) — for both the company (sustainable revenue to continue serving) and the customer (fair price for value received, avoiding *ghabn* (deception) and *riba* (unjust increase)). Also Hifz al-'Aql (rational economic decision-making) by transparently communicating the value metric so users can make informed choices.
|
||||
|
||||
**SHURUT:**
|
||||
- Must publish a clear, measurable value metric (e.g., number of active projects, users, or outcomes delivered) and an anchor price for each tier.
|
||||
- Must offer a low-cost entry tier (no free tier) to preserve access for those with limited means (Sad al-Dhara'i against exploitation of the poor).
|
||||
- Must A/B test any price change on a <10% user segment for at least two weeks before full rollout.
|
||||
- Must define a "price fairness ratio": max 5x between lowest and highest tier to avoid *gha'ish* (excessive gouging) and preserve *maslaha* of community.
|
||||
|
||||
**MUNKATHIRAT:**
|
||||
- If customer complaints about pricing exceed 15% in any tier within 30 days of release, rollback to previous pricing and redo discovery.
|
||||
- If conversion rate from trial (paid trial, not free) drops below 5%, invalidate the tier structure and return to cost-plus until new value data is gathered.
|
||||
- If any recognized Islamic finance body issues a fatwa against the pricing model (e.g., charging for value not yet delivered = *gharar*), suspend immediately and consult.
|
||||
|
||||
---
|
||||
|
||||
## THE PROTOCOL
|
||||
|
||||
**STEP 1: Value Discovery (This Sprint)** — Conduct 10 "value-level" interviews with existing customers using the JTBD framework. Ask: "What job did you hire our product for? How much does that job cost you if not done? What would you pay to eliminate that pain?" Map answers onto a 3-level scale: Low (basic need, <$10/month), Medium (core job, $10–$25/month), High (mission-critical, $25–$60/month). Do this in 5 working days.
|
||||
|
||||
**STEP 2: Build & A/B Test Pricing Matrix (Next Sprint)** — Using the value-level data, construct three tiers: Basic ($10), Pro ($25), Enterprise ($60). Ensure lowest tier covers cost-plus floor. Set up a 2-week A/B test on 5% of new signups (control: old cost-plus pricing; variant: value-based tiers). Measure conversion rate, ARPU, and churn. Use a simple landing page with clear value metric (e.g., "Pay per active project").
|
||||
|
||||
**STEP 3: Rollout & Monitor (Week 3–4)** — If A/B test meets success criteria (conversion > control by 10%, fairness ratio ≤5x, complaints <15%), roll out to 100%. Add a 30-day money-back guarantee to preserve trust (*trust = Hifz al-'Aql*). Monitor daily for Munkathirat triggers. If any trigger fires, execute rollback within 24 hours and return to cost-plus with a note in your retrospective.
|
||||
|
||||
---
|
||||
|
||||
## MUHASABA (RETROSPECTIVE)
|
||||
|
||||
When we set the price, whose *'adl* did we truly prioritize — the company's need for sustainable revenue, or the customer's need for affordability and fairness? Did we actually understand the value we deliver, or did we just guess based on competitor benchmarks? What would it mean to price with the same rigorous discovery we apply to feature decisions? Here's the piercing question: **Would you, the product team, pay this price for your own product? If not, why are you asking your customers to?** Let that sit. Then ask: *What one change would make the pricing feel just to both sides?*
|
||||
@@ -0,0 +1,119 @@
|
||||
# Fatwa #8: Growth Metrics — Barakah vs Vanity Metrics
|
||||
|
||||
**Maqasid:** Hifz al-Nasl (Preservation of Lineage / Continuity) → Sustainable Growth
|
||||
**Framework:** AARRR → Barakah Filter
|
||||
|
||||
---
|
||||
|
||||
## 1. THE SCENARIO
|
||||
|
||||
You're the Product Lead at a fast-growing Islamic fintech startup. Monthly active users are exploding. The CEO bursts into your weekly sync: "Why are we building this feature? Just ship it — we need the MAU number for the board deck." You pause. Your notebook is open. The *Mujtahid* in you asks: *What is the hukm? What is the maqsad?* The *Product Lead* in you asks: *What outcome are we really after?* The numbers look great. But something feels hollow. You suspect these aren't users — they're visitors. Growth without Barakah is just noise. You need a filter.
|
||||
|
||||
---
|
||||
|
||||
## 2. DISCOVERY (ISTIQSA')
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Run continuous discovery. Open your Opportunity Solution Tree. Start with the desired outcome: *Sustainable, Barakah-filled growth that compounds.* Then ask: *What opportunities block that outcome?* One pattern emerges: we chase vanity metrics (MAU, downloads, sign-ups) but ignore retention and referral quality. Map the JTBD: *“Help me grow my wealth without riba”* vs *“Help me feel like I’m a user of a cool app.”* The real job is trust + continuity. Talk to ten users who churned after 30 days. Ask: “What made you leave?” The answer: “I didn’t feel the app was actually helping me stay halal.” That’s a discovery insight. Now sketch an Opportunity Solution Tree: Top opportunity = *“Build trust through consistent value delivery.”* Sub-opportunities: *“Reduce friction in Zakat calculation”* and *“Show long-term impact of halal investing.”* All solutions must pass the Barakah test: does this action increase or decrease the user’s *taqwa* (God-consciousness) and *tawakkul* (reliance on Allah)?
|
||||
|
||||
**MUJTAHID:**
|
||||
*Istiqsa’* — exhaustive investigation of the problem space. You must define *Barakah* in operational terms. Barakah (البركة) is the *hidden increase* from Allah — growth that multiplies without inflation, that brings *khayr* (goodness) and *sakinah* (tranquility). It is not merely quantitative; it is qualitative. Prophet ﷺ said: *"Blessed is the wealth of a Muslim from which he gives to the poor, to the relative, and to the orphan."* (Bukhari). Growth with Barakah preserves *Hifz al-Nasl* — continuity across generations. Vanity metrics are *ghurur* (delusion). They inflate the ego and lead to *hasad* (envy) and *riba* (unjust increase). Your discovery must ask: *What is the maqsad of growth?* Is it to please Allah and serve the ummah, or to impress investors? Define the *shurut* (conditions) of Barakah in growth: (1) *Halal source* — no deceptive acquisition tactics. (2) *Niyyah* — intention to benefit users, not exploit. (3) *Tazkiyah* — growth must purify, not pollute. (4) *Istithmar* — sustainable yield, not burnout. Use *Maslaha Mursalah* (public benefit) to prioritize features that build long-term trust over short-term spikes. Draw the quadrant: X-axis = *Quantity* (low to high). Y-axis = *Barakah* (low to high). Only the top-right quadrant — high quantity + high Barakah — is worth pursuing. Everything else is vanity.
|
||||
|
||||
---
|
||||
|
||||
## 3. EVIDENCE (ISTIDLAL)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Gather two types of evidence: quantitative and qualitative.
|
||||
- **Quantitative:** Pull your AARRR funnel.
|
||||
- *Acquisition:* 50k sign-ups last quarter.
|
||||
- *Activation:* Only 30% completed onboarding (halal account setup).
|
||||
- *Retention:* 15% Day-30 retention.
|
||||
- *Referral:* 0.2 viral coefficient.
|
||||
- *Revenue:* $2 ARPU but 60% churn after first month.
|
||||
These numbers scream: you’re bleeding users. The spike in MAU is from ads, not value.
|
||||
- **Qualitative:** Run 8 user interviews with retained users (those who stayed >90 days). Common theme: *“I use the app because it helps me track my Zakat automatically — that’s the only feature I trust.”* That’s a Barakah signal. Interview 8 churned users: *“I signed up because of a referral link, but then I never used it. Too complicated.”* That’s a vanity signal.
|
||||
Now triangulate. The *Barakah filter* for metrics:
|
||||
- *Retention* is the proxy for Barakah (continuity = Hifz al-Nasl).
|
||||
- *Referral quality* (do referred users stay?) is stronger than raw referrals.
|
||||
- *Revenue per retained user* is more meaningful than total revenue.
|
||||
Your North Star should be: *“Monthly active users who have completed at least one halal transaction in the last 30 days and have a Zakat tracker enabled.”* That’s a Barakah metric.
|
||||
|
||||
**MUJTAHID:**
|
||||
*Istidlal* — evidence hierarchy. You need *qati* (definitive) and *zanni* (probable) evidence to support your metrics filter.
|
||||
- **Qati al-Thubut (definitive source):** Quran 35:29-30 — *“Those who recite the Book of Allah, establish prayer, and spend from what We have provided… they hope for a transaction that will never perish.”* This is the *dalil* that sustainable growth (not perishable vanity) is the objective. Vanity metrics perish; Barakah metrics endure.
|
||||
- **Zanni al-Dalala (probable interpretation):** Hadith on *barakah in sustenance* — Prophet ﷺ said: *“Give charity, for it increases wealth in barakah.”* (Sahih Muslim). Charity here is a metaphor for value-first growth. If you give genuine value to users first (charity of service), Allah increases your growth in Barakah. Metrics that measure *giving* (e.g., time saved, Zakat calculated) have Barakah.
|
||||
- **Qiyas (analogy):** Vanity metrics are like *riba* — apparent increase but actual loss. Allah says: *“Allah destroys interest and gives increase for charities.”* (2:276). Churn is the destruction. Retention is the charity. So your evidence shows: **churn rate is a *munkathir* (nullifier)** of Barakah.
|
||||
- **Maslaha (public benefit):** Prioritize metrics that protect *Hifz al-Nasl* — long-term user continuity. A user who stays for 5 years and refers their family preserves lineage of faith and financial health. That’s the *maqsad*.
|
||||
- **Sad al-Dhara'i (blocking means to evil):** Block any feature that inflates MAU without genuine activation. Example: push notifications that trick users into opening the app (clickbait). That’s a *dhari'ah* to vanity. Instead, build notifications that remind users of prayer times or Zakat due — that’s Barakah.
|
||||
|
||||
**Evidence Summary:**
|
||||
- High retention + low churn = Barakah.
|
||||
- Low retention + high acquisition = Vanity (like *ghurur*).
|
||||
- Referral quality (family, friends who stay) = Hifz al-Nasl.
|
||||
- Revenue from retained users = *Mal* with Barakah.
|
||||
|
||||
---
|
||||
|
||||
## 4. SHURA
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Call a cross-functional Shura. Attendees: CEO, Head of Growth, Head of Engineering, two user representatives (one retained, one churned). Use a structured format:
|
||||
1. **Situation:** Present the Opportunity Solution Tree. Show the vanity trap.
|
||||
2. **Evidence:** Share the quantitative and qualitative data. Highlight the churn crisis.
|
||||
3. **Proposal:** Shift growth strategy from “more MAU” to “more retained, Barakah-filled users.” Suggest new North Star metric: *“Active Halal Transaction Users (AHTU).”*
|
||||
4. **Dissent:** Invite pushback. The Head of Growth argues: “But our board expects MAU growth — we’ll lose funding.” The user rep says: “I almost left because I didn’t understand the app. If you fix onboarding, I’d stay.”
|
||||
5. **Weighting:** PRODUCT_LEAD weights user voice heavily (closest to truth). Head of Growth voice is important but secondary if it contradicts user evidence. Use *Istishab* (presumption of continuity): assume current growth is unsustainable unless proven otherwise. The evidence shows it is unsustainable.
|
||||
6. **Consensus:** The Shura agrees to pilot a 2-week experiment: disable all push notifications except Barakah-triggered ones (Zakat, prayer, charity). Measure impact on retention and churn. If retention improves, roll out. Document the *mukhalif* (dissenting) opinion: Head of Growth will prepare a risk-mitigation plan for board communication.
|
||||
|
||||
**MUJTAHID:**
|
||||
Shura is *fard kifayah* — obligatory when leaders lack full knowledge. The Prophet ﷺ consulted companions even on military matters. Methodology:
|
||||
- **Who to consult:** Those with *‘ilm* (knowledge of the domain) and *taqwa* (God-consciousness). Your Shura includes a user (owner of the problem) and a growth expert (owner of the numbers). Both have partial *‘ilm*.
|
||||
- **How to consult:** Present the *hukm* options (e.g., “We can either continue chasing MAU or pivot to retention”). Ask each member: *“What is your evidence? What is your maqsad?”* Record all responses.
|
||||
- **Weighting:** The *mujtahid* (you) is the final decider. But you must give *tarjih* (preference) based on strength of evidence, not authority. The user’s lived experience is *zanni* but high *dalala* (strong indication). The Head of Growth’s board concern is also *zanni* but lower *dalala* because it’s hypothetical (fear of funding loss). Prefer the evidence that is *qati* in its source (user experience = direct reality) over *zanni* in its outcome (board reaction = uncertain).
|
||||
- **Recording dissent:** Write down the Head of Growth’s objection. Label it *munkathir* (potential nullifier) — if retention doesn’t improve, revert to previous strategy. This builds *shurut* (conditions) into the decision.
|
||||
- **Outcome of Shura:** A *fatwa* is not yet issued. The Shura has *defined the problem* and *gathered evidence*. Next step: synthesize into a *hukm* (ruling) with *daleel*, *maqsad*, *shurut*, *munkathirat*. That will be Fatwa #8’s second half.
|
||||
|
||||
---
|
||||
|
||||
*End of Part 1. Part 2 will deliver the formal Fatwa (Hukm), the Protocol (3 actionable steps), and the Muhasaba (retrospective).*## THE FATWA (HUKM)
|
||||
|
||||
**HUKM:** We will build a **Retention & Referral Barakah Dashboard** as our primary growth metric, and we will **not optimize for raw acquisition numbers** unless they pass the Barakah Filter (ethical source, sustainable unit economics, aligned with Maqasid).
|
||||
|
||||
**DALEEL:**
|
||||
Quantitative: 90% of new users from paid ads churn within 30 days (Zanni evidence of waste). Qualitative: Users who were referred by a trusted peer show 3x higher LTV and report "barakah" (feeling of blessing, trust). Istidlal: The Sunnah of the Prophet ﷺ emphasizes quality over quantity in community building ("The best of you are those who are best to their families" – sustainable care). Qiyas: Vanity metrics are like counting seeds without checking soil; Barakah metrics measure rootedness.
|
||||
|
||||
**MAQSAD:**
|
||||
**Hifz al-Nasl** – Preservation of lineage/continuity. By prioritizing retention and referral, we build a self-sustaining community that grows through trust, not manipulation. This protects the product’s legacy and the user’s spiritual and financial capital (Hifz al-Mal and Hifz al-Aql also served).
|
||||
|
||||
**SHURUT:**
|
||||
- **Retention rate ≥ 60%** for monthly active users after 3 months (if below, pause scaling).
|
||||
- **Referral conversion rate ≥ 15%** (if below, fix referral mechanism before injecting more traffic).
|
||||
- **Unit economics must be positive** within 6 months for any acquisition channel (no "growth at all costs").
|
||||
- **Rollback trigger:** If any metric (acquisition, activation, revenue) grows but retention drops >5%, revert to previous growth strategy and run discovery.
|
||||
|
||||
**MUNKATHIRAT:**
|
||||
- **Buying users with no retention signal** – invalidates the fatwa immediately.
|
||||
- **Gamification that exploits dopamine loops** (e.g., fake scarcity) – nullifies barakah.
|
||||
- **Using dark patterns to increase referrals** (e.g., forced sharing) – violates trust.
|
||||
|
||||
---
|
||||
|
||||
## THE PROTOCOL
|
||||
|
||||
**STEP 1: Define your Barakah Dashboard (This Monday)**
|
||||
Open your analytics tool. Create a single view showing: (a) Weekly active users retained from 4 weeks ago, (b) Referral rate (users who joined via invitation in the last 7 days), (c) Net Promoter Score of retained users. Hide all other metrics from your daily view. **Label this "Barakah North Star."**
|
||||
|
||||
**STEP 2: Delete one vanity metric (This Week)**
|
||||
Choose the highest-traffic vanity metric (e.g., "Total Signups" or "Page Views"). Remove it from your weekly report. Replace it with a qualitative pulse: "Ask 3 retained users this week: 'Why do you still use us? What feels blessed about this?'" Document answers in a shared doc.
|
||||
|
||||
**STEP 3: Run a Barakah Growth Experiment (This Sprint)**
|
||||
Pick one referral channel (e.g., "invite a friend for mutual benefit"). Ship a minimal version (e.g., a simple share link with a thank-you note, no rewards). Measure referral conversion and 30-day retention of referred users. If retention ≥ 60%, double down. If not, run discovery on why.
|
||||
|
||||
---
|
||||
|
||||
## MUHASABA (RETROSPECTIVE)
|
||||
|
||||
**What is one vanity metric we are secretly attached to because it makes us feel important, and what would it cost us to let it go for one quarter?**
|
||||
|
||||
This question exposes the ego behind growth. Barakah often arrives when we release the need for visible, instant validation. The metric we fear to drop is the one that’s likely corrupting our sustainability. Answer honestly, then delete it tomorrow.
|
||||
@@ -0,0 +1,79 @@
|
||||
# Fatwa #8: Growth Metrics — Barakah vs Vanity Metrics
|
||||
|
||||
**Maqasid:** Hifz al-Nasl (Preservation of Lineage / Continuity) → Sustainable Growth
|
||||
**Framework:** AARRR → Barakah Filter
|
||||
|
||||
---
|
||||
|
||||
## 1. THE SCENARIO
|
||||
|
||||
You're the Product Lead at a fast-growing Islamic fintech startup. Monthly active users are exploding. The CEO bursts into your weekly sync: "Why are we building this feature? Just ship it — we need the MAU number for the board deck." You pause. Your notebook is open. The *Mujtahid* in you asks: *What is the hukm? What is the maqsad?* The *Product Lead* in you asks: *What outcome are we really after?* The numbers look great. But something feels hollow. You suspect these aren't users — they're visitors. Growth without Barakah is just noise. You need a filter.
|
||||
|
||||
---
|
||||
|
||||
## 2. DISCOVERY (ISTIQSA')
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Run continuous discovery. Open your Opportunity Solution Tree. Start with the desired outcome: *Sustainable, Barakah-filled growth that compounds.* Then ask: *What opportunities block that outcome?* One pattern emerges: we chase vanity metrics (MAU, downloads, sign-ups) but ignore retention and referral quality. Map the JTBD: *“Help me grow my wealth without riba”* vs *“Help me feel like I’m a user of a cool app.”* The real job is trust + continuity. Talk to ten users who churned after 30 days. Ask: “What made you leave?” The answer: “I didn’t feel the app was actually helping me stay halal.” That’s a discovery insight. Now sketch an Opportunity Solution Tree: Top opportunity = *“Build trust through consistent value delivery.”* Sub-opportunities: *“Reduce friction in Zakat calculation”* and *“Show long-term impact of halal investing.”* All solutions must pass the Barakah test: does this action increase or decrease the user’s *taqwa* (God-consciousness) and *tawakkul* (reliance on Allah)?
|
||||
|
||||
**MUJTAHID:**
|
||||
*Istiqsa’* — exhaustive investigation of the problem space. You must define *Barakah* in operational terms. Barakah (البركة) is the *hidden increase* from Allah — growth that multiplies without inflation, that brings *khayr* (goodness) and *sakinah* (tranquility). It is not merely quantitative; it is qualitative. Prophet ﷺ said: *"Blessed is the wealth of a Muslim from which he gives to the poor, to the relative, and to the orphan."* (Bukhari). Growth with Barakah preserves *Hifz al-Nasl* — continuity across generations. Vanity metrics are *ghurur* (delusion). They inflate the ego and lead to *hasad* (envy) and *riba* (unjust increase). Your discovery must ask: *What is the maqsad of growth?* Is it to please Allah and serve the ummah, or to impress investors? Define the *shurut* (conditions) of Barakah in growth: (1) *Halal source* — no deceptive acquisition tactics. (2) *Niyyah* — intention to benefit users, not exploit. (3) *Tazkiyah* — growth must purify, not pollute. (4) *Istithmar* — sustainable yield, not burnout. Use *Maslaha Mursalah* (public benefit) to prioritize features that build long-term trust over short-term spikes. Draw the quadrant: X-axis = *Quantity* (low to high). Y-axis = *Barakah* (low to high). Only the top-right quadrant — high quantity + high Barakah — is worth pursuing. Everything else is vanity.
|
||||
|
||||
---
|
||||
|
||||
## 3. EVIDENCE (ISTIDLAL)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Gather two types of evidence: quantitative and qualitative.
|
||||
- **Quantitative:** Pull your AARRR funnel.
|
||||
- *Acquisition:* 50k sign-ups last quarter.
|
||||
- *Activation:* Only 30% completed onboarding (halal account setup).
|
||||
- *Retention:* 15% Day-30 retention.
|
||||
- *Referral:* 0.2 viral coefficient.
|
||||
- *Revenue:* $2 ARPU but 60% churn after first month.
|
||||
These numbers scream: you’re bleeding users. The spike in MAU is from ads, not value.
|
||||
- **Qualitative:** Run 8 user interviews with retained users (those who stayed >90 days). Common theme: *“I use the app because it helps me track my Zakat automatically — that’s the only feature I trust.”* That’s a Barakah signal. Interview 8 churned users: *“I signed up because of a referral link, but then I never used it. Too complicated.”* That’s a vanity signal.
|
||||
Now triangulate. The *Barakah filter* for metrics:
|
||||
- *Retention* is the proxy for Barakah (continuity = Hifz al-Nasl).
|
||||
- *Referral quality* (do referred users stay?) is stronger than raw referrals.
|
||||
- *Revenue per retained user* is more meaningful than total revenue.
|
||||
Your North Star should be: *“Monthly active users who have completed at least one halal transaction in the last 30 days and have a Zakat tracker enabled.”* That’s a Barakah metric.
|
||||
|
||||
**MUJTAHID:**
|
||||
*Istidlal* — evidence hierarchy. You need *qati* (definitive) and *zanni* (probable) evidence to support your metrics filter.
|
||||
- **Qati al-Thubut (definitive source):** Quran 35:29-30 — *“Those who recite the Book of Allah, establish prayer, and spend from what We have provided… they hope for a transaction that will never perish.”* This is the *dalil* that sustainable growth (not perishable vanity) is the objective. Vanity metrics perish; Barakah metrics endure.
|
||||
- **Zanni al-Dalala (probable interpretation):** Hadith on *barakah in sustenance* — Prophet ﷺ said: *“Give charity, for it increases wealth in barakah.”* (Sahih Muslim). Charity here is a metaphor for value-first growth. If you give genuine value to users first (charity of service), Allah increases your growth in Barakah. Metrics that measure *giving* (e.g., time saved, Zakat calculated) have Barakah.
|
||||
- **Qiyas (analogy):** Vanity metrics are like *riba* — apparent increase but actual loss. Allah says: *“Allah destroys interest and gives increase for charities.”* (2:276). Churn is the destruction. Retention is the charity. So your evidence shows: **churn rate is a *munkathir* (nullifier)** of Barakah.
|
||||
- **Maslaha (public benefit):** Prioritize metrics that protect *Hifz al-Nasl* — long-term user continuity. A user who stays for 5 years and refers their family preserves lineage of faith and financial health. That’s the *maqsad*.
|
||||
- **Sad al-Dhara'i (blocking means to evil):** Block any feature that inflates MAU without genuine activation. Example: push notifications that trick users into opening the app (clickbait). That’s a *dhari'ah* to vanity. Instead, build notifications that remind users of prayer times or Zakat due — that’s Barakah.
|
||||
|
||||
**Evidence Summary:**
|
||||
- High retention + low churn = Barakah.
|
||||
- Low retention + high acquisition = Vanity (like *ghurur*).
|
||||
- Referral quality (family, friends who stay) = Hifz al-Nasl.
|
||||
- Revenue from retained users = *Mal* with Barakah.
|
||||
|
||||
---
|
||||
|
||||
## 4. SHURA
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Call a cross-functional Shura. Attendees: CEO, Head of Growth, Head of Engineering, two user representatives (one retained, one churned). Use a structured format:
|
||||
1. **Situation:** Present the Opportunity Solution Tree. Show the vanity trap.
|
||||
2. **Evidence:** Share the quantitative and qualitative data. Highlight the churn crisis.
|
||||
3. **Proposal:** Shift growth strategy from “more MAU” to “more retained, Barakah-filled users.” Suggest new North Star metric: *“Active Halal Transaction Users (AHTU).”*
|
||||
4. **Dissent:** Invite pushback. The Head of Growth argues: “But our board expects MAU growth — we’ll lose funding.” The user rep says: “I almost left because I didn’t understand the app. If you fix onboarding, I’d stay.”
|
||||
5. **Weighting:** PRODUCT_LEAD weights user voice heavily (closest to truth). Head of Growth voice is important but secondary if it contradicts user evidence. Use *Istishab* (presumption of continuity): assume current growth is unsustainable unless proven otherwise. The evidence shows it is unsustainable.
|
||||
6. **Consensus:** The Shura agrees to pilot a 2-week experiment: disable all push notifications except Barakah-triggered ones (Zakat, prayer, charity). Measure impact on retention and churn. If retention improves, roll out. Document the *mukhalif* (dissenting) opinion: Head of Growth will prepare a risk-mitigation plan for board communication.
|
||||
|
||||
**MUJTAHID:**
|
||||
Shura is *fard kifayah* — obligatory when leaders lack full knowledge. The Prophet ﷺ consulted companions even on military matters. Methodology:
|
||||
- **Who to consult:** Those with *‘ilm* (knowledge of the domain) and *taqwa* (God-consciousness). Your Shura includes a user (owner of the problem) and a growth expert (owner of the numbers). Both have partial *‘ilm*.
|
||||
- **How to consult:** Present the *hukm* options (e.g., “We can either continue chasing MAU or pivot to retention”). Ask each member: *“What is your evidence? What is your maqsad?”* Record all responses.
|
||||
- **Weighting:** The *mujtahid* (you) is the final decider. But you must give *tarjih* (preference) based on strength of evidence, not authority. The user’s lived experience is *zanni* but high *dalala* (strong indication). The Head of Growth’s board concern is also *zanni* but lower *dalala* because it’s hypothetical (fear of funding loss). Prefer the evidence that is *qati* in its source (user experience = direct reality) over *zanni* in its outcome (board reaction = uncertain).
|
||||
- **Recording dissent:** Write down the Head of Growth’s objection. Label it *munkathir* (potential nullifier) — if retention doesn’t improve, revert to previous strategy. This builds *shurut* (conditions) into the decision.
|
||||
- **Outcome of Shura:** A *fatwa* is not yet issued. The Shura has *defined the problem* and *gathered evidence*. Next step: synthesize into a *hukm* (ruling) with *daleel*, *maqsad*, *shurut*, *munkathirat*. That will be Fatwa #8’s second half.
|
||||
|
||||
---
|
||||
|
||||
*End of Part 1. Part 2 will deliver the formal Fatwa (Hukm), the Protocol (3 actionable steps), and the Muhasaba (retrospective).*
|
||||
@@ -0,0 +1,41 @@
|
||||
## THE FATWA (HUKM)
|
||||
|
||||
**HUKM:** We will build a **Retention & Referral Barakah Dashboard** as our primary growth metric, and we will **not optimize for raw acquisition numbers** unless they pass the Barakah Filter (ethical source, sustainable unit economics, aligned with Maqasid).
|
||||
|
||||
**DALEEL:**
|
||||
Quantitative: 90% of new users from paid ads churn within 30 days (Zanni evidence of waste). Qualitative: Users who were referred by a trusted peer show 3x higher LTV and report "barakah" (feeling of blessing, trust). Istidlal: The Sunnah of the Prophet ﷺ emphasizes quality over quantity in community building ("The best of you are those who are best to their families" – sustainable care). Qiyas: Vanity metrics are like counting seeds without checking soil; Barakah metrics measure rootedness.
|
||||
|
||||
**MAQSAD:**
|
||||
**Hifz al-Nasl** – Preservation of lineage/continuity. By prioritizing retention and referral, we build a self-sustaining community that grows through trust, not manipulation. This protects the product’s legacy and the user’s spiritual and financial capital (Hifz al-Mal and Hifz al-Aql also served).
|
||||
|
||||
**SHURUT:**
|
||||
- **Retention rate ≥ 60%** for monthly active users after 3 months (if below, pause scaling).
|
||||
- **Referral conversion rate ≥ 15%** (if below, fix referral mechanism before injecting more traffic).
|
||||
- **Unit economics must be positive** within 6 months for any acquisition channel (no "growth at all costs").
|
||||
- **Rollback trigger:** If any metric (acquisition, activation, revenue) grows but retention drops >5%, revert to previous growth strategy and run discovery.
|
||||
|
||||
**MUNKATHIRAT:**
|
||||
- **Buying users with no retention signal** – invalidates the fatwa immediately.
|
||||
- **Gamification that exploits dopamine loops** (e.g., fake scarcity) – nullifies barakah.
|
||||
- **Using dark patterns to increase referrals** (e.g., forced sharing) – violates trust.
|
||||
|
||||
---
|
||||
|
||||
## THE PROTOCOL
|
||||
|
||||
**STEP 1: Define your Barakah Dashboard (This Monday)**
|
||||
Open your analytics tool. Create a single view showing: (a) Weekly active users retained from 4 weeks ago, (b) Referral rate (users who joined via invitation in the last 7 days), (c) Net Promoter Score of retained users. Hide all other metrics from your daily view. **Label this "Barakah North Star."**
|
||||
|
||||
**STEP 2: Delete one vanity metric (This Week)**
|
||||
Choose the highest-traffic vanity metric (e.g., "Total Signups" or "Page Views"). Remove it from your weekly report. Replace it with a qualitative pulse: "Ask 3 retained users this week: 'Why do you still use us? What feels blessed about this?'" Document answers in a shared doc.
|
||||
|
||||
**STEP 3: Run a Barakah Growth Experiment (This Sprint)**
|
||||
Pick one referral channel (e.g., "invite a friend for mutual benefit"). Ship a minimal version (e.g., a simple share link with a thank-you note, no rewards). Measure referral conversion and 30-day retention of referred users. If retention ≥ 60%, double down. If not, run discovery on why.
|
||||
|
||||
---
|
||||
|
||||
## MUHASABA (RETROSPECTIVE)
|
||||
|
||||
**What is one vanity metric we are secretly attached to because it makes us feel important, and what would it cost us to let it go for one quarter?**
|
||||
|
||||
This question exposes the ego behind growth. Barakah often arrives when we release the need for visible, instant validation. The metric we fear to drop is the one that’s likely corrupting our sustainability. Answer honestly, then delete it tomorrow.
|
||||
@@ -0,0 +1,133 @@
|
||||
## Part 1: Discovery, Evidence, and Shura
|
||||
|
||||
### 1. THE SCENARIO
|
||||
|
||||
You’re the Product Lead at *ZakatPay*, a growing fintech startup connecting users to verified charities. The team has grown from 5 to 25 engineers in six months. Silos are forming. The CEO pulls you aside: “Why is the payments squad building a dashboard without talking to the charity onboarding squad? And why do both of them report to me for every decision?” You open your notebook. The *Mujtahid* in you asks: *What is the hukm of organizing the team? What is the maqsad of our structure?* The *Product Lead* in you asks: *What’s the smallest change that gives us speed without chaos?*
|
||||
|
||||
### 2. DISCOVERY (ISTIQSA’)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Let’s start with Continuous Discovery. Open your Opportunity Solution Tree. The root opportunity is: *“Our team is too slow to respond to user needs because every decision escalates to the CEO.”* The parent opportunity is: *“Team lacks clear ownership boundaries.”* Child opportunities include: “No single point of accountability per feature area,” “Cross-functional dependencies block progress,” “Developers don’t know who to ask for product guidance.”
|
||||
|
||||
Now map the *Jobs-to-be-Done* for the organization itself. The org has three core JTBD:
|
||||
1. **Ship validated features weekly** – currently failing because of approval bottlenecks.
|
||||
2. **Maintain quality and risk compliance** – currently handled by CEO-as-gatekeeper, unsustainable.
|
||||
3. **Enable team growth and learning** – currently zero cross-squad knowledge sharing.
|
||||
|
||||
Draw four boxes on your whiteboard: *Functional* (all PMs together, all engineers together), *Cross-functional* (squads with PM+Eng+Design), *Guild* (community of practice across squads), *Chapter* (discipline-specific sync within squad). Your hypothesis: a squad model with chapters and guilds will unlock speed and preserve alignment.
|
||||
|
||||
**MUJTAHID:**
|
||||
*Istiqsa’* means exhaustive inquiry into the reality of the problem. The *maqsad* here is *Hifz al-Nasl* – preservation of the community. The team is a micro-ummah. If its structure fractures, the community (users, charities, donors) suffers delayed aid, broken trust, and wasted *mal* (wealth).
|
||||
|
||||
Ask: *How did the Prophet ﷺ organize the Ummah at scale?* He used *Shura* (consultation) for every major decision, appointed *wulat* (governors) with clear territorial authority, and maintained *majlis* (councils) for cross-regional coordination. The *Sahaba* were organized into *asabiyyat* (clans) but operated as cross-functional squads for expeditions, da’wa, and governance.
|
||||
|
||||
Translate to your startup:
|
||||
- A **squad** is a *jama’a* (group) with a clear *amir* (product lead) and *shura council* (engineer, designer, QA).
|
||||
- A **guild** is a *majlis* (forum) for a discipline – e.g., all frontend engineers meet biweekly to share *maslaha* (benefit) practices.
|
||||
- A **chapter** is a *halaqa* (study circle) within a squad for a specific skill (e.g., security practices).
|
||||
|
||||
The root *illa* (cause) of the CEO bottleneck is: *lack of defined wilayah* (authority boundaries). The *hukm* is: delegation is *wajib* (obligatory) when the *maqsad* (speed, community service) cannot be achieved otherwise. The *shart* (condition): delegation must have *shura* built in.
|
||||
|
||||
### 3. EVIDENCE (ISTIDLAL)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Quantitative evidence:
|
||||
- **Cycle time** for a feature from ideation to production: 45 days (target: 10 days).
|
||||
- **Escalations to CEO** per week: 12 (target: 2).
|
||||
- **Net Promoter Score** from internal team survey: -10 (toxic dependency culture).
|
||||
|
||||
Qualitative evidence:
|
||||
- User interviews: “We asked for a recurring donation feature three months ago – still waiting.”
|
||||
- Engineering 1:1s: “I don’t know who makes product decisions. I just build what the CEO says.”
|
||||
- Design retrospectives: “We design in a vacuum; the charity team never sees our prototypes.”
|
||||
|
||||
Continuous Discovery also demands *outcome-based* evidence. The desired outcome is: *“A donor can set up a recurring charity donation within two clicks, verified by the charity in real-time.”* Currently, that requires 4 handoffs across 3 teams – each handoff adds 1 week delay. The Opportunity Solution Tree shows the highest-impact opportunity: *Define squad boundaries by user journey, not by technology.*
|
||||
|
||||
**MUJTAHID:**
|
||||
*Istidlal* (deduction of evidence) requires classifying *daleel* (proof) by strength.
|
||||
|
||||
**Qati’ al-Thubut wa Qati’ al-Dalala** (definitive in transmission and meaning): The Prophetic command in *Surah Al-Shura* (42:38): *“And those who have responded to their lord and established prayer and whose affairs are [conducted] through consultation among them…”* This is *qati’* – Shura is an *obligation* for collective affairs, not a recommendation. Your team organization *must* embed consultation.
|
||||
|
||||
**Zanni al-Thubut, Qati’ al-Dalala** (probable transmission, definitive meaning): The *hadith*: “The hand of Allah is with the *jama’a*” (Tirmidhi). The *jama’a* here is the unified squad – a group with shared purpose and mutual consultation.
|
||||
|
||||
**Qiyas** (analogy): The Prophet appointed *Mu’adh ibn Jabal* as governor of Yemen with clear authority to make *ijtihad* within his wilayah. Analogy: a squad should have autonomy to make product decisions *within its domain* without escalating to CEO, provided they consult their *shura* (squad members).
|
||||
|
||||
**Sad al-Dhara’i** (blocking the means to harm): The current structure (all decisions to CEO) creates a *dhari’a* (path) to *fitna* (disorder) – delays, resentment, burnout. Reorganizing into squads is *wajib* to block this harm.
|
||||
|
||||
**Maslaha Mursala** (unrestricted public interest): The *maqsad* of Hifz al-Nasl (preserving the team community) is served by squad autonomy. The evidence supports that *shura at scale* requires structural delegation.
|
||||
|
||||
### 4. SHURA (CONSULTATION)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Call a cross-functional sync. Invite: CEO, two senior engineers, one designer, one charity operations lead, one customer support lead. Agenda: “How should we organize to ship faster without losing quality?”
|
||||
|
||||
Use a *Shura Canvas*:
|
||||
- **Current state** (pain points, bottlenecks).
|
||||
- **Desired outcomes** (cycle time <10 days, CEO escalations <2/week).
|
||||
- **Proposed models**: squad/chapter/guild (Spotify-inspired, but adapted to Islamic values).
|
||||
- **Risks**: autonomy without accountability, duplication of work, loss of shared standards.
|
||||
|
||||
Ask each person: “What is your biggest fear about squads? What is your biggest hope?” Record all input. Weight by *khibra* (expertise) – the senior engineer’s concern about code duplication carries more weight than the designer’s aesthetic worry.
|
||||
|
||||
Make *dissenting opinions visible*: the charity ops lead worries that squads will ignore compliance. Write it on the board. Don’t suppress it – *shura* requires airing all views.
|
||||
|
||||
**MUJTAHID:**
|
||||
Shura in Usul al-Fiqh is not a vote; it is a *binding consultation* when the leader has delegated authority. The *mujtahid* (here, you as Product Lead) must:
|
||||
|
||||
1. **Identify the ahl al-shura** (those qualified to consult). Criteria: *adl* (integrity), *khibra* (expertise in their domain), *hilm* (deliberateness). Exclude those who are biased toward preserving their own power (e.g., the CEO who likes being gatekeeper).
|
||||
2. **Frame the question** clearly: *“What structure maximizes speed, quality, and community preservation?”*
|
||||
3. **Listen without interrupting** – the Prophet ﷺ would listen to all, even the youngest companion.
|
||||
4. **Weigh by maslaha** – the opinion that best serves *Hifz al-Nasl* (team unity and user community) and *Hifz al-Mal* (efficient use of resources) should be preferred.
|
||||
|
||||
After the session, write a *mahdar* (minutes) with:
|
||||
- All opinions recorded (names anonymized).
|
||||
- Weight assigned (1-5 scale based on expertise and relevance).
|
||||
- Dissenting opinions highlighted.
|
||||
- Your preliminary *takhayyur* (preferred opinion) – but do not finalize until you have completed the full *istidlal* above.
|
||||
|
||||
Now you have the raw material for the *Fatwa* – the ruling on how to organize your teams. The Discovery, Evidence, and Shura are done. The decision awaits in Part 2.
|
||||
|
||||
---
|
||||
|
||||
*End of Part 1. Next: Fatwa (Hukm, Daleel, Maqsad, Shurut, Munkathirat), Protocol, and Muhasaba.*## THE FATWA (HUKM)
|
||||
|
||||
**HUKM:** We will organize product teams into **cross-functional squads** (5–9 members) with a **Guild Shura council** composed of one representative per squad, meeting weekly to coordinate shared outcomes and preserve community cohesion.
|
||||
|
||||
**DALEEL:** Continuous discovery revealed that functional silos delayed decisions by 2–3 weeks, eroded trust, and fragmented the team’s sense of purpose. User interviews with squad members showed that weekly shura within the squad increased alignment and psychological safety. Islamic evidence: Quran 42:38 (“Their affairs are by mutual consultation”) and the Prophet’s ﷺ practice of consulting companions before major decisions. Qiyas (analogy) with the early Muslim community’s use of shura to balance autonomy and unity — squad autonomy mirrors local ijtihad, while the Guild council ensures maslaha (public benefit) across the organization.
|
||||
|
||||
**MAQSAD:** Hifz al-Nasl (Preservation of Community). The squad structure protects the team’s social fabric from fragmentation, ensures collective ownership, and nurtures a culture of mutual accountability — essential for long-term organizational health.
|
||||
|
||||
**SHURUT:**
|
||||
- Squad size: 5–9 members, always including at least one engineer, one designer, and one product person.
|
||||
- Each squad holds a **weekly internal shura** (30 min) to review decisions, surface blockers, and update their opportunity tree.
|
||||
- The Guild Shura council meets **every other week** with rotating facilitation; decisions require consensus or super-majority (≥70%) after open debate.
|
||||
- All team members must complete a 2-hour training on Shura adab (listening, ijtihad, respecting minority views).
|
||||
- North Star metric: **Team Health Score** (measured bi-weekly via eNPS + decision speed). Target: eNPS ≥ 50 and decision time < 2 days.
|
||||
|
||||
**MUNKATHIRAT** (Nullifiers / Rollback Triggers):
|
||||
- If Guild council meetings devolve into status updates without real deliberation (observed via meeting notes) — revert to ad-hoc coordination.
|
||||
- If squad eNPS drops below 20 for two consecutive sprints — dissolve the Guild structure and pilot a different model.
|
||||
- If two squads consistently conflict over shared resources and cannot resolve through shura — escalate to a Chapter lead with binding authority.
|
||||
|
||||
---
|
||||
|
||||
## THE PROTOCOL (3 Steps This Sprint)
|
||||
|
||||
**STEP 1 — Define Squad Boundaries & Charter**
|
||||
By end of Week 1, map your current team into squads based on product outcome areas (e.g., “Checkout Squad,” “Discovery Squad”). Write a one-page charter per squad: mission, key metrics, decision scope, and which other squads they depend on. Share with the entire team for feedback.
|
||||
|
||||
**STEP 2 — Train Everyone on Shura Adab**
|
||||
In Week 2, run a 2-hour workshop. Cover: the difference between debate and deliberation, how to prepare a short ijtihad statement (problem → evidence → proposed hukm), and the rule that silence equals consent unless explicitly opted out. Use a real product decision as practice (e.g., “Should we remove the onboarding wizard?”).
|
||||
|
||||
**STEP 3 — Launch the Guild Shura Council**
|
||||
By Week 3, each squad elects one representative (rotate every 4 sprints). Hold the first council meeting: establish a shared opportunity tree for cross-squad dependencies, set a rotating facilitator schedule, and agree on how to escalate unresolved disputes. Outcome: one written agreement on Shura council operating norms.
|
||||
|
||||
---
|
||||
|
||||
## MUHASABA (RETROSPECTIVE)
|
||||
|
||||
**What one signal will tell you that Shura is genuinely working — not just a meeting ritual — and how will you measure it this month?**
|
||||
|
||||
Piercing question: *“If Shura is real, decisions should get faster and better, not slower. Where is the decision that took longer after Shura than before — and what does that say about our process?”*
|
||||
|
||||
Track a single metric: **time from problem identification to final decision** (in hours). If it increases by more than 20% after implementing Shura, your council is likely debating instead of deliberating. Fix by adding a time-box and a clear “hukm” output per session.
|
||||
@@ -0,0 +1,92 @@
|
||||
## Part 1: Discovery, Evidence, and Shura
|
||||
|
||||
### 1. THE SCENARIO
|
||||
|
||||
You’re the Product Lead at *ZakatPay*, a growing fintech startup connecting users to verified charities. The team has grown from 5 to 25 engineers in six months. Silos are forming. The CEO pulls you aside: “Why is the payments squad building a dashboard without talking to the charity onboarding squad? And why do both of them report to me for every decision?” You open your notebook. The *Mujtahid* in you asks: *What is the hukm of organizing the team? What is the maqsad of our structure?* The *Product Lead* in you asks: *What’s the smallest change that gives us speed without chaos?*
|
||||
|
||||
### 2. DISCOVERY (ISTIQSA’)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Let’s start with Continuous Discovery. Open your Opportunity Solution Tree. The root opportunity is: *“Our team is too slow to respond to user needs because every decision escalates to the CEO.”* The parent opportunity is: *“Team lacks clear ownership boundaries.”* Child opportunities include: “No single point of accountability per feature area,” “Cross-functional dependencies block progress,” “Developers don’t know who to ask for product guidance.”
|
||||
|
||||
Now map the *Jobs-to-be-Done* for the organization itself. The org has three core JTBD:
|
||||
1. **Ship validated features weekly** – currently failing because of approval bottlenecks.
|
||||
2. **Maintain quality and risk compliance** – currently handled by CEO-as-gatekeeper, unsustainable.
|
||||
3. **Enable team growth and learning** – currently zero cross-squad knowledge sharing.
|
||||
|
||||
Draw four boxes on your whiteboard: *Functional* (all PMs together, all engineers together), *Cross-functional* (squads with PM+Eng+Design), *Guild* (community of practice across squads), *Chapter* (discipline-specific sync within squad). Your hypothesis: a squad model with chapters and guilds will unlock speed and preserve alignment.
|
||||
|
||||
**MUJTAHID:**
|
||||
*Istiqsa’* means exhaustive inquiry into the reality of the problem. The *maqsad* here is *Hifz al-Nasl* – preservation of the community. The team is a micro-ummah. If its structure fractures, the community (users, charities, donors) suffers delayed aid, broken trust, and wasted *mal* (wealth).
|
||||
|
||||
Ask: *How did the Prophet ﷺ organize the Ummah at scale?* He used *Shura* (consultation) for every major decision, appointed *wulat* (governors) with clear territorial authority, and maintained *majlis* (councils) for cross-regional coordination. The *Sahaba* were organized into *asabiyyat* (clans) but operated as cross-functional squads for expeditions, da’wa, and governance.
|
||||
|
||||
Translate to your startup:
|
||||
- A **squad** is a *jama’a* (group) with a clear *amir* (product lead) and *shura council* (engineer, designer, QA).
|
||||
- A **guild** is a *majlis* (forum) for a discipline – e.g., all frontend engineers meet biweekly to share *maslaha* (benefit) practices.
|
||||
- A **chapter** is a *halaqa* (study circle) within a squad for a specific skill (e.g., security practices).
|
||||
|
||||
The root *illa* (cause) of the CEO bottleneck is: *lack of defined wilayah* (authority boundaries). The *hukm* is: delegation is *wajib* (obligatory) when the *maqsad* (speed, community service) cannot be achieved otherwise. The *shart* (condition): delegation must have *shura* built in.
|
||||
|
||||
### 3. EVIDENCE (ISTIDLAL)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Quantitative evidence:
|
||||
- **Cycle time** for a feature from ideation to production: 45 days (target: 10 days).
|
||||
- **Escalations to CEO** per week: 12 (target: 2).
|
||||
- **Net Promoter Score** from internal team survey: -10 (toxic dependency culture).
|
||||
|
||||
Qualitative evidence:
|
||||
- User interviews: “We asked for a recurring donation feature three months ago – still waiting.”
|
||||
- Engineering 1:1s: “I don’t know who makes product decisions. I just build what the CEO says.”
|
||||
- Design retrospectives: “We design in a vacuum; the charity team never sees our prototypes.”
|
||||
|
||||
Continuous Discovery also demands *outcome-based* evidence. The desired outcome is: *“A donor can set up a recurring charity donation within two clicks, verified by the charity in real-time.”* Currently, that requires 4 handoffs across 3 teams – each handoff adds 1 week delay. The Opportunity Solution Tree shows the highest-impact opportunity: *Define squad boundaries by user journey, not by technology.*
|
||||
|
||||
**MUJTAHID:**
|
||||
*Istidlal* (deduction of evidence) requires classifying *daleel* (proof) by strength.
|
||||
|
||||
**Qati’ al-Thubut wa Qati’ al-Dalala** (definitive in transmission and meaning): The Prophetic command in *Surah Al-Shura* (42:38): *“And those who have responded to their lord and established prayer and whose affairs are [conducted] through consultation among them…”* This is *qati’* – Shura is an *obligation* for collective affairs, not a recommendation. Your team organization *must* embed consultation.
|
||||
|
||||
**Zanni al-Thubut, Qati’ al-Dalala** (probable transmission, definitive meaning): The *hadith*: “The hand of Allah is with the *jama’a*” (Tirmidhi). The *jama’a* here is the unified squad – a group with shared purpose and mutual consultation.
|
||||
|
||||
**Qiyas** (analogy): The Prophet appointed *Mu’adh ibn Jabal* as governor of Yemen with clear authority to make *ijtihad* within his wilayah. Analogy: a squad should have autonomy to make product decisions *within its domain* without escalating to CEO, provided they consult their *shura* (squad members).
|
||||
|
||||
**Sad al-Dhara’i** (blocking the means to harm): The current structure (all decisions to CEO) creates a *dhari’a* (path) to *fitna* (disorder) – delays, resentment, burnout. Reorganizing into squads is *wajib* to block this harm.
|
||||
|
||||
**Maslaha Mursala** (unrestricted public interest): The *maqsad* of Hifz al-Nasl (preserving the team community) is served by squad autonomy. The evidence supports that *shura at scale* requires structural delegation.
|
||||
|
||||
### 4. SHURA (CONSULTATION)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Call a cross-functional sync. Invite: CEO, two senior engineers, one designer, one charity operations lead, one customer support lead. Agenda: “How should we organize to ship faster without losing quality?”
|
||||
|
||||
Use a *Shura Canvas*:
|
||||
- **Current state** (pain points, bottlenecks).
|
||||
- **Desired outcomes** (cycle time <10 days, CEO escalations <2/week).
|
||||
- **Proposed models**: squad/chapter/guild (Spotify-inspired, but adapted to Islamic values).
|
||||
- **Risks**: autonomy without accountability, duplication of work, loss of shared standards.
|
||||
|
||||
Ask each person: “What is your biggest fear about squads? What is your biggest hope?” Record all input. Weight by *khibra* (expertise) – the senior engineer’s concern about code duplication carries more weight than the designer’s aesthetic worry.
|
||||
|
||||
Make *dissenting opinions visible*: the charity ops lead worries that squads will ignore compliance. Write it on the board. Don’t suppress it – *shura* requires airing all views.
|
||||
|
||||
**MUJTAHID:**
|
||||
Shura in Usul al-Fiqh is not a vote; it is a *binding consultation* when the leader has delegated authority. The *mujtahid* (here, you as Product Lead) must:
|
||||
|
||||
1. **Identify the ahl al-shura** (those qualified to consult). Criteria: *adl* (integrity), *khibra* (expertise in their domain), *hilm* (deliberateness). Exclude those who are biased toward preserving their own power (e.g., the CEO who likes being gatekeeper).
|
||||
2. **Frame the question** clearly: *“What structure maximizes speed, quality, and community preservation?”*
|
||||
3. **Listen without interrupting** – the Prophet ﷺ would listen to all, even the youngest companion.
|
||||
4. **Weigh by maslaha** – the opinion that best serves *Hifz al-Nasl* (team unity and user community) and *Hifz al-Mal* (efficient use of resources) should be preferred.
|
||||
|
||||
After the session, write a *mahdar* (minutes) with:
|
||||
- All opinions recorded (names anonymized).
|
||||
- Weight assigned (1-5 scale based on expertise and relevance).
|
||||
- Dissenting opinions highlighted.
|
||||
- Your preliminary *takhayyur* (preferred opinion) – but do not finalize until you have completed the full *istidlal* above.
|
||||
|
||||
Now you have the raw material for the *Fatwa* – the ruling on how to organize your teams. The Discovery, Evidence, and Shura are done. The decision awaits in Part 2.
|
||||
|
||||
---
|
||||
|
||||
*End of Part 1. Next: Fatwa (Hukm, Daleel, Maqsad, Shurut, Munkathirat), Protocol, and Muhasaba.*
|
||||
@@ -0,0 +1,42 @@
|
||||
## THE FATWA (HUKM)
|
||||
|
||||
**HUKM:** We will organize product teams into **cross-functional squads** (5–9 members) with a **Guild Shura council** composed of one representative per squad, meeting weekly to coordinate shared outcomes and preserve community cohesion.
|
||||
|
||||
**DALEEL:** Continuous discovery revealed that functional silos delayed decisions by 2–3 weeks, eroded trust, and fragmented the team’s sense of purpose. User interviews with squad members showed that weekly shura within the squad increased alignment and psychological safety. Islamic evidence: Quran 42:38 (“Their affairs are by mutual consultation”) and the Prophet’s ﷺ practice of consulting companions before major decisions. Qiyas (analogy) with the early Muslim community’s use of shura to balance autonomy and unity — squad autonomy mirrors local ijtihad, while the Guild council ensures maslaha (public benefit) across the organization.
|
||||
|
||||
**MAQSAD:** Hifz al-Nasl (Preservation of Community). The squad structure protects the team’s social fabric from fragmentation, ensures collective ownership, and nurtures a culture of mutual accountability — essential for long-term organizational health.
|
||||
|
||||
**SHURUT:**
|
||||
- Squad size: 5–9 members, always including at least one engineer, one designer, and one product person.
|
||||
- Each squad holds a **weekly internal shura** (30 min) to review decisions, surface blockers, and update their opportunity tree.
|
||||
- The Guild Shura council meets **every other week** with rotating facilitation; decisions require consensus or super-majority (≥70%) after open debate.
|
||||
- All team members must complete a 2-hour training on Shura adab (listening, ijtihad, respecting minority views).
|
||||
- North Star metric: **Team Health Score** (measured bi-weekly via eNPS + decision speed). Target: eNPS ≥ 50 and decision time < 2 days.
|
||||
|
||||
**MUNKATHIRAT** (Nullifiers / Rollback Triggers):
|
||||
- If Guild council meetings devolve into status updates without real deliberation (observed via meeting notes) — revert to ad-hoc coordination.
|
||||
- If squad eNPS drops below 20 for two consecutive sprints — dissolve the Guild structure and pilot a different model.
|
||||
- If two squads consistently conflict over shared resources and cannot resolve through shura — escalate to a Chapter lead with binding authority.
|
||||
|
||||
---
|
||||
|
||||
## THE PROTOCOL (3 Steps This Sprint)
|
||||
|
||||
**STEP 1 — Define Squad Boundaries & Charter**
|
||||
By end of Week 1, map your current team into squads based on product outcome areas (e.g., “Checkout Squad,” “Discovery Squad”). Write a one-page charter per squad: mission, key metrics, decision scope, and which other squads they depend on. Share with the entire team for feedback.
|
||||
|
||||
**STEP 2 — Train Everyone on Shura Adab**
|
||||
In Week 2, run a 2-hour workshop. Cover: the difference between debate and deliberation, how to prepare a short ijtihad statement (problem → evidence → proposed hukm), and the rule that silence equals consent unless explicitly opted out. Use a real product decision as practice (e.g., “Should we remove the onboarding wizard?”).
|
||||
|
||||
**STEP 3 — Launch the Guild Shura Council**
|
||||
By Week 3, each squad elects one representative (rotate every 4 sprints). Hold the first council meeting: establish a shared opportunity tree for cross-squad dependencies, set a rotating facilitator schedule, and agree on how to escalate unresolved disputes. Outcome: one written agreement on Shura council operating norms.
|
||||
|
||||
---
|
||||
|
||||
## MUHASABA (RETROSPECTIVE)
|
||||
|
||||
**What one signal will tell you that Shura is genuinely working — not just a meeting ritual — and how will you measure it this month?**
|
||||
|
||||
Piercing question: *“If Shura is real, decisions should get faster and better, not slower. Where is the decision that took longer after Shura than before — and what does that say about our process?”*
|
||||
|
||||
Track a single metric: **time from problem identification to final decision** (in hours). If it increases by more than 20% after implementing Shura, your council is likely debating instead of deliberating. Fix by adding a time-box and a clear “hukm” output per session.
|
||||
@@ -0,0 +1,153 @@
|
||||
# FATWA #10: LEGACY PRODUCT — SADAQAH JARIYAH AS COMPOUND IMPACT
|
||||
|
||||
**Maqsad:** Hifz al-Din (Preservation of Purpose) → Sadaqah Jariyah Product
|
||||
**Framework:** Legacy Loop: Create → Ship → Measure → Compound → Endow → Teach
|
||||
|
||||
---
|
||||
|
||||
## 1. THE SCENARIO
|
||||
|
||||
You're the Product Lead at a growing fintech startup. Your CEO walks into the weekly sync and throws a curveball: *"Why are we building this feature? We've got six months of runway. Every sprint needs to count. What's the point of this thing if I die next year?"*
|
||||
|
||||
The room goes quiet. Your engineering lead stares at the ceiling. Your designer doodles a tombstone.
|
||||
|
||||
You open your notebook. The Mujtahid inside you starts whispering: *"What is the hukm of this feature? What is its maqsad? Does it die when the company dies? Or does it keep giving—sadaqah jariyah?"*
|
||||
|
||||
Your CEO isn't asking for a roadmap. He's asking for a theology of product. And you realize: the most powerful product you can build is one that outlives you.
|
||||
|
||||
---
|
||||
|
||||
## 2. DISCOVERY (ISTIQSA')
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Let's start with the Opportunity Solution Tree. Draw it on the whiteboard.
|
||||
|
||||
- **Opportunity:** Users want their financial actions to have lasting meaning beyond their own lifetime. They want to be part of something that compounds—a donation that keeps funding, a knowledge base that keeps teaching, a system that keeps operating without them.
|
||||
- **JTBD:** "Help me create something that benefits others long after I'm gone—without me having to manage it manually."
|
||||
- **Current behavior:** Users set up recurring donations, write wills, or build simple automations. But none of these compound. They're linear—one transaction, one impact, then stop.
|
||||
- **Desired outcome:** A product that becomes a flywheel—each unit of input generates ongoing output, and that output generates more input.
|
||||
|
||||
Now interview three users who have been with the platform for over two years. Ask: *"What do you hope happens to your account if you stop logging in for five years?"* One says: *"I want my recurring charity to keep going."* Another: *"I want my kids to inherit my investment strategy."* The third: *"I want my savings goals to auto-adjust for inflation so my future grandkids still benefit."*
|
||||
|
||||
They all want the same thing: a product that doesn't degrade when they're not watching.
|
||||
|
||||
**MUJTAHID:**
|
||||
Let me run Istiqsa'—a comprehensive exploration of the problem space through the lens of Maqasid.
|
||||
|
||||
First, define *Sadaqah Jariyah* in product terms. From the hadith: *"When a person dies, his deeds are cut off except for three: ongoing charity (sadaqah jariyah), beneficial knowledge, or a righteous child who prays for him."* (Muslim)
|
||||
|
||||
The key word is *jariyah*—flowing, continuous. Not a one-time burst. A product that generates ongoing benefit without ongoing effort from the creator.
|
||||
|
||||
Now ask: **How does a product become sadaqah jariyah?** It must meet three conditions:
|
||||
1. **Benefit is ongoing**—the product continues to serve users after the creator stops active maintenance.
|
||||
2. **Benefit is multiplied**—each user's interaction creates benefit for others (compound effect).
|
||||
3. **Source is preserved**—the knowledge or system is handed over, open-sourced, or endowed so it can't be easily killed.
|
||||
|
||||
What products have done this? Wikipedia—anyone can edit, the knowledge compounds. Linux—the source is free, the community maintains it. Open source libraries—a single commit can benefit millions for decades.
|
||||
|
||||
But in fintech? Most products die when the company stops paying servers. The default state of a SaaS product is decay. We need to design for *permanence*.
|
||||
|
||||
Define the problem space more sharply:
|
||||
- **The core tension:** We want users to trust us with their financial legacy, but we can't guarantee the company will outlive them. So the product must be *portable*—able to run independently.
|
||||
- **The maqsad (purpose):** Hifz al-Din—preserving the purpose (benefit) of the user's intention. If a user sets up a recurring charity, the purpose is that the charity continues. Our product must not allow that intention to die.
|
||||
- **The hukm (ruling):** Building a product that is intentionally designed to outlive its creator is *mandub* (recommended) when it serves a clear benefit, and *wajib* (obligatory) if the user's intention depends on it—like a waqf.
|
||||
|
||||
---
|
||||
|
||||
## 3. EVIDENCE (ISTIDLAL)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Let's gather the evidence—quantitative and qualitative.
|
||||
|
||||
**Quantitative:**
|
||||
- Pull data on user retention by cohort. Look at users who set up automated recurring actions (donations, savings, investments) more than 12 months ago. What percentage are still active? 73% still have the automation running, but only 12% have revisited the settings. That means 61% are "set and forget." Good—it means they trust the system. But also dangerous—if the system stops, they won't know.
|
||||
- Analyze referral loops. Users who refer others have a 2.3x higher lifetime value. But the real compound effect is in *knowledge sharing*: users who create educational content (videos, blog posts, templates) generate 4.8x more engaged users over 6 months. That's a compound curve.
|
||||
- Look at churn reasons: 34% of churned users said "I don't need the product anymore." But when interviewed, many said they actually *wanted* it to keep running for their family. They just assumed it would stop.
|
||||
|
||||
**Qualitative:**
|
||||
- Interview 10 power users who have been on the platform for 2+ years. Ask: *"What would you pay for to ensure this product runs for your grandchildren?"* 8 out of 10 said they'd pay an annual "endowment fee" or contribute to a fund that keeps the service alive. One user said: *"I'd rather pay $50/year now than have my kids set up everything from scratch."*
|
||||
- Interview 5 former users who churned. Ask: *"If someone else could maintain your settings and keep the benefit flowing, would you have stayed?"* 4 said yes. They left because they felt the product was "abandoned."
|
||||
|
||||
**MUJTAHID:**
|
||||
Now let's apply the Daleel hierarchy.
|
||||
|
||||
**Qati al-Thubut (certain transmission):** The hadith of sadaqah jariyah is mutawatir—mass transmitted, unquestionable. The Prophet (sallallahu alayhi wasallam) explicitly linked ongoing charity to ongoing benefit. This is a clear textual basis for designing products that generate continuous impact.
|
||||
|
||||
**Qati al-Dalala (clear meaning):** The word *jariyah* means flowing water, continuous stream. The implication is clear: the benefit must flow without interruption. A product that stops when the creator stops is not sadaqah jariyah. It's sadaqah mu'ajjalah (temporary charity).
|
||||
|
||||
**Zanni al-Dalala (ambiguous meaning):** What qualifies as "ongoing benefit"? Is a software product that requires periodic updates still jariyah? The answer lies in *maqasid*: if the benefit depends on updates, then the product must be designed to be updated by others. So the product must include a *succession mechanism*—a way for new maintainers to take over.
|
||||
|
||||
**Istidlal bi al-Maslaha (reasoning by public interest):** The compound effect of a product that benefits generation after generation is a clear maslaha (public good). The scholars say: *"Wherever the maslaha is found, there lies the Shariah."* So if we can build a product that compounds impact, it is not just allowed—it is encouraged.
|
||||
|
||||
**Qiyas (analogy):** Compare a product to a waqf (endowment). A waqf is a perpetual charity—the principal remains, the benefit flows. A product can be structured the same way: the code (principal) remains open or endowed, the user benefit (income) flows indefinitely. The analogy holds.
|
||||
|
||||
**Sad al-Dhara'i (blocking the means of harm):** The opposite of sadaqah jariyah is a product that *stops* benefiting. That's the harm. So we must design against that: build in redundancy, portability, and endowment mechanisms.
|
||||
|
||||
**Measurement of generational impact:**
|
||||
- **Depth of impact:** How many downstream users benefit from one original user's action? (e.g., one user creates a template → 100 users use it → each of those shares it → exponential)
|
||||
- **Duration of impact:** How many years does the benefit last after the creator stops? (target: 10+ years)
|
||||
- **Intensity of impact:** How much benefit per user per year? (e.g., $100 donated annually per user)
|
||||
|
||||
The "interest rate" on product impact: if one unit of effort creates 10 units of benefit per year forever, that's a compound curve. The goal is to make the product *multiply* effort, not just amplify it.
|
||||
|
||||
---
|
||||
|
||||
## 4. SHURA
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Time to consult the stakeholders. Set up three meetings:
|
||||
|
||||
1. **CEO + CTO:** Present the finding that users want their product to outlive them. Ask: *"Are we willing to invest in a feature that may not pay back in 6 months, but compounds over decades?"* CEO is skeptical: *"We have runway pressure."* CTO is curious: *"We'd need to rethink our architecture—more modular, maybe open-source parts."* Record both views.
|
||||
|
||||
2. **Design + Research:** Show the user quotes. Designer says: *"We'd need a 'legacy mode'—a UI that lets users set up succession plans."* Researcher adds: *"We should test with users who have kids. They care most."* Document these insights.
|
||||
|
||||
3. **Finance + Legal:** Bring the idea of an "endowment fund" where users pay to keep the service alive. Finance says: *"That's a recurring revenue model—I like it."* Legal warns: *"If we sell it as 'perpetual,' we need to be careful about promises. Better to say 'ongoing' with disclaimers."*
|
||||
|
||||
**MUJTAHID:**
|
||||
Shura in Usul al-Fiqh is not just gathering opinions—it's *weighting* evidence and *recording dissent*.
|
||||
|
||||
The principle: *"Consult them in the matter, and when you have decided, rely upon Allah."* (Qur'an 3:159). The decision is yours after shura, but the shura must be sincere.
|
||||
|
||||
**Weighting input:**
|
||||
- **CEO's concern (runway)** is a real constraint. It's a *shart* (condition) of survival. If the company dies, no product survives. So the legacy feature must be designed to not drain resources now.
|
||||
- **CTO's architectural shift** is a higher *maslaha*—modular design benefits all features, not just legacy. Weight it heavily.
|
||||
- **Legal's caution** is a *sadd al-dhara'i*—we must block the harm of false promises. So we avoid the word "perpetual"## THE FATWA (HUKM)
|
||||
|
||||
**HUKM:** We will build a Sadaqah Jariyah Endowment product that allows users to endow capital (cash, stocks, or crypto) into a Shariah-compliant investment pool, with automatic distribution of returns to pre-selected causes, and the option to add new capital over time to compound the perpetual impact.
|
||||
|
||||
**DALEEL:** Continuous discovery (15 user interviews, 3 stakeholder workshops) revealed that 80% of high-value donors want a “legacy that outlives me” and are willing to endow at least 10% of their net worth if the process is simple and trustworthy. Quantitative analysis showed that recurring donors have 3x higher lifetime value and 40% lower churn. Shariah evidence (Qiyas on Waqf, Istihsan for modern investment vehicles, and Maslaha Mursala for compounding returns) supports the model: the principal is preserved (Hifz al-Mal), the returns are continuously distributed (Hifz al-Din), and the donor’s intention (niyyah) is locked in perpetuity, fulfilling the Sunnah of ongoing charity.
|
||||
|
||||
**MAQSAD:** Primary: Hifz al-Din (preservation of purpose) — enabling the donor’s act of worship to continue beyond their lifetime. Secondary: Hifz al-Mal (preservation of wealth) by ensuring the principal is never consumed and only ethically invested. Tertiary: Hifz al-Nasl (preservation of progeny) — the endowment can be designated to benefit future generations.
|
||||
|
||||
**SHURUT (Conditions & Constraints):**
|
||||
- Minimum endowment threshold: $5,000 (to cover legal, investment, and operational costs).
|
||||
- All investments must be Shariah-compliant (certified by internal Shariah board quarterly).
|
||||
- Transparent dashboard showing principal growth, returns distributed, and impact stories — updated monthly.
|
||||
- Rollback trigger: If the endowment’s real value (adjusted for inflation) declines by 20% over a 12-month moving average, distributions are paused until capital is restored.
|
||||
- Donor can only modify beneficiary assignments once per year, and cannot withdraw the principal after the first distribution cycle.
|
||||
|
||||
**MUNKATHIRAT (Nullifiers / Rollback Triggers):**
|
||||
- If the Shariah board revokes compliance certification for the investment pool, all endowments are frozen and capital returned (minus costs) to donors or their heirs.
|
||||
- If regulatory changes in any jurisdiction make perpetual endowments illegal or tax-disadvantageous, the product is sunset with a 90-day grace period for donors to reassign capital.
|
||||
- If the donor dies and no valid heir or successor is named, the endowment reverts to our default beneficiary pool (pre-approved causes), nullifying the donor’s specific intention.
|
||||
|
||||
---
|
||||
|
||||
## THE PROTOCOL (3 Steps for This Sprint)
|
||||
|
||||
**STEP 1: Define the minimum viable endowment tiers.**
|
||||
This week, work with legal, finance, and Shariah to finalize three tiers: Basic ($5k – $20k), Growth ($20k – $100k), and Legacy ($100k+). Each tier has a different investment risk profile (low, moderate, balanced) and fee structure. Document the Shariah screens for each tier. *Deadline: Friday.*
|
||||
|
||||
**STEP 2: Build a distribution calculator prototype.**
|
||||
Build a simple spreadsheet (or low-code tool) that shows a donor: (a) their principal, (b) projected annual returns at 4%, 6%, and 8%, (c) how many meals, wells, or scholarships that translates to, and (d) the compounding effect if they add $1,000/year. Test with 3 power users from the discovery group. *Deadline: Next Wednesday.*
|
||||
|
||||
**STEP 3: Create the endowment agreement template.**
|
||||
Draft a one-page legal-ethical agreement that covers: donor’s intention (niyyah), beneficiary list, investment policy, rollback triggers, and succession plan. Must be readable in 5 minutes. Get Shariah board approval. *Deadline: End of sprint.*
|
||||
|
||||
---
|
||||
|
||||
## MUHASABA (RETROSPECTIVE)
|
||||
|
||||
**Where did we prioritize financial sustainability over spiritual fidelity, and how do we course-correct before ship?**
|
||||
|
||||
The hardest question: Are we building a product that *feels* like investing with a charity wrapper, or are we truly enabling a sacred act of *sadaqah jariyah*? The metrics we chose (retention, LTV, AUM) are commercial. The Maqsad is spiritual. If our dashboard shows “returns” before “lives touched,” we have already nullified the donor’s intention. The next sprint must reframe the user story: not “I invest for growth” but “I endow for eternity.” Let’s replace one commercial KPI with a spiritual one — e.g., “number of beneficiaries per endowment” as a North Star. If we don’t, the fatwa dissolves.
|
||||
@@ -0,0 +1,114 @@
|
||||
# FATWA #10: LEGACY PRODUCT — SADAQAH JARIYAH AS COMPOUND IMPACT
|
||||
|
||||
**Maqsad:** Hifz al-Din (Preservation of Purpose) → Sadaqah Jariyah Product
|
||||
**Framework:** Legacy Loop: Create → Ship → Measure → Compound → Endow → Teach
|
||||
|
||||
---
|
||||
|
||||
## 1. THE SCENARIO
|
||||
|
||||
You're the Product Lead at a growing fintech startup. Your CEO walks into the weekly sync and throws a curveball: *"Why are we building this feature? We've got six months of runway. Every sprint needs to count. What's the point of this thing if I die next year?"*
|
||||
|
||||
The room goes quiet. Your engineering lead stares at the ceiling. Your designer doodles a tombstone.
|
||||
|
||||
You open your notebook. The Mujtahid inside you starts whispering: *"What is the hukm of this feature? What is its maqsad? Does it die when the company dies? Or does it keep giving—sadaqah jariyah?"*
|
||||
|
||||
Your CEO isn't asking for a roadmap. He's asking for a theology of product. And you realize: the most powerful product you can build is one that outlives you.
|
||||
|
||||
---
|
||||
|
||||
## 2. DISCOVERY (ISTIQSA')
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Let's start with the Opportunity Solution Tree. Draw it on the whiteboard.
|
||||
|
||||
- **Opportunity:** Users want their financial actions to have lasting meaning beyond their own lifetime. They want to be part of something that compounds—a donation that keeps funding, a knowledge base that keeps teaching, a system that keeps operating without them.
|
||||
- **JTBD:** "Help me create something that benefits others long after I'm gone—without me having to manage it manually."
|
||||
- **Current behavior:** Users set up recurring donations, write wills, or build simple automations. But none of these compound. They're linear—one transaction, one impact, then stop.
|
||||
- **Desired outcome:** A product that becomes a flywheel—each unit of input generates ongoing output, and that output generates more input.
|
||||
|
||||
Now interview three users who have been with the platform for over two years. Ask: *"What do you hope happens to your account if you stop logging in for five years?"* One says: *"I want my recurring charity to keep going."* Another: *"I want my kids to inherit my investment strategy."* The third: *"I want my savings goals to auto-adjust for inflation so my future grandkids still benefit."*
|
||||
|
||||
They all want the same thing: a product that doesn't degrade when they're not watching.
|
||||
|
||||
**MUJTAHID:**
|
||||
Let me run Istiqsa'—a comprehensive exploration of the problem space through the lens of Maqasid.
|
||||
|
||||
First, define *Sadaqah Jariyah* in product terms. From the hadith: *"When a person dies, his deeds are cut off except for three: ongoing charity (sadaqah jariyah), beneficial knowledge, or a righteous child who prays for him."* (Muslim)
|
||||
|
||||
The key word is *jariyah*—flowing, continuous. Not a one-time burst. A product that generates ongoing benefit without ongoing effort from the creator.
|
||||
|
||||
Now ask: **How does a product become sadaqah jariyah?** It must meet three conditions:
|
||||
1. **Benefit is ongoing**—the product continues to serve users after the creator stops active maintenance.
|
||||
2. **Benefit is multiplied**—each user's interaction creates benefit for others (compound effect).
|
||||
3. **Source is preserved**—the knowledge or system is handed over, open-sourced, or endowed so it can't be easily killed.
|
||||
|
||||
What products have done this? Wikipedia—anyone can edit, the knowledge compounds. Linux—the source is free, the community maintains it. Open source libraries—a single commit can benefit millions for decades.
|
||||
|
||||
But in fintech? Most products die when the company stops paying servers. The default state of a SaaS product is decay. We need to design for *permanence*.
|
||||
|
||||
Define the problem space more sharply:
|
||||
- **The core tension:** We want users to trust us with their financial legacy, but we can't guarantee the company will outlive them. So the product must be *portable*—able to run independently.
|
||||
- **The maqsad (purpose):** Hifz al-Din—preserving the purpose (benefit) of the user's intention. If a user sets up a recurring charity, the purpose is that the charity continues. Our product must not allow that intention to die.
|
||||
- **The hukm (ruling):** Building a product that is intentionally designed to outlive its creator is *mandub* (recommended) when it serves a clear benefit, and *wajib* (obligatory) if the user's intention depends on it—like a waqf.
|
||||
|
||||
---
|
||||
|
||||
## 3. EVIDENCE (ISTIDLAL)
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Let's gather the evidence—quantitative and qualitative.
|
||||
|
||||
**Quantitative:**
|
||||
- Pull data on user retention by cohort. Look at users who set up automated recurring actions (donations, savings, investments) more than 12 months ago. What percentage are still active? 73% still have the automation running, but only 12% have revisited the settings. That means 61% are "set and forget." Good—it means they trust the system. But also dangerous—if the system stops, they won't know.
|
||||
- Analyze referral loops. Users who refer others have a 2.3x higher lifetime value. But the real compound effect is in *knowledge sharing*: users who create educational content (videos, blog posts, templates) generate 4.8x more engaged users over 6 months. That's a compound curve.
|
||||
- Look at churn reasons: 34% of churned users said "I don't need the product anymore." But when interviewed, many said they actually *wanted* it to keep running for their family. They just assumed it would stop.
|
||||
|
||||
**Qualitative:**
|
||||
- Interview 10 power users who have been on the platform for 2+ years. Ask: *"What would you pay for to ensure this product runs for your grandchildren?"* 8 out of 10 said they'd pay an annual "endowment fee" or contribute to a fund that keeps the service alive. One user said: *"I'd rather pay $50/year now than have my kids set up everything from scratch."*
|
||||
- Interview 5 former users who churned. Ask: *"If someone else could maintain your settings and keep the benefit flowing, would you have stayed?"* 4 said yes. They left because they felt the product was "abandoned."
|
||||
|
||||
**MUJTAHID:**
|
||||
Now let's apply the Daleel hierarchy.
|
||||
|
||||
**Qati al-Thubut (certain transmission):** The hadith of sadaqah jariyah is mutawatir—mass transmitted, unquestionable. The Prophet (sallallahu alayhi wasallam) explicitly linked ongoing charity to ongoing benefit. This is a clear textual basis for designing products that generate continuous impact.
|
||||
|
||||
**Qati al-Dalala (clear meaning):** The word *jariyah* means flowing water, continuous stream. The implication is clear: the benefit must flow without interruption. A product that stops when the creator stops is not sadaqah jariyah. It's sadaqah mu'ajjalah (temporary charity).
|
||||
|
||||
**Zanni al-Dalala (ambiguous meaning):** What qualifies as "ongoing benefit"? Is a software product that requires periodic updates still jariyah? The answer lies in *maqasid*: if the benefit depends on updates, then the product must be designed to be updated by others. So the product must include a *succession mechanism*—a way for new maintainers to take over.
|
||||
|
||||
**Istidlal bi al-Maslaha (reasoning by public interest):** The compound effect of a product that benefits generation after generation is a clear maslaha (public good). The scholars say: *"Wherever the maslaha is found, there lies the Shariah."* So if we can build a product that compounds impact, it is not just allowed—it is encouraged.
|
||||
|
||||
**Qiyas (analogy):** Compare a product to a waqf (endowment). A waqf is a perpetual charity—the principal remains, the benefit flows. A product can be structured the same way: the code (principal) remains open or endowed, the user benefit (income) flows indefinitely. The analogy holds.
|
||||
|
||||
**Sad al-Dhara'i (blocking the means of harm):** The opposite of sadaqah jariyah is a product that *stops* benefiting. That's the harm. So we must design against that: build in redundancy, portability, and endowment mechanisms.
|
||||
|
||||
**Measurement of generational impact:**
|
||||
- **Depth of impact:** How many downstream users benefit from one original user's action? (e.g., one user creates a template → 100 users use it → each of those shares it → exponential)
|
||||
- **Duration of impact:** How many years does the benefit last after the creator stops? (target: 10+ years)
|
||||
- **Intensity of impact:** How much benefit per user per year? (e.g., $100 donated annually per user)
|
||||
|
||||
The "interest rate" on product impact: if one unit of effort creates 10 units of benefit per year forever, that's a compound curve. The goal is to make the product *multiply* effort, not just amplify it.
|
||||
|
||||
---
|
||||
|
||||
## 4. SHURA
|
||||
|
||||
**PRODUCT_LEAD:**
|
||||
Time to consult the stakeholders. Set up three meetings:
|
||||
|
||||
1. **CEO + CTO:** Present the finding that users want their product to outlive them. Ask: *"Are we willing to invest in a feature that may not pay back in 6 months, but compounds over decades?"* CEO is skeptical: *"We have runway pressure."* CTO is curious: *"We'd need to rethink our architecture—more modular, maybe open-source parts."* Record both views.
|
||||
|
||||
2. **Design + Research:** Show the user quotes. Designer says: *"We'd need a 'legacy mode'—a UI that lets users set up succession plans."* Researcher adds: *"We should test with users who have kids. They care most."* Document these insights.
|
||||
|
||||
3. **Finance + Legal:** Bring the idea of an "endowment fund" where users pay to keep the service alive. Finance says: *"That's a recurring revenue model—I like it."* Legal warns: *"If we sell it as 'perpetual,' we need to be careful about promises. Better to say 'ongoing' with disclaimers."*
|
||||
|
||||
**MUJTAHID:**
|
||||
Shura in Usul al-Fiqh is not just gathering opinions—it's *weighting* evidence and *recording dissent*.
|
||||
|
||||
The principle: *"Consult them in the matter, and when you have decided, rely upon Allah."* (Qur'an 3:159). The decision is yours after shura, but the shura must be sincere.
|
||||
|
||||
**Weighting input:**
|
||||
- **CEO's concern (runway)** is a real constraint. It's a *shart* (condition) of survival. If the company dies, no product survives. So the legacy feature must be designed to not drain resources now.
|
||||
- **CTO's architectural shift** is a higher *maslaha*—modular design benefits all features, not just legacy. Weight it heavily.
|
||||
- **Legal's caution** is a *sadd al-dhara'i*—we must block the harm of false promises. So we avoid the word "perpetual"
|
||||
@@ -0,0 +1,40 @@
|
||||
## THE FATWA (HUKM)
|
||||
|
||||
**HUKM:** We will build a Sadaqah Jariyah Endowment product that allows users to endow capital (cash, stocks, or crypto) into a Shariah-compliant investment pool, with automatic distribution of returns to pre-selected causes, and the option to add new capital over time to compound the perpetual impact.
|
||||
|
||||
**DALEEL:** Continuous discovery (15 user interviews, 3 stakeholder workshops) revealed that 80% of high-value donors want a “legacy that outlives me” and are willing to endow at least 10% of their net worth if the process is simple and trustworthy. Quantitative analysis showed that recurring donors have 3x higher lifetime value and 40% lower churn. Shariah evidence (Qiyas on Waqf, Istihsan for modern investment vehicles, and Maslaha Mursala for compounding returns) supports the model: the principal is preserved (Hifz al-Mal), the returns are continuously distributed (Hifz al-Din), and the donor’s intention (niyyah) is locked in perpetuity, fulfilling the Sunnah of ongoing charity.
|
||||
|
||||
**MAQSAD:** Primary: Hifz al-Din (preservation of purpose) — enabling the donor’s act of worship to continue beyond their lifetime. Secondary: Hifz al-Mal (preservation of wealth) by ensuring the principal is never consumed and only ethically invested. Tertiary: Hifz al-Nasl (preservation of progeny) — the endowment can be designated to benefit future generations.
|
||||
|
||||
**SHURUT (Conditions & Constraints):**
|
||||
- Minimum endowment threshold: $5,000 (to cover legal, investment, and operational costs).
|
||||
- All investments must be Shariah-compliant (certified by internal Shariah board quarterly).
|
||||
- Transparent dashboard showing principal growth, returns distributed, and impact stories — updated monthly.
|
||||
- Rollback trigger: If the endowment’s real value (adjusted for inflation) declines by 20% over a 12-month moving average, distributions are paused until capital is restored.
|
||||
- Donor can only modify beneficiary assignments once per year, and cannot withdraw the principal after the first distribution cycle.
|
||||
|
||||
**MUNKATHIRAT (Nullifiers / Rollback Triggers):**
|
||||
- If the Shariah board revokes compliance certification for the investment pool, all endowments are frozen and capital returned (minus costs) to donors or their heirs.
|
||||
- If regulatory changes in any jurisdiction make perpetual endowments illegal or tax-disadvantageous, the product is sunset with a 90-day grace period for donors to reassign capital.
|
||||
- If the donor dies and no valid heir or successor is named, the endowment reverts to our default beneficiary pool (pre-approved causes), nullifying the donor’s specific intention.
|
||||
|
||||
---
|
||||
|
||||
## THE PROTOCOL (3 Steps for This Sprint)
|
||||
|
||||
**STEP 1: Define the minimum viable endowment tiers.**
|
||||
This week, work with legal, finance, and Shariah to finalize three tiers: Basic ($5k – $20k), Growth ($20k – $100k), and Legacy ($100k+). Each tier has a different investment risk profile (low, moderate, balanced) and fee structure. Document the Shariah screens for each tier. *Deadline: Friday.*
|
||||
|
||||
**STEP 2: Build a distribution calculator prototype.**
|
||||
Build a simple spreadsheet (or low-code tool) that shows a donor: (a) their principal, (b) projected annual returns at 4%, 6%, and 8%, (c) how many meals, wells, or scholarships that translates to, and (d) the compounding effect if they add $1,000/year. Test with 3 power users from the discovery group. *Deadline: Next Wednesday.*
|
||||
|
||||
**STEP 3: Create the endowment agreement template.**
|
||||
Draft a one-page legal-ethical agreement that covers: donor’s intention (niyyah), beneficiary list, investment policy, rollback triggers, and succession plan. Must be readable in 5 minutes. Get Shariah board approval. *Deadline: End of sprint.*
|
||||
|
||||
---
|
||||
|
||||
## MUHASABA (RETROSPECTIVE)
|
||||
|
||||
**Where did we prioritize financial sustainability over spiritual fidelity, and how do we course-correct before ship?**
|
||||
|
||||
The hardest question: Are we building a product that *feels* like investing with a charity wrapper, or are we truly enabling a sacred act of *sadaqah jariyah*? The metrics we chose (retention, LTV, AUM) are commercial. The Maqsad is spiritual. If our dashboard shows “returns” before “lives touched,” we have already nullified the donor’s intention. The next sprint must reframe the user story: not “I invest for growth” but “I endow for eternity.” Let’s replace one commercial KPI with a spiritual one — e.g., “number of beneficiaries per endowment” as a North Star. If we don’t, the fatwa dissolves.
|
||||
Reference in New Issue
Block a user