Hermes Bot
8.3 KiB
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.