Hermes Bot
3.6 KiB
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.