Hermes Bot
8.7 KiB
FATWA #1: THE PROBLEM STATEMENT — WHAT PROBLEM ARE WE SOLVING?
Maqsad: Hifz al-Aql (Preservation of Mind/Clarity) → Jobs-to-be-Done
1. THE SCENARIO
You’re the Product Lead at a growing fintech startup. Your CEO bursts into your weekly sync: “Why are we building this feature? The board wants to know. The team is spinning. Just give me a PRD by Friday.” You open your notebook. The Mujtahid in you asks: “What is the hukm? What is the maqsad?” The Product Lead in you asks: “What problem are we actually solving? Is this a symptom or a root cause? User pain or business pain? Known or unknown?” You have three days to produce a problem statement that passes both the user test and the Maqasid test. The clock is ticking.
2. DISCOVERY (ISTIQSA‘)
PRODUCT_LEAD:
“Before you write a single line of a PRD, you must discover the real problem. I use the Problem Quadrant. Draw a 2x2.
- X-axis: Symptom ↔ Root Cause
- Y-axis: User Pain ↔ Business Pain
Place your CEO’s feature request somewhere in that quadrant. Most requests land in ‘Symptom + Business Pain’ — urgent but shallow. Your job is to push it toward ‘Root Cause + User Pain.’ That’s where durable solutions live.
Start with Continuous Discovery. This week, do three things:
- Map the Opportunity Solution Tree — Write the desired outcome at the top (e.g., ‘Increase user activation in first 7 days’). Below it, list opportunities (user needs, pains, desires). Don’t jump to solutions yet.
- Conduct 3–5 user interviews using Jobs-to-be-Done language: “When you first signed up, what job were you hiring our app to do? What made you switch from your old tool?”
- Trace the symptom chain — Keep asking “Why?” five times until you hit a root cause. If the CEO says “Users aren’t completing onboarding,” ask: “Why? Because they get stuck on step 3. Why? Because the KYC form asks for too much data. Why? Because we copied a bank’s template. Why? Because we never tested with real users.” Now you have a root cause.
MUJTAHID:
“I call this Istiqsa‘ — exhaustive investigation of the problem space. In Usul al-Fiqh, before issuing a fatwa, a mujtahid must first define the wāqi‘ (reality). He does not rule on a vague question. He asks: What is the precise nature of this case? What are its borders? What maslaha (benefit) or mafsada (harm) is at stake?
Apply the Maqasid lens to your problem. The Maqsad here is Hifz al-Aql — preservation of mind and clarity. This means:
- The user’s mind must not be burdened with confusion, unnecessary steps, or deceptive flows.
- The product’s logic must align with the user’s mental model.
- The problem statement itself must be clear and unambiguous — no vague language like “improve engagement.”
Ask: What is the hukm of this feature? Is it obligatory (wajib) to solve this problem? Recommended (mandub)? Permissible (mubah)? Or is it merely a desire of the CEO? A problem that harms the user’s mental clarity (e.g., dark patterns) is haram to build. A problem that enhances clarity is a priority.
Also, distinguish symptom from root cause using the maqasid hierarchy:
- Symptom = surface disruption (e.g., low completion rate).
- Root cause = deep misalignment with user’s innate needs (fitrah). The user’s fitrah seeks clarity, efficiency, and trust. If your KYC form violates that, the root cause is a design that does not respect Hifz al-Aql.
Your discovery is incomplete until you can state the problem in one crisp sentence that answers: What job is the user trying to do, and what prevents them from doing it with clarity?”
3. EVIDENCE (ISTIDLAL)
PRODUCT_LEAD:
“Now gather daleel — evidence. In product, we have two types: quantitative (metrics, analytics, logs) and qualitative (interviews, observation, support tickets). Both are necessary. But they are not equal in weight. Here’s how I prioritize:
- Quantitative daleel — Look at your funnel. Where is the drop-off? What’s the baseline? If 70% of users abandon onboarding at step 3, that’s a strong signal. But numbers alone don’t tell you why.
- Qualitative daleel — User interviews, session recordings, support chats. Listen for the JTBD language: “I just wanted to send money quickly. I didn’t expect to fill out my entire life story.”
- Triangulate — If the data says ‘low completion’ and interviews say ‘too much friction,’ you have convergent evidence. If they conflict, dig deeper.
Avoid anecdote as daleel. One CEO’s hunch is not data. One user complaint is not a trend. Require at least three independent sources before calling something a root cause. Use the Opportunity Solution Tree: attach evidence to each opportunity node. If an opportunity has no evidence, prune it.
MUJTAHID:
“In Usul al-Fiqh, evidence is graded. We have:
- Qaṭ‘ī al-thubūt wa qaṭ‘ī al-dalāla (definitive transmission and definitive meaning) — e.g., a clear verse from Qur’an. In product, this is like a log that proves 100% of users hit an error. Very rare but powerful.
- Ẓannī al-thubūt wa ẓannī al-dalāla (probable in both) — most product data falls here. It’s probable, not certain. You must treat it as a hypothesis, not a fact.
- Istishāb (presumption of continuity) — assume the current state remains until proven otherwise. If you don’t have evidence that users hate the KYC form, presume they accept it. The burden of proof is on the one claiming change.
Your evidence must be maqṣūd (relevant) and kāfī (sufficient). One user interview is not sufficient — that’s like one witness in a court. You need multiple witnesses (users) whose testimony converges.
Ask: Is this evidence ‘ānim (general) or khāṣṣ (specific)? A general metric like ‘NPS dropped’ is too broad. Specific evidence like ‘85% of users who abandon onboarding do so at the document upload step’ is actionable.
Finally, distinguish between ‘illa (effective cause) and sabab (mere occasion). The sabab is the trigger (e.g., user clicks ‘Cancel’). The ‘illa is the underlying reason (e.g., form asks for photo ID but user doesn’t have one handy). The ‘illa is what you must address. That is the root cause.”
4. SHURA
PRODUCT_LEAD:
“Shura — consultation — is not a rubber stamp. It’s a structured process to surface blind spots. Call a cross-functional sync with engineering, design, data, and customer support. But don’t just ask “What do you think?” Use a stakeholder map:
- Who owns the outcome? (PM, execs)
- Who owns the output? (engineers, designers)
- Who has context? (support, sales)
- Who is affected? (users, compliance)
For each stakeholder, ask: “What evidence do you have that this problem exists? What evidence refutes it?” Record dissent explicitly. If the engineer says “This problem is not real, users just need better education,” write it down. That hypothesis can be tested.
Then conduct user shura: run a small co-creation session with 3–5 users. Show them the draft problem statement: “We believe users abandon onboarding because the KYC form is too long. Does that match your experience?” Let them correct you. Their voice is the strongest daleel.
MUJTAHID:
“Shura in Islam is not majority vote. It is a method to reach the best ijtihād. The Prophet ﷺ consulted his companions even when he knew the answer — to train them and to surface hidden wisdom.
Your shura must have ādāb (etiquettes):
- Ikhlāṣ (sincerity) — consult to find the truth, not to confirm your bias.
- Inṣāf (fairness) — give each stakeholder’s evidence its due weight. The support rep who hears complaints daily has ẓannī evidence that may outweigh the CEO’s hunch.
- Tadwīn (recording) — document every opinion, especially dissenting ones. This is your majlis al-shura record.
Weight the input using marātib al-ijtihād:
- A stakeholder with direct user contact (support, UX researcher) → higher weight for qualitative evidence.
- A stakeholder with system-level data (data scientist) → higher weight for quantitative evidence.
- A stakeholder with strategic vision (CEO) → weight only after user evidence is clear.
If there is ikhtilāf (disagreement), do not suppress it. Mark it as a riwāya (variant opinion) and test it in the next discovery cycle. The goal is not unanimity — it is clarity.”
End of Part 1. Continue with Fatwa, Protocol, and Muhasaba in the next section.