Hermes Bot
148 lines
12 KiB
Markdown
148 lines
12 KiB
Markdown
# FATWA #2: Evidence Gathering — Continuous Discovery as Istiqsa'
|
||
|
||
**Maqsad:** Hifz al-Mal (Preservation of Wealth/Data) → Continuous Discovery Habits
|
||
|
||
---
|
||
|
||
## 1. THE SCENARIO
|
||
|
||
You're the Product Lead at a growing Islamic fintech startup. Your CEO walks into your desk and asks: "Why are we building this *waqf*-linked investment feature? I need one sentence."
|
||
|
||
You open your notebook. There's a blank page where your evidence should be. The Mujtahid inside you whispers: *What is the hukm? What is the maqsad? What is the daleel?* You have user stories, but no user evidence. You have OKRs, but no outcome data. You realize: you're building on assumptions, not discovery.
|
||
|
||
The CEO waits. You have two weeks before the next board meeting. You need a Decision Protocol — but first, you need **Istiqsa'**: thorough investigation.
|
||
|
||
---
|
||
|
||
## 2. DISCOVERY (ISTIQSA')
|
||
|
||
**PRODUCT_LEAD:**
|
||
Continuous Discovery is not a meeting. It's a habit. Every week, you talk to users. Every sprint, you map an Opportunity Solution Tree. You don't start with the feature — you start with the **opportunity**: the JTBD your users are trying to accomplish.
|
||
|
||
Draw a tree. The root is the **outcome** (e.g., "More users complete their first waqf investment"). The branches are **opportunities** (e.g., "Users don't trust the platform," "Users don't understand the Islamic contract," "Users need help choosing a waqf category"). Under each opportunity, list **solutions** (features, experiments). Under each solution, list **assumptions** — the hypotheses you need to test.
|
||
|
||
Your job is not to build the solution. Your job is to **validate the opportunity** first. Talk to six users this week. Ask: "Tell me about the last time you tried to make a waqf investment. What happened?" Listen for pain, fear, confusion. Map their story onto the tree.
|
||
|
||
**MUJTAHID:**
|
||
In Usul al-Fiqh, *Istiqsa'* is exhaustive investigation to uncover the **hukm** (ruling) of a situation. A Mujtahid does not issue a fatwa until he has gathered sufficient evidence from the Qur'an, Sunnah, Ijma', and Qiyas. But what is "sufficient"? It depends on the **maqsad** (objective).
|
||
|
||
Here, the maqsad is **Hifz al-Mal** — preserving wealth. For a fintech product, wealth is both capital and **data**. Every assumption you hold is a liability. If you build a feature on false evidence, you waste user trust and company money. That is *israf* (waste) — prohibited in Islam (Qur'an 7:31).
|
||
|
||
Istiqsa' in product means you must investigate **four domains**: the user's context, the user's behavior, the user's stated needs, and the user's unstated fears. You cannot rely on one source. The Sahaba (RA) would travel weeks to verify a single hadith. Can you spend six user interviews to verify a feature?
|
||
|
||
**Apply Maqasid:**
|
||
- **Hifz al-Din** (Faith): Does the feature align with Shariah?
|
||
- **Hifz al-Nafs** (Life): Does it protect users from harm (e.g., risky investments)?
|
||
- **Hifz al-Aql** (Intellect): Is the contract clear? Does the user understand?
|
||
- **Hifz al-Mal** (Wealth): Does this feature preserve or waste user wealth?
|
||
- **Hifz al-Nasl** (Lineage): Does it support long-term family financial stability?
|
||
|
||
Your discovery must cover all five. Continuous Discovery is Istiqsa' — systematic, thorough, and outcome-driven.
|
||
|
||
---
|
||
|
||
## 3. EVIDENCE (ISTIDLAL)
|
||
|
||
**PRODUCT_LEAD:**
|
||
Evidence comes in four flavors. Draw a 2×2 grid. Horizontal axis: **Quantitative** (numbers) vs **Qualitative** (stories). Vertical axis: **Behavioral** (what they do) vs **Attitudinal** (what they say). Four quadrants:
|
||
|
||
| | Quantitative | Qualitative |
|
||
|---|---|---|
|
||
| **Behavioral** | Analytics (conversion rates, drop-off) | Usability tests, session recordings |
|
||
| **Attitudinal** | Surveys (NPS, CSAT) | User interviews, focus groups |
|
||
|
||
Most teams live in the bottom-left: attitudinal-quantitative (surveys). But the strongest evidence comes from **behavioral data** — what people actually do, not what they say. A user tells you "I want a waqf investment feature" (attitudinal). But when you run an A/B test, only 3% click the CTA (behavioral). The behavioral evidence overrides the attitudinal.
|
||
|
||
**The Minimum Viable Evidence Rule:**
|
||
You don't need 500 survey responses for a fatwa-level decision. But you do need **triangulation** — at least two different evidence types pointing in the same direction. For an MVP, you need behavioral-qualitative evidence (e.g., 3 usability sessions showing the same confusion pattern) plus quantitative-behavioral (e.g., analytics showing 40% drop-off at the same step).
|
||
|
||
**MUJTAHID:**
|
||
In Usul, evidence (*daleel*) is classified by **certainty** (*qati'* vs *zanni*) and **source** (*thubut* vs *dalala*). A verse from the Qur'an is *qati' al-thubut* (certain transmission) but may be *zanni al-dalala* (ambiguous meaning). A weak hadith is *zanni al-thubut* but may be *qati' al-dalala* (clear meaning).
|
||
|
||
Apply this to product evidence:
|
||
|
||
| Product Evidence Type | Thubut (Reliability of Data) | Dalala (Clarity of Interpretation) |
|
||
|---|---|---|
|
||
| Analytics from your own tool | High (you control logging) | Varies (correlation ≠ causation) |
|
||
| User interview quotes | Low (small sample, bias) | High (direct quotes are clear) |
|
||
| A/B test result (p<0.05) | High (statistically significant) | Medium (depends on context) |
|
||
| Competitor analysis | Low (they may be wrong) | Low (their features ≠ your users' needs) |
|
||
|
||
**Signal vs Noise:**
|
||
A Mujtahid weighs evidence by *ta'adul wa tarjih* (balancing and preferring). If one user says "I love the feature" but analytics show 90% abandonment, the behavioral evidence outweighs. Similarly, if a hadith contradicts a stronger source, the stronger source prevails.
|
||
|
||
**Minimum Viable Evidence for a Product Fatwa:**
|
||
You need:
|
||
1. **At least one behavioral source** (analytics or usability test)
|
||
2. **At least one qualitative source** (interview or observation)
|
||
3. **Triangulation** — both sources point to the same opportunity or problem
|
||
|
||
If you only have attitudinal data (surveys, user "requests"), you have not yet performed Istiqsa'. You are building on *zann* (speculation), and the Prophet ﷺ warned against following conjecture (Qur'an 10:36).
|
||
|
||
---
|
||
|
||
## 4. SHURA
|
||
|
||
**PRODUCT_LEAD:**
|
||
Shura is not a committee that votes. It's a structured consultation with **stakeholders who have skin in the game**. Map your stakeholders: users, engineering, design, Shariah board, CEO, compliance. Each brings a different lens. Your job is to collect their input, but not to average it.
|
||
|
||
**The Shura Session Protocol:**
|
||
1. Present the **Opportunity Solution Tree** — not the solution.
|
||
2. Ask each stakeholder: "What evidence do you have that this opportunity is real?"
|
||
3. Record all evidence in the four-quadrant grid.
|
||
4. Weight by **proximity to the user** (engineers who never talk to users get lower weight).
|
||
5. Document dissent — especially from the Shariah board or compliance.
|
||
|
||
**MUJTAHID:**
|
||
Shura in Islam is not democracy; it is **seeking counsel from those with knowledge and experience**. The Prophet ﷺ consulted the Sahaba before Badr, even though he had revelation. Why? Because consultation uncovers blind spots and builds ownership.
|
||
|
||
A Mujtahid consults:
|
||
- **Ahl al-'ilm** (those with knowledge): Shariah scholars for fatwa, domain experts for product.
|
||
- **Ahl al-ra'y** (those with sound judgment): Senior engineers, experienced PMs.
|
||
- **Ahl al-khibra** (those with direct experience): Users, customer support.
|
||
|
||
**Weighting Input:**
|
||
- A Shariah board member's input on permissibility is *qati'* and cannot be overridden.
|
||
- A user's input on usability is *zanni* but highly relevant.
|
||
- A CEO's input on business strategy is *zanni* and must be balanced with user evidence.
|
||
|
||
**Recording Dissent:**
|
||
In classical fiqh, *mukhalif* (dissenting opinions) are recorded even if not adopted. Why? Because later evidence may shift the balance. In product, record every "no" and "why" — it becomes a risk register for rollback triggers.
|
||
|
||
**End of Shura:**
|
||
You now have a consolidated evidence map. You know what's known, unknown, and disputed. You are ready to issue a **Fatwa** — the product decision. That is our next chapter.## THE FATWA (HUKM)
|
||
|
||
**HUKM:** We will adopt a weekly, 90-minute Continuous Discovery habit using the Evidence Quadrant as our primary tool for all product decisions, with explicit guardrails to protect engineering resources and user trust.
|
||
|
||
**DALEEL:**
|
||
**PRODUCT_LEAD:** Our quantitative data shows 35% of features shipped last quarter had <20% adoption. Qualitative interviews reveal users feel “features are built for someone else.” Behavioral logs confirm low repeat usage. Attitudinal surveys show Net Promoter Score dropping 12 points in 6 months. This quadrant reveals a systemic failure to validate before building.
|
||
**MUJTAHID:** The daleel is mixed but sufficient to establish a hukm. The quantitative data is qat‘i al-thubut (certain in transmission) but zanni al-dalala (speculative in interpretation). Qualitative evidence is zanni but corroborated. Istidlal via qiyas: the Prophet ﷺ said, “The strong believer is better and more beloved to Allah than the weak believer” (Muslim). Strength here implies disciplined use of resources. Hifz al-Mal obligates us to spend development capital only on validated problems. The maslaha (public benefit) of a discovery habit is overwhelming.
|
||
|
||
**MAQSAD:** Hifz al-Mal (Preservation of Wealth) – we protect engineering hours, server costs, and data assets from waste. Also Hifz al-Aql (Intellect) – we avoid cognitive bias by forcing structured evidence review. Sub-maqsad: Hifz al-Din (Religion) – trustworthiness with stakeholder and user resources.
|
||
|
||
**SHURUT:**
|
||
- Each session must review evidence from all four quadrants. No session is valid if one quadrant is empty (e.g., “we have no behavioral data yet” triggers an action item, not a pass).
|
||
- At least one user must be interviewed or observed every two weeks. Recordings or notes become part of the evidence repository.
|
||
- The session must produce a written “Evidence Summary” (one page) that updates the Opportunity Solution Tree and is shared with the broader team.
|
||
- Rollback condition: If after 8 consecutive sessions we have zero changes to our product roadmap (i.e., no pivots or kills), we suspend the habit and audit whether the method is being applied correctly.
|
||
|
||
**MUNKATHIRAT:**
|
||
- Making a major product decision (feature go/no-go, resource allocation >1 sprint) without referencing the Evidence Quadrant.
|
||
- Cherry-picking evidence from only the quadrant that supports a pre-existing bias.
|
||
- Allowing “we already know this” to skip a session – the habit itself is the nullifier if broken three times without written justification.
|
||
|
||
## THE PROTOCOL
|
||
|
||
**STEP 1: This week – Build your quadrant board.**
|
||
Create a shared Miro or whiteboard with four labeled boxes: *Quantitative* (metrics, analytics), *Qualitative* (user interview quotes, verbatims), *Behavioral* (session recordings, heatmaps, funnel drop-offs), *Attitudinal* (surveys, NPS, satisfaction scores). Populate with every piece of evidence you currently have. Identify the emptiest quadrant – that is your first discovery task.
|
||
|
||
**STEP 2: This sprint – Run your first discovery session.**
|
||
Block 90 minutes on Tuesday. Invite PM, designer, lead engineer, and one rotating team member. Objective: Review each quadrant, list top 3 opportunities, and for each opportunity write a “What would have to be true?” statement. End with one decision: continue, pivot, or kill the current top feature candidate.
|
||
|
||
**STEP 3: Next 30 days – Build the habit and measure.**
|
||
After 4 sessions, conduct a mini-muhasaba: How many decisions changed because of evidence? What quadrant gave us the most leverage? If no decisions changed, escalate to the rollback condition. If decisions improved, codify the session as a team ritual.
|
||
|
||
## MUHASABA (RETROSPECTIVE)
|
||
|
||
**What evidence are we most afraid to collect, and what does that fear tell us about our willingness to protect our users’ and company’s wealth?**
|
||
The uncomfortable truth: we often avoid behavioral data because it might prove our assumptions wrong. Hifz al-Mal demands we seek that discomfort – because a wrong feature costs far more than a bruised ego. If you can’t name the evidence you’re avoiding, you haven’t truly done Istiqsa’. Go back to Discovery. |