Hermes Bot
62 lines
8.3 KiB
Markdown
62 lines
8.3 KiB
Markdown
# 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:
|
||
1. **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.
|
||
2. **Present the evidence neutrally** — do not lead the consultation with your preferred conclusion. The Mujtahid states the facts, the opportunities, the risks.
|
||
3. **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.
|
||
4. **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.* |