Auto-sync Thu Aug 6 11:31:13 +08 2026

chapters/Fatwa_02.md

@@ -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.