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

chapters/Fatwa_05.md

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