Hermes Bot
103 lines
11 KiB
Markdown
103 lines
11 KiB
Markdown
### FATWA #3: Stakeholder Consultation — Shura as Discovery
|
||
|
||
**MAQSAD:** Hifz al-Karama (Preservation of Dignity) → Stakeholder Voice
|
||
**FRAMEWORK:** Shura Quadrant: Users / Team / Business / Regulators
|
||
|
||
---
|
||
|
||
## PART 1: SCENARIO → DISCOVERY → EVIDENCE → SHURA
|
||
|
||
---
|
||
|
||
### 1. THE SCENARIO
|
||
|
||
You’re the Product Lead at a growing fintech startup. Your CEO storms into your weekly sync: “Why are we building this feature? Who asked for it? I want a roadmap that *actually* reflects the business priorities.”
|
||
|
||
You open your notebook. The Mujtahid in you whispers: *What is the hukm of this consultation? What is the maqsad? Is this Shura or a performance?* You’ve done stakeholder interviews before. But they felt like checkboxes, not real discovery. The team built features that nobody used. The CEO’s voice dominated every product council. Users complained they were never heard. Regulators sent compliance warnings that caught you off guard. Something was broken. You need a methodology for consultation that is *valid* — not just polite listening but structured, evidence-weighted, dignity-preserving Shura.
|
||
|
||
---
|
||
|
||
### 2. DISCOVERY (ISTIQSA')
|
||
|
||
**PRODUCT_LEAD:** Let’s start with the real problem. The CEO’s question “Why are we building this?” is actually a symptom. The deeper problem: we have no systematic way to *discover* what stakeholders actually need. We’re jumping to solutions based on the loudest voice (usually the CEO or the highest-paying customer). That’s not discovery; that’s guessing.
|
||
|
||
I use the Opportunity Solution Tree. Draw it: On the left, your desired outcome (e.g., “Increase active user retention by 20%”). Then branch into *opportunities* — problems, pains, desires from users. Then branch into *solution ideas*. Then *experiments*. The key is that every branch comes from user evidence, not executive intuition.
|
||
|
||
In your fintech case, start with user interviews. Ask: “What’s the hardest part of managing your money right now?” Not “What feature do you want?” That’s JTBD: people hire your product to get a job done. The job might be “avoid late fees” or “save for Hajj without temptation.” Your CEO might think the job is “more analytics dashboards.” But the user’s job is different.
|
||
|
||
Map all stakeholder groups: Users (retail customers), Team (engineers, designers), Business (CEO, sales, finance), Regulators (Sharia board, central bank). Each has a different job. Each must be heard *in their own domain*. But you can’t give equal weight to all voices for every decision. That’s where the framework gets teeth.
|
||
|
||
**MUJTAHID:** In Usul al-Fiqh, *Istiqsa’* is exhaustive inquiry into the reality of the matter before issuing a hukm. It is not a casual survey. It is a systematic investigation of the *‘illah* (effective cause) and *maqsad* (purpose). Before you consult, you must define the domain of consultation.
|
||
|
||
Shura in the Islamic tradition is not just “asking for opinions.” It is a binding methodology for collective decision-making rooted in *Hifz al-Karama* — preserving the dignity of every stakeholder by giving them a voice that is actually heard and weighed. The Prophet ﷺ consulted his companions even when revelation existed. Why? Because Shura is a *right* of the community, not a courtesy.
|
||
|
||
But Shura has conditions (*shurut*):
|
||
1. The matter must be *mujtahad fih* — open to ijtihad, not fixed by explicit text.
|
||
2. The consultor must be trustworthy and seeking truth, not validation.
|
||
3. The consulted must be qualified (*ahl al-shura*) — knowledgeable in that domain.
|
||
4. The consultor is not bound to follow the majority opinion; but must give it due weight and explain departure.
|
||
|
||
So your discovery phase is actually *Istiqsa’*: you are gathering the *wāqi‘* (reality) of the problem space. Ask: What is the *maqsad* of this feature? Is it preserving *Mal* (wealth), *Aql* (mind), *Nafs* (life)? In fintech, most features impact *Mal* directly. But they also impact *Karama* — dignity of the user (e.g., not hiding fees, not patronizing language). The *maqsad* of stakeholder voice itself is *Karama*: every stakeholder is a human whose opinion has inherent value.
|
||
|
||
So your Istiqsa’ must map each stakeholder’s *maqsad* in the decision. Users want fairness and transparency. Team wants clarity and autonomy. Business wants growth and risk management. Regulators want compliance and public interest (*maslaha*). Each has a legitimate *maqsad*. The discovery question becomes: *Which maqasid are at stake in this decision?*
|
||
|
||
Draw a Maqasid Matrix: For each stakeholder group, list the primary maqsad (e.g., Users: Hifz al-Mal + Karama; Team: Hifz al-Aql (clarity) + Karama; Business: Hifz al-Mal; Regulators: Hifz al-Din + Hifz al-Mal al-‘Amm). Then rank by weight in this specific decision. That becomes your discovery lens.
|
||
|
||
---
|
||
|
||
### 3. EVIDENCE (ISTIDLAL)
|
||
|
||
**PRODUCT_LEAD:** Evidence gathering is two streams: quantitative and qualitative. Quantitative: metrics, analytics, conversion funnels, NPS, churn rates. Qualitative: user interviews, support tickets, session replays, stakeholder 1:1s.
|
||
|
||
But the trap is treating all evidence equally. A CEO’s strong opinion is not evidence. A single user complaint is not evidence. A regression test passing is not evidence of value.
|
||
|
||
Use the Evidence Hierarchy:
|
||
- **Level 1: Direct observation** (you watched a user struggle)
|
||
- **Level 2: Behavioral data** (analytics show 80% drop-off at step 3)
|
||
- **Level 3: Self-reported data** (user says “I want X” — weak)
|
||
- **Level 4: Expert opinion** (CEO says “the market needs Y” — weakest)
|
||
|
||
In your fintech case, you might have:
|
||
- Quantitative: 45% of users abandon onboarding after KYC step.
|
||
- Qualitative: Users say “I don’t trust giving my ID to an app.”
|
||
- CEO says: “We need to simplify KYC to one click.”
|
||
- Regulator says: “KYC must have three verification steps.”
|
||
|
||
Conflict. How do you weigh? You go back to the *outcome*: North Star Metric is “trusted transactions per user.” The evidence from users (distrust) and regulators (compliance) both point to the same root: lack of transparency in the KYC process. The CEO’s “one click” would violate regulatory shart. So you weigh regulatory evidence heavier in this domain (their *maqsad* is Hifz al-Mal al-‘Amm, public wealth, which overrides convenience).
|
||
|
||
**MUJTAHID:** Istidlal is the process of deriving evidence and weighing it. In Usul al-Fiqh, evidence has a hierarchy:
|
||
- **Qati‘ al-Thubut wa Qati‘ al-Dalala** (definitive source and definitive meaning) — e.g., a clear Qur’anic verse. In product: hard data that is beyond dispute (e.g., “server downtime is 99.9%”).
|
||
- **Qati‘ al-Thubut wa Zanni al-Dalala** (definitive source but ambiguous meaning) — e.g., a verse with multiple interpretations. In product: a metric that is reliable but its meaning is debated (e.g., “engagement time went up” — is that good or bad?).
|
||
- **Zanni al-Thubut wa Qati‘ al-Dalala** (probable source but clear meaning) — e.g., a strong hadith. In product: a well-conducted user interview with a clear signal.
|
||
- **Zanni al-Thubut wa Zanni al-Dalala** (both probable) — e.g., a weak hadith or an opinion. In product: a stakeholder’s gut feeling.
|
||
|
||
When stakeholders conflict, you must weigh their evidence by *thubut* (reliability) and *dalala* (clarity). A regulator’s written requirement is Qati‘ al-Thubut (it’s law) and often Qati‘ al-Dalala (clear rule). A user’s complaint is Zanni al-Thubut (maybe biased, maybe sample of one) but could be Qati‘ al-Dalala if the complaint is precise (“I can’t upload my ID because the file size limit is too small”). A CEO’s vision is usually Zanni al-Thubut (no data) and Zanni al-Dalala (vague).
|
||
|
||
So the weight of evidence is: **Regulator > User behavioral data > User self-report > CEO opinion**. But that’s not absolute — if the CEO’s opinion is based on deep market data (e.g., competitor analysis), it moves up in thubut.
|
||
|
||
The Mujtahid’s rule: *Al-thubut yuqaddam ‘ala al-dalala* (reliability of source is prioritized over clarity of meaning) when sources conflict. But you must also consider *maqsad*: the purpose of the rule. If the CEO’s idea serves Hifz al-Mal (profit) but violates Hifz al-Din (compliance), the latter outweighs because *Dar’u al-mafasid muqaddam ‘ala jalb al-masalih* (preventing harm takes precedence over bringing benefit). So you rank evidence by both source reliability and maqsad weight.
|
||
|
||
Practical step: For each stakeholder input, assign a score: Thubut (1-3: weak, medium, strong) and Dalala (1-3: vague, clear, precise). Multiply? Or use a weighted matrix. The key is to make the weighting explicit, not silent. Write it down. Share it with stakeholders as part of Shura transparency.
|
||
|
||
---
|
||
|
||
### 4. SHURA
|
||
|
||
**PRODUCT_LEAD:** Shura is not a meeting. It’s a process. In practice, I run structured consultation:
|
||
|
||
1. **Pre-work:** Send the Opportunity Solution Tree and the evidence matrix to stakeholders a week before. Ask them to review and add their own evidence.
|
||
2. **The Shura session:** 90 minutes, no slides. Start with the *maqsad*: “What outcome are we trying to achieve?” Then review the evidence for each opportunity. Then discuss solutions. But the rule: *each stakeholder speaks only in their domain of expertise*. The CEO does not override the engineer on technical feasibility. The user does not override the regulator on compliance. The PM synthesizes.
|
||
3. **Recording dissent:** If a stakeholder disagrees, it is recorded and given weight in the final decision. The Prophet ﷺ would record minority opinions and sometimes follow them later. This preserves Karama — even the dissenter’s dignity is honored.
|
||
|
||
In your fintech case, you might have: Users want simpler KYC. Regulator wants stricter KYC. Team says they can build a tiered KYC (low risk = simple, high risk = strict). The CEO wants a single flow. The Shura session reveals that the *maqsad* is Hifz al-Mal (prevent fraud) and Hifz al-Karama (don’t humiliate users with unnecessary hurdles). The tiered solution balances both. The CEO’s single flow is rejected because it fails the maqsad of *Karama* (low-risk users would be overburdened) and *Mal* (fraud risk). The dissent is recorded: CEO disagrees, but the evidence and maqsad analysis overrides.
|
||
|
||
**MUJTAHID:** Shura in Usul al-Fiqh is an obligation for matters that affect the community. The Qur’an says: *“And consult them in the matter”* (3:159). The *mushawir* (consultor) must be:
|
||
- *‘Adil* (just) — not favoring their own opinion.
|
||
- *Khabir* (expert) — knows the domain.
|
||
- *Amin* (trustworthy) — will not leak confidential information.
|
||
|
||
The *mushar* (consulted) must be:
|
||
- *Ahl al-ray* (qualified to give opinion).
|
||
- *Mukhlish* (sincere, not seeking personal gain).
|
||
|
||
How do you consult? You present the *mas’ala* (issue) and the *wāqi‘* (reality) as you have discovered it. You do not present your preferred solution first — that biases the response. Instead, you ask: “What do you see as the best path forward, given this evidence?” Then you listen. You take notes. You thank them for their input, even if you disagree. The *adab* (etiquette) of Shura requires that you never dismiss a stakeholder’ |