Hermes Bot
12 KiB
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:
- At least one behavioral source (analytics or usability test)
- At least one qualitative source (interview or observation)
- 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:
- Present the Opportunity Solution Tree — not the solution.
- Ask each stakeholder: "What evidence do you have that this opportunity is real?"
- Record all evidence in the four-quadrant grid.
- Weight by proximity to the user (engineers who never talk to users get lower weight).
- 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.