Hermes Bot
8.1 KiB
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
You’re 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 isn’t 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 CEO’s 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? That’s 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 — it’s 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 mas’ala (question). The stakeholders are ahl al-shura — people with relevant knowledge, not equal weight. The Mujtahid’s question: What is the maqsad behind each stakeholder’s 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”). That’s 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 problem’s 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: CEO’s strategic hunch, engineer’s “I think this is easier,” user’s stated preference (which may differ from behavior).
The Mujtahid uses tarjih (preponderance) rules:
- Who holds the burden of proof? The stakeholder advocating a change must bring daleel. If they say “competitor does it,” that’s zanni — insufficient.
- 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).
- Sad al-Dhara’i (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.
- Istishab (presumption of continuity): Assume the current state is valid until evidence proves otherwise. Don’t 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 don’t 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 advisor’s dignity is sacred.
How to consult as a Mujtahid PM:
- 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?”
- Weight by expertise, not hierarchy. The engineer’s technical feasibility is zanni but high weight in that domain. The CEO’s strategic vision is zanni but high weight in market context. The user’s pain is zanni but weight increases with frequency.
- Use the Shura Quadrant to identify gaps. If only Business speaks, ask: “Where is the user’s voice?” Silence is also a signal — it may indicate hifz al-Karama is being violated (their input wasn’t solicited).
- 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.