# 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.