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

2026-08-06 11:31:13 +08:00
commit 2ac024163b
31 changed files with 3638 additions and 0 deletions
@@ -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.