Hermes Bot
128 lines
16 KiB
Markdown
128 lines
16 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’## THE FATWA (HUKM)
|
||
|
||
**HUKM:** We will institutionalise a mandatory Shura process for all product decisions above a defined threshold (impacting >10% of users or >$50k revenue), requiring documented consultation from all four quadrants (Users, Team, Business, Regulators) before any fatwa is issued, with a clear escalation mechanism for unresolved conflicts.
|
||
|
||
**DALEEL:** PRODUCT_LEAD: “Continuous discovery teaches us that decisions made in isolation fail to capture the full opportunity space. Our user interviews revealed three features that were deprioritised because the team assumed they were low-value, but when we finally asked, users rated them as critical. That’s a dignity failure — we assumed their voice without giving them a seat.” MUJTAHID: “Usul al-fiqh requires istiqsa’ (comprehensive investigation) before ruling. The Shura quadrant is a tool for istiqsa’ of stakeholder reality. Daleel from the Quran (Surah Al-Shura 42:38) commands consultation in affairs. The sunnah of the Prophet ﷺ in the Battle of Uhud shows that even when the leader held a strong opinion, he honoured the Shura outcome. Here, our quantitative data showed that 70% of product failures in the last quarter were attributable to a single quadrant being ignored — usually Regulators or Team. That is a pattern of injustice (zulm) that must be remedied.”
|
||
|
||
**MAQSAD:** Hifz al-Karama (Preservation of Dignity) — the primary maqsad. Every stakeholder is created with inherent worth; their perspective is a trust (amanah) that must be heard and weighed. Without structured Shura, we reduce people to data points. Secondary maqsad: Hifz al-Mal — avoiding rework that costs 3x initial development; Hifz al-Aql — incorporating diverse reasoning to prevent groupthink; Hifz al-Nasl — building a culture where future product teams inherit a tradition of consultation, not dictatorship.
|
||
|
||
**SHURUT:**
|
||
- **Threshold clarity:** The Shura process is mandatory for any decision on the product roadmap that affects a critical metric (e.g., North Star, OKR) or requires >2 sprints of engineering effort. Lower-impact decisions can use a lightweight version (15-min async poll).
|
||
- **Quadrant weighting:** Each quadrant’s voice is weighted by relevance to the decision, not by seniority. A junior engineer’s technical constraint may outweigh a VP’s preference. Weighting is documented before the session and shared openly.
|
||
- **Time-bound:** Shura sessions must conclude within 5 working days for standard decisions, 48 hours for time-sensitive ones. If no consensus, the facilitator (typically the PM) issues a fatwa with a documented rationale based on maslaha (public benefit) and istihsan (juristic preference), explicitly stating which quadrant’s input was overridden and why.
|
||
- **Transparency:** The fatwa must be published to all participants within 24 hours of the session, including a summary of how each quadrant’s input shaped the decision. If a quadrant’s input was set aside, the rationale must cite a specific qa’idah fiqhiyyah (e.g., “al-darar yuzal” — harm must be removed — if overriding a user request to prevent a broader harm).
|
||
|
||
**MUNKATHIRAT:**
|
||
- If any quadrant’s documented input is ignored without a written istihsan or maslaha justification in the fatwa, the decision is void and must be reconvened within one sprint.
|
||
- If the Shura process is bypassed for a decision that meets the threshold (e.g., due to “urgency” that turns out to be false), the fatwa is nullified, and the responsible PM must present a tawbah (corrective action) plan to the team.
|
||
- If new daleel emerges within two sprints that contradicts a key assumption used in the Shura, the fatwa is suspended and a mini-Shura (30-min session with the same quadrants) is called to reassess.
|
||
|
||
## THE PROTOCOL
|
||
|
||
STEP 1: **Map your NEXT product decision to the Shura Quadrant.** Within 48 hours, open a simple document (Google Doc or Notion) with four sections: Users / Team / Business / Regulators. For each quadrant, list the specific person or data source you will consult. If you cannot name at least one voice per quadrant, that is a red flag — escalate to your product lead. Example: Decision to add a new payment feature — Users: interview 3 power users; Team: lead engineer and designer; Business: CFO and sales director; Regulators: compliance officer and Shariah advisor (if fintech). Deadline: end of third day.
|
||
|
||
STEP 2: **Run a 60-minute Shura session using the structured agenda.** Invite all identified stakeholders. Agenda: (a) Context setting — the problem and opportunity (5 min), (b) Each quadrant presents their input in turn, uninterrupted (4 min each = 16 min), (c) Facilitated discussion — highlight trade-offs, identify conflicting daleel (20 min), (d) Decision or escalation — if consensus, document fatwa; if not, assign a decision-maker to issue a fatwa with rationale within 24 hours (19 min). Use a timer. Record all input on a shared board.
|
||
|
||
STEP 3: **Issue the fatwa and define Munkathirat.** Within 24 hours of the session, publish the fatwa using the five-part format (Hukm, Daleel, Maqsad, Shurut, Munkathirat). Include a one-paragraph summary of how each quadrant’s input was considered. Then, add a calendar entry for one sprint later to review the Munkathirat triggers. Example trigger: “If user adoption of the new payment feature drops below 20% in two weeks, the decision is null and we |