Files
digital-mujtahid-v2/chapters/Principle_03.md
T
2026-08-16 06:08:04 +08:00

11 KiB
Raw Blame History


Principle #3: Stakeholder Consultation — Shura as Discovery

Maqasid: Hifz al-Karama (Preservation of Dignity) → Stakeholder Voice
Framework: Shura Quadrant — Users / Team / Business / Regulators


1. THE SCENARIO

Youre the Product Lead at a growing fintech startup. Your CEO walks into your desk, coffee in hand, and asks: “Why are we building this feature? And whose voice are we listening to?” You open your notebook. The Mujtahid in you asks: “What is the hukm of consulting stakeholders? What is the maqsad behind their input? And what happens when their voices conflict — whose daleel carries weight?” The CEO isnt waiting for theory. She wants a decision by end of week. You need a framework that turns consultation into discovery, not performative noise.


2. DISCOVERY (ISTIQSA)

PRODUCT_LEAD:
Continuous Discovery starts with a clear Opportunity Solution Tree. Your CEOs question is a gift — it forces you to map the problem space. Who are your stakeholders? Users, engineers, compliance, finance, the CEO herself. Each sits in a different branch of the tree. Your job is not to collect opinions but to uncover the underlying jobs to be done for each stakeholder.

  • Users: What outcome do they want from this feature? (e.g., faster checkout, lower fees)
  • Team (engineers, design): What technical or process constraints do they see? (e.g., legacy API, sprint capacity)
  • Business (CEO, finance): What metric moves? (e.g., conversion rate, LTV)
  • Regulators (legal, compliance): What risk must be mitigated? (e.g., KYC, data privacy)

Run a Shura Quadrant mapping exercise this week. Draw four boxes. Populate them with the primary job each stakeholder is trying to get done through you. Then ask: Which box is empty? Thats where discovery is needed.

MUJTAHID:
In Usul al-Fiqh, Istiqsa (comprehensive investigation) is the systematic search for all relevant evidence before issuing a ruling. Shura is not a brainstorming session — its a method of evidence gathering. The Prophet ﷺ consulted his Companions on matters where revelation was silent, not to poll feelings but to surface valid maqasid (purposes) and masalih (benefits).

Your fintech feature request is a masala (question). The stakeholders are ahl al-shura — people with relevant knowledge, not equal weight. The Mujtahids question: What is the maqsad behind each stakeholders voice? Is it Hifz al-Mal (preservation of wealth)? Hifz al-Nafs (safety)? Hifz al-Aql (sound judgment)?

  • Users: Their voice protects Hifz al-Mal (fair pricing, no exploitation) and Hifz al-Karama (they are not just data points).
  • Team: Their voice protects Hifz al-Aql (technical soundness, avoid harm from rushed code).
  • Business: Their voice protects Hifz al-Mal (sustainability, growth) but can become gharar (uncertainty) if over-prioritized.
  • Regulators: Their voice protects Hifz al-Din (contractual validity, riba avoidance) and Hifz al-Nafs (fraud prevention).

The maqsad of Shura is not consensus — it is istiqsa of masalih and mafasid. You must discover whose input is dareuri (essential) vs hajiyyat (needed) vs tahsiniyyat (nice-to-have). The empty quadrant is a mafsada waiting to happen.


3. EVIDENCE (ISTIDLAL)

PRODUCT_LEAD:
Evidence comes in two flavors: quantitative (metrics, A/B tests, analytics) and qualitative (interviews, observation, support tickets). Your CEO wants a decision — but the feature request is likely based on a single data point (e.g., “our competitor has it”). Thats zanni (speculative) evidence at best.

Build your evidence stack:

  • Quantitative: Funnel drop-off rates, feature usage heatmaps, survey NPS segmented by stakeholder group. What does the data say about the problems prevalence?
  • Qualitative: 5 user interviews this week, 2 stakeholder shadow sessions (e.g., sit with compliance during a manual review). What story does the data not tell?

When stakeholders conflict (e.g., users want speed, compliance wants more checks), weight evidence by frequency, severity, and reversibility. A 2% conversion loss from adding a step is zanni until you validate it with a cheap experiment. A regulatory fine of $10M is qati (definitive) — it must be addressed first.

MUJTAHID:
Daleel in Usul is ranked: Qati al-Thubut wa Qati al-Dalala (definitive source and meaning) vs Zanni in either. In Shura, stakeholder input is rarely qati. It is zanni evidence that must be weighed.

  • Qati evidence: Explicit regulatory requirements, binding contracts, clear user harm (e.g., bug causes financial loss). These override everything.
  • Zanni evidence: CEOs strategic hunch, engineers “I think this is easier,” users stated preference (which may differ from behavior).

The Mujtahid uses tarjih (preponderance) rules:

  1. Who holds the burden of proof? The stakeholder advocating a change must bring daleel. If they say “competitor does it,” thats zanni — insufficient.
  2. What is the maqsad? If the feature protects Hifz al-Din (e.g., ensuring riba-free transactions), it takes precedence over Hifz al-Mal (revenue).
  3. Sad al-Dharai (blocking the means to harm):* If a feature opens a path to mafsada (e.g., easier fraud), it is avoided even if users request it.
  4. Istishab (presumption of continuity): Assume the current state is valid until evidence proves otherwise. Dont build a feature just because someone asked — the default is no change.

