Files
2026-08-06 11:31:13 +08:00

4.4 KiB
Raw Permalink Blame History

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 shari) 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 mujtahids 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 (prewritten). After two weeks, if all metrics pass, the fatwa becomes mutamad (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 didnt set them tightly enough. Next time, ask: Which of our four quadrant metrics would actually hurt if we missed it? Thats the one that preserves our maqsad.