Hermes Bot
110 lines
12 KiB
Markdown
110 lines
12 KiB
Markdown
**Fatwa #4: The Product Decision — The Fatwa as Definition of Done**
|
||
*Maqsad: Hifz al-Din (Preservation of Purpose)*
|
||
|
||
---
|
||
|
||
### 1. THE SCENARIO
|
||
|
||
You’re the Product Lead at a growing fintech startup. The CEO calls you into her office. “We’ve been sprinting for six weeks on the new auto-invest feature,” she says. “The engineers say it’s ‘done’ — tests pass, UI looks clean. But I’m not sure it solves the problem. Why are we building this again?”
|
||
|
||
You open your notebook. The Mujtahid in you asks: *What is the hukm? What is the maqsad?* The Product Lead in you asks: *What does “done” really mean?* You realize: you don’t have a Definition of Done that connects to purpose. You have a checklist, not a fatwa.
|
||
|
||
---
|
||
|
||
### 2. DISCOVERY (ISTIQSA’)
|
||
|
||
**PRODUCT_LEAD:**
|
||
Let’s run Continuous Discovery. Open your Opportunity Solution Tree. On the left, write the *outcome*: “Increase monthly active investors by 20%.” That’s your North Star for this quarter. Now trace backward: What are the opportunities? User interviews last week showed a JTBD: “I want to invest without thinking about it.” That’s the job. The opportunity is *reducing cognitive overhead*. But your team jumped straight to a solution: auto-invest with a fixed percentage. Did you explore *why* users avoid manual investing? Did you test the assumption that auto-invest is the best way to remove friction? Discovery isn’t done until you’ve mapped at least three alternative solutions and validated the opportunity with real behavior, not just stated preferences.
|
||
|
||
**MUJTAHID:**
|
||
Istiqsa’ — comprehensive investigation of the problem space. In usul al-fiqh, we don’t issue a fatwa until we fully comprehend the *maqsad* (purpose) and the *waqi’* (reality). Here, the maqsad is Hifz al-Din — preserving the purpose of the product. What is the purpose of your fintech app? Not just to move money, but to help users steward their wealth responsibly (Hifz al-Mal). If you lose that purpose, you’ve built a gambling machine, not a savings tool. So first question: *What is the hukm asl (default ruling) of an auto-invest feature?* It’s mubah — permissible — but only if it doesn’t lead to harm (gharar, riba, negligence). You must explore the *shurut* (conditions) that make it valid. Is the user giving informed consent? Is the investment halal? Does the feature encourage mindless risk? Istiqsa’ means mapping these conditions before you decide.
|
||
|
||
**Merged insight:**
|
||
Both mentors agree: Discovery is not about listing features. It’s about defining the problem space so thoroughly that the decision boundary becomes clear. Use a Decision Quadrant:
|
||
- **Reversible vs Irreversible** (Type 1 vs Type 2 decisions)
|
||
- **High Stakes vs Low Stakes**
|
||
- **Data-Rich vs Data-Poor**
|
||
|
||
Auto-invest is *reversible* (you can roll back), *moderately high stakes* (users’ money), and *data-poor* (no actual usage yet). That means you need a lightweight fatwa — a conditional go with strong monitoring. But you must still anchor to maqsad: *Does this feature preserve the user’s ability to act intentionally?* If it removes all intention, it may violate Hifz al-Din (purposeful action).
|
||
|
||
---
|
||
|
||
### 3. EVIDENCE (ISTIDLAL)
|
||
|
||
**PRODUCT_LEAD:**
|
||
Gather daleel — evidence. Two types: quantitative and qualitative.
|
||
- *Quantitative*: You run a smoke test. Put a “Set & Forget” button on the dashboard. Track click-through rate. 12% click — high intent. But then you run an A/B test on onboarding: users who see a “What’s your risk tolerance?” question before auto-invest vs. those who see a default allocation. The default group has 40% higher signup but 60% higher opt-out within 30 days. That’s a Zanni (speculative) signal: convenience may cause regret.
|
||
- *Qualitative*: User interviews with 8 people. One says: “I set it and forgot it, but now I don’t know where my money is. I feel uneasy.” That’s a Qati al-Dalala (clear indication) of a problem: the feature undermines *awareness*.
|
||
|
||
Evidence hierarchy:
|
||
- Qati (certain) = user behavior showing harm (e.g., high regret rate).
|
||
- Zanni (probable) = survey scores, A/B significance.
|
||
- Wahn (weak) = gut feel from execs.
|
||
|
||
**MUJTAHID:**
|
||
In istidlal, we weigh evidence by strength and relevance. The Prophet ﷺ said, “The burden of proof is on the claimant” (al-Bayhaqi). Here, the claimant is the team arguing the feature is “done.” They claim it solves the user’s job. But the evidence shows a *mafsada* (harm): reduced user agency. This triggers Sad al-Dhara’i — blocking the means to harm. The auto-invest feature, without a periodic check-in, becomes a *dhari’ah* (pathway) to heedlessness (ghaflah). That violates Hifz al-Din — the preservation of purposeful action.
|
||
|
||
Your evidence threshold depends on the decision type:
|
||
- **Reversible decision** (easy rollback): Zanni evidence is enough. Ship it, measure, iterate.
|
||
- **Irreversible decision** (changes data model, hard to undo): Need Qati evidence or strong Zanni with multiple witnesses (tawatur of user feedback).
|
||
|
||
This decision is reversible — you can turn off auto-invest. So Zanni evidence suffices. But the maqsad requires you to *add a condition*: the user must confirm their risk profile every 90 days. That condition is a *shart* derived from the evidence of harm.
|
||
|
||
---
|
||
|
||
### 4. SHURA
|
||
|
||
**PRODUCT_LEAD:**
|
||
Call a shura — a consultation meeting. Invite: the engineer (feasibility), the designer (usability), the compliance officer (risk), and two users (via video call). Don’t ask “Should we ship?” Ask: “What would need to be true for this feature to actually help users invest intentionally?” The engineer says rollback takes one sprint. The designer says adding a quarterly check-in adds 2 days of work. The compliance officer warns that auto-invest without periodic consent may violate regulations in 3 markets. The users say: “I’d feel better if the app nudges me to review every few months.”
|
||
|
||
Record all dissenting opinions. In shura, the majority does not automatically bind — the *rajih* (preponderant) view is based on strength of evidence and alignment with maqsad. The compliance officer’s concern is Qati (regulatory text), so it overrides the engineer’s convenience.
|
||
|
||
**MUJTAHID:**
|
||
Shura is sunnah, but it has rules. The Prophet ﷺ consulted his companions even when revelation was available — not because he needed their opinion, but to train them and to uncover blind spots. Here, you must weight each opinion by *adalah* (trustworthiness) and *khibrah* (expertise). The user’s voice carries weight because he is the *mustafti* (seeker of the ruling). His testimony is *shahadah* (witness) of the real problem. The engineer’s opinion on cost is *ra’y* (reasoned opinion), not evidence.
|
||
|
||
Dissent is recorded. If the compliance officer objects, note it. If you override, explain why: *maslaha* (public benefit) of shipping quickly to test learning outweighs the low-probability regulatory risk, *provided* you add the shart of quarterly review. The shura ends with a clear list of *shurut* (conditions) and *munkathirat* (nullifiers) that will trigger rollback.
|
||
|
||
---
|
||
|
||
*End of Part 1. Part 2 continues with the Fatwa, Protocol, and Muhasaba.*## THE FATWA (HUKM)
|
||
|
||
**HUKM:** We will ship a **private personal progress tracker** (no public leaderboard) with optional one-to-one sharing to a trusted accountability partner, and we will **not build** any social comparison features (rankings, scores, global streaks) until we have direct evidence that such features enhance the user’s core *niyyah* (intention) rather than distract from it.
|
||
|
||
**DALEEL:**
|
||
- User research (n=12) and a prototype test (n=60) showed that public leaderboards increased logins by 40% but decreased reported *khushu’* (mindfulness) scores by 25%.
|
||
- The *maqsad* of the product is *Hifz al-Din* (preservation of purpose) – helping users deepen their spiritual practice. Social comparison features introduce *riya’* (showing off), which is *haram* in intent and likely to corrupt the core JTBD ("I want to build consistent spiritual habits without ego getting in the way").
|
||
- The decision quadrant shows this is **high stakes** (spiritual harm) and **irreversible** once public leaderboard data creates network effects; switching back would break user trust. We are **data-poor** on long-term spiritual outcomes, so the principle of *Sad al-Dhara’i’* (blocking the means to harm) applies.
|
||
|
||
**MAQSAD:** Hifz al-Din – preserving the product’s purpose as a tool for *ibadah* (worship) and *tazkiyah* (self-purification), not as a gamified distraction. Secondary: Hifz al-Nafs (protecting the user from spiritual harm) and Hifz al-Aql (protecting mental clarity from competitive anxiety).
|
||
|
||
**SHURUT (Conditions / Acceptance Criteria):**
|
||
- The private tracker must show **absolute personal progress** (e.g., “You completed 12 out of 15 daily *adhkar* this week”) with no relative comparison to others.
|
||
- Optional sharing must be **opt-in, one-to-one, and reversible** – user can disconnect at any time without losing data.
|
||
- Success metric: Improvement in self-reported *niyyah* clarity score (survey at week 2 and week 6) must be ≥ +0.5 on a 5-point scale, and drop-off rate due to “feeling pressured” must be < 5%.
|
||
- Rollout: Feature-flag with 10% of users; if the *niyyah* score drops or complaints of *riya’* emerge, we roll back within 48 hours.
|
||
|
||
**MUNKATHIRAT (Nullifiers / Rollback Triggers):**
|
||
- Any user-reported incident of *riya’* (e.g., “I feel like I’m competing with my friend instead of focusing on Allah”) – immediate rollback and re-design.
|
||
- A/B test shows that the private tracker reduces daily active usage by more than 20% compared to control (without tracker) – indicates we’ve added friction without purpose preservation.
|
||
- Qualitative feedback from ≥2 users in the first week indicates that the feature is being used as a *trophy case* rather than a *reflection tool* – roll back and revisit JTBD.
|
||
|
||
---
|
||
|
||
## THE PROTOCOL (3 Steps – This Sprint)
|
||
|
||
**STEP 1: Build the private tracker MVP**
|
||
Design a single-screen dashboard showing the user’s own 7-day streak of the three core habits (e.g., Fajr on time, daily Quran page, evening adhkar). No badges, no points, no leaderboard. Use a simple green checkmark system. Ship behind feature flag to 10% of active users. *(Time: 3 days)*
|
||
|
||
**STEP 2: Collect *niyyah* data**
|
||
Add an in-app micro-survey after 2 days of use: “On a scale of 1–5, how much does this tracker help you focus on your intention (niyyah) for worship?” Also track feature usage (clicks, time spent). *(Time: 5 days continuous)*
|
||
|
||
**STEP 3: Review and decide on expansion**
|
||
If the *niyyah* score is ≥4.0 and no *riya’* incidents are reported, expand to 50% of users and begin designing a “close accountability partner” sharing feature (one-to-one, non‑competitive). If score <3.5, roll back the feature and schedule a new discovery sprint to understand what users actually need. *(Time: end of sprint)*
|
||
|
||
---
|
||
|
||
## MUHASABA (RETROSPECTIVE)
|
||
|
||
**What did we learn about our own willingness to sacrifice user engagement metrics for preserving spiritual purpose, and where did we feel the strongest temptation to compromise because of board pressure or growth targets?**
|
||
|
||
The most uncomfortable insight was that our team hesitated to kill the leaderboard idea because it promised easy retention numbers. The *Fatwa* forced us to ask: “Are we building for Allah’s pleasure or for our vanity as product builders?” The next sprint, we will pre‑commit to a *Shura* check before any feature with social elements enters development. |