PRINCIPLE #2: EVIDENCE GATHERING — Continuous Discovery as Istiqsa'

MAQSAD: Hifz al-Mal (Preservation of Wealth/Data) FRAMEWORK: Evidence Quadrant – Quantitative / Qualitative / Behavioral / Attitudinal

1. THE SCENARIO

You're the Product Lead at a fast-growing fintech startup. Your CEO bursts into your weekly sync: "Why are we building this feature? Show me the evidence." You open your notebook. The Mujtahid in you asks: What is the hukm? What is the maqsad? The Product Lead in you asks: What did we discover? What opportunity are we solving? The CEO isn't asking for a roadmap slide. She's asking for the daleel. And if you can't produce it, you're building on sand. This is a Hifz al-Mal moment — preserving the company's wealth (time, engineering hours, user trust) from waste. The Habit of Continuous Discovery is your shield.

2. DISCOVERY (ISTIQSA')

PRODUCT_LEAD:
Continuous Discovery is not a meeting. It's a weekly cadence of talking to users, mapping opportunities, and testing assumptions before writing a single line of code. You start with the Opportunity Solution Tree. Draw the trunk: the desired outcome (e.g., "Increase monthly active savings accounts by 20%"). Then branch into opportunities: "Users don't trust automated savings rules", "Onboarding takes too long", "No clear feedback loop after deposits". Each opportunity is a hypothesis. Then branch into solutions: "Add manual override for auto-save rules", "Streamline KYC with biometrics", "Push notification after each deposit". But before you pick a solution, you must gather evidence. The habit is: every week, talk to 2–3 users about the opportunity space. No sales pitch. Just JTBD interviews: "What job were you trying to get done when you set up your savings rule?" Discovery is a habit, not a phase. You do it continuously because the problem space shifts like sand.

MUJTAHID:
Istiqsa' (إستقصاء) in Usul al-Fiqh means thorough investigation — leaving no stone unturned before issuing a hukm. A Mujtahid does not rule on a matter until she has exhausted the sources: Qur'an, Sunnah, Ijma', Qiyas, and then the subsidiary proofs (Istihsan, Maslaha, etc.). She does not leap from a single hadith to a fatwa. She asks: Is this daleel qati' (definitive) or zanni (probable)? Is the chain authentic? Does it conflict with a stronger daleel? This is exactly the rigor of Continuous Discovery. The product decision is your hukm (ruling). The maqsad is Hifz al-Mal — preserving the company's wealth and the user's wealth (data, time, money) from waste. Istiqsa' means you do not build a feature based on a single user request or a CEO's gut feeling. You investigate: What is the real problem? Who faces it? Under what conditions? What have we learned from past features? The Mujtahid's question at this stage: What constitutes 'sufficient evidence' for this product decision? The answer depends on the risk. High-risk decisions (e.g., changing the core transaction flow) require qati' evidence — multiple data sources, triangulated user interviews, A/B test results. Low-risk decisions (e.g., button color) can be zanni — a heuristic or a single test. But the habit of Istiqsa' demands you know the difference.

3. EVIDENCE (ISTIDLAL)

PRODUCT_LEAD:
Evidence comes in four flavors — the Evidence Quadrant:

Quantitative (what: metrics, dashboards, funnels)
Qualitative (why: interviews, diary studies, usability tests)
Behavioral (what users actually do: logs, clickstream, feature adoption)
Attitudinal (what users say: surveys, NPS, feedback forms)

You need all four to triangulate. A high drop-off in onboarding (quantitative) tells you where people leave. Interviews (qualitative) tell you why — maybe they're confused by the savings rules. Behavioral data (logs) shows that 70% of users who attempt to set a rule abandon after step 3. Attitudinal data (survey) reveals 60% find the rule builder "too complex." Now you have evidence. But the habit is: you don't wait for a perfect dataset. You gather minimum viable evidence — just enough to reduce uncertainty to a level where you can make a decision. If the risk is low, a single interview with a clear pattern may suffice. If the risk is high (e.g., launching a new payment rail), you need a full investigation: user research, competitive analysis, prototype testing, and a staged rollout.

MUJTAHID:
In Istidlal (استدلال), we classify evidence by strength. The hierarchy:

Qati' al-Thubut wa Qati' al-Dalala — Definitive in transmission and meaning (like a mutawatir hadith). In product: a clear, replicable A/B test with statistical significance, or a consistent pattern across 20+ user interviews.
Qati' al-Thubut wa Zanni al-Dalala — Definitive transmission but ambiguous meaning. Example: a metric that is reliable but could be interpreted multiple ways (e.g., "time on page" could mean engagement or confusion).
Zanni al-Thubut wa Qati' al-Dalala — Probable transmission but clear meaning. Example: a single user interview where the user's words are unambiguous, but you need more data to confirm it's not an outlier.
Zanni al-Thubut wa Zanni al-Dalala — Both weak. Example: a gut feeling from the CEO, or a survey with a biased sample.

Your job as product Mujtahid is to weigh the evidence and assign a confidence level. The maqsad of Hifz al-Mal means you protect resources from being wasted on low-confidence decisions. You do not build a feature based on zanni evidence alone — unless the cost of delay is higher than the cost of a mistake (Maslaha principle). Signal vs. noise: a single spike in support tickets about a bug is signal. A low NPS score with no qualitative context is noise. You must filter noise by triangulating across quadrants. The minimum viable evidence for a principle (a product decision with high impact) is at least two independent sources from different quadrants, with no contradictory evidence. For an MVP experiment, one strong qualitative signal plus a behavioral data point is sufficient.

4. SHURA

PRODUCT_LEAD:
Discovery is not a solo sport. You need input from stakeholders: engineering (feasibility), design (usability), data science (metrics), customer support (pain points), and legal (compliance). But Shura is not voting. It's consultation with weight. You present your evidence — the Opportunity Solution Tree, the user quotes, the data — and ask: What am I missing? What assumptions are we making? What risks do you see? You record dissent explicitly. If an engineer says "This will break our caching layer," that's a shart (condition) you must address before the hukm. If a designer says "Users will find this confusing," that's a potential munkathir (nullifier) — if proven, the decision must reverse. Shura is not a rubber stamp. It's a pressure test of your evidence.

MUJTAHID:
Shura (مشاورة) is an obligation for the Mujtahid when the evidence is not definitive. The Prophet ﷺ consulted his companions even when the revelation was clear, to teach the method. The methodology:

Identify the right stakeholders — those with relevant expertise (not just hierarchy). The engineer who built the legacy code, the customer support agent who hears complaints daily, the finance analyst who knows the unit economics.
Present the evidence neutrally — do not lead the consultation with your preferred conclusion. The Mujtahid states the facts, the opportunities, the risks.
Weigh the input — not all voices are equal. The person closest to the user's pain may have more weight than the VP who hasn't spoken to a customer in a year. Weight by relevance, not rank.
Record dissenting opinions — if a respected stakeholder disagrees, note it in your product decision log. That dissent becomes a munkathir (nullifier) if later evidence proves it correct. It also protects you from groupthink.

A Muslim PM should see Shura as a sunnah that protects Hifz al-Mal — the collective wisdom of the team prevents costly mistakes. The output of Shura is not consensus; it's a refined set of shurut (conditions) and munkathirat (nullifiers) that you will carry into the principle.

End of Part 1. Continue to Part 2: The Principle (Hukm), The Protocol, and The Retrospective.## THE PRINCIPLE (HUKM)

HUKM: We will institutionalise a weekly Continuous Discovery habit that systematically collects evidence across all four quadrants of the Evidence Quadrant (Quantitative, Qualitative, Behavioral, Attitudinal) before committing any engineering resources to a new feature or experiment.

DALEEL: Analysis of our last three sprints shows 67% of shipped features failed to move the North Star metric because decisions were based on attitudinal data alone (customer “I want X” interviews) without behavioral validation. The Evidence Quadrant framework, when applied rigorously, reduces waste (Hifz al-Mal) by grounding decisions in triangulated signals. Our own A/B test history confirms that features validated with ≥3 quadrants have a 4× higher success rate.

MAQSAD: Primary: Hifz al-Mal (Preservation of Wealth/Data) – avoiding wasteful engineering spend and protecting the integrity of our data pipeline. Secondary: Hifz al-Aql (Preservation of Intellect) – ensuring decisions are made with sound reasoning, not guesswork.

SHURUT:

Evidence must be refreshed within the last 14 days before any sprint commitment.
At least two quadrants must agree before a decision is taken to build.
Behavioral data (actual user interaction logs) takes precedence over attitudinal data (stated preferences) in case of conflict.
The Evidence Quadrant board must be visible to the entire team and updated weekly.

MUNKATHIRAT:

Skipping the weekly evidence review without a documented emergency.
Making a build decision based on a single quadrant (e.g., only quantitative metrics or only a CEO’s opinion).
Ignoring disconfirming evidence that emerges after a decision is made – the principle is invalidated if the team refuses to revisit the evidence.

THE PROTOCOL

STEP 1: Every Monday morning, block 90 minutes for the Continuous Discovery huddle. The PM brings three pieces of evidence: one quantitative (e.g., funnel conversion), one qualitative (e.g., user interview quote), and one behavioral (e.g., session recording clip). No slide decks – just raw evidence on the Evidence Quadrant board.

STEP 2: For any feature being considered for the next sprint, the team must map it to at least two quadrants within that same week. If only one quadrant has evidence, the feature is deferred to the next cycle. Use the Opportunity Solution Tree to trace the evidence back to a specific opportunity.

STEP 3: Every Friday, run a 30-minute “Evidence Audit” where the team asks: “What did we learn this week that disconfirms our current assumptions?” If any Munkathirat condition is triggered, the build is paused and the Hukm is re-evaluated before Monday.

MUHASABA (RETROSPECTIVE)

Where in our last sprint did we ship something based on a single quadrant, and what would it have cost us if we had been wrong – both in wasted engineering hours (Hifz al-Mal) and in misleading data that now pollutes our model (Hifz al-Aql)?

11 KiB Raw Blame History Unescape Escape