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

This commit is contained in:
Hermes Bot
2026-08-06 11:31:13 +08:00
commit 2ac024163b
31 changed files with 3638 additions and 0 deletions
+104
View File
@@ -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.