Use a simple Tarjih Matrix: For each stakeholder input, assign a score (1-3) for Qati/Zanni, Maqsad weight (Daruri=3, Hajji=2, Tahsini=1), and Mafsada risk (high=3, medium=2, low=1). The highest total wins — but only if the maqsad is preserved.


4. SHURA

PRODUCT_LEAD:
Shura is not a meeting. It is a structured discovery ritual. You dont just “ask stakeholders what they want” — you build a Shura Cadence:

  • Weekly 30-min sync with each quadrant (Users, Team, Business, Regulators). Use a consistent format: “What problem are we solving? What evidence do you have? What outcome do you need?”
  • Monthly Shura Council — one hour, all four quadrants present. Each presents their top opportunity (backed by evidence). The goal is not to vote but to surface trade-offs.
  • Record dissent explicitly. When a stakeholder disagrees, write their dissent and the daleel they offered. This is tadwin al-shura — documenting consultation. It protects Hifz al-Karama: their voice was heard, weighted, and preserved.

MUJTAHID:
The Mujtahid consults by tamyiz (discernment), not democracy. The Prophet ﷺ consulted Badr strategy with the Companions, but the final decision was his. Shura is advisory, not binding — but the advisors dignity is sacred.

How to consult as a Mujtahid PM:

  1. Start with the maqsad. Open the Shura by stating: “We are here to protect $MAQSAD for $STAKEHOLDER. What evidence do you have that $FEATURE serves or harms this?”
  2. Weight by expertise, not hierarchy. The engineers technical feasibility is zanni but high weight in that domain. The CEOs strategic vision is zanni but high weight in market context. The users pain is zanni but weight increases with frequency.
  3. Use the Shura Quadrant to identify gaps. If only Business speaks, ask: “Where is the users voice?” Silence is also a signal — it may indicate hifz al-Karama is being violated (their input wasnt solicited).
  4. End with a ruling, not a poll. After gathering all input, you (the Product Lead / Mujtahid) issue a hukm: “We will proceed with $DECISION, based on $DALEEL, with $SHURUT (conditions), and $MUNKATHIRAT (rollback triggers).” Record the reasoning. This is tadwin al-ijtihad.

Shura is the discovery engine. When done right, it transforms stakeholder consultation from a political chore into a rigorous, dignity-preserving investigation of what is khayr (good) for the product and its people.

End of Part 1. Principle, Protocol, and Retrospective continue in Part 2.## THE PRINCIPLE (HUKM)

HUKM: We will build a recurring, structured Shura Council for every major product decision, with rotating representation from Users, Team, Business, and Regulators, and we will publish a summary of input and outcomes.

DALEEL: Discovery interviews across 12 stakeholder interviews revealed that 8 felt their voice was either ignored or collected too late. Quantitative survey (n=50) showed 74% of stakeholders would increase trust with a formal consultation process. Maqasid analysis confirms that Hifz al-Karama (dignity) is violated when stakeholders are informed after decisions are locked. Qiyas: the Prophet ﷺ consulted even in minor matters (Khandaq, changing strategy based on Salman al-Farsis input). The daleel is strong: recurring Shura preserves dignity AND improves decision quality.

MAQSAD: Hifz al-Karama the preservation of stakeholder dignity through genuine voice, which is a necessary condition for trust, alignment, and sustained collaboration. Secondary Maqasid: Hifz al-Mal (business outcomes improve when blind spots are surfaced early).

SHURUT:

  • The Shura Council must include at least one representative from each quadrant (Users, Team, Business, Regulators) per decision.
  • A written “Shura Brief” (problem statement, constraints, options) must be distributed 48 hours before the session.
  • The Product Manager must explain how each piece of input was used or why it was not used, and publish this in a public log.
  • Rollback trigger: If any quadrant misses two consecutive sessions, the decision is paused until they are represented.

MUNKATHIRAT:

  • When stakeholder input is never referenced in the final decision document (nullifies dignity).
  • When sessions become monologues from the product team (no genuine listening).
  • When the same individuals dominate every session without rotation (entrenchment, not shura).

THE PROTOCOL

STEP 1: This sprint, identify the next major product decision (e.g., feature prioritization, pricing change, or sunsetting a module). Draft a one-page Shura Brief with the problem, three options, and one clear question: “What would you do if you were me?” Share it with at least one person from each quadrant by Wednesday.

STEP 2: Hold a 45-minute Shura session on Thursday. Start with the brief, then each quadrant speaks uninterrupted for 5 minutes. Take verbatim notes. End with: “I will share my decision and how your input shaped it by Monday.”

STEP 3: By Monday, publish the decision log in a visible place (Slack, wiki, or product board). Include: what we decided, which inputs changed our thinking, which inputs we deprioritized and why. Then schedule the next Shura session two weeks out.


MUHASABA (RETROSPECTIVE)

When did you last change a product decision because a stakeholder disagreed with you? If you cant remember, your Shura is performative. Dignity is not about being heard—its about being able to change the outcome. The real test of Hifz al-Karama is whether your product roadmap has scars from stakeholder voice.