Hermes Bot
12 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.## THE FATWA (HUKM)
HUKM: We will frame the problem as “Customers abandon the checkout flow because they cannot predict the total cost before entering payment details” — and we will not build a “guest checkout” or “one-click purchase” until we validate that this root cause is solved.
DALEEL: Continuous discovery interviews (n=23) showed 78% of drop‑offs occur on the payment screen after unexpected fees appear; quantitative funnel analysis confirms a 34% exit rate at that step. This is a zanni (probable) but actionable signal—the pain is real (Hifz al‑Mal: loss of money through surprise fees; Hifz al‑Aql: cognitive load of uncertainty). The maqsad of clarity (al‑Aql) is violated by hidden costs, creating a “job” of predicting total cost before committing.
MAQSAD: Hifz al‑Aql (preservation of clarity and sound decision‑making) — the user’s mind is burdened by ambiguity. The JTBD is: “Help me know the exact price before I decide to pay.” Serving this maqsad also indirectly protects Hifz al‑Mal (avoiding financial regret) and Hifz al‑Nasl (trust in the transaction for future use).
SHURUT:
- Condition 1: The solution must surface the all‑inclusive total (tax, shipping, discounts) before the user enters any payment information.
- Condition 2: Feature must ship with an A/B test measuring checkout completion rate (North Star: +15% relative improvement within 2 weeks).
- Condition 3: Rollout initially to 10% of traffic; if confidence interval for detriment exceeds 5%, pause and revert.
- Condition 4: Legal must approve fee‑transparency wording to avoid false claims (Hifz al‑Din: honesty in business).
MUNKATHIRAT (Nullifiers):
- If after 2 weeks the checkout completion rate does not improve by at least 5% (statistically significant), the fatwa is revoked and we return to discovery.
- If user interviews reveal the real job is speed, not clarity (e.g., they want one‑click checkout even with surprise fees), then this problem statement is invalid and we pivot.
- If engineering cost exceeds 4 sprints, the fatwa is nullified because the maslaha does not outweigh the delay to other work.
THE PROTOCOL
STEP 1: Prototype the “total cost preview” on the cart page.
This sprint: design a single‑screen mockup that shows the final price with a breakdown (subtotal + tax + shipping). Test with 5 users via moderated interviews. Deadline: End of Week 1.
STEP 2: Validate the JTBD with a concierge MVP.
For 2 days, manually message every user who reaches the payment screen with a pop‑up: “Your total will be $X. Continue?” Measure how many complete vs. abandon. Deadline: Week 2, Days 1–2.
STEP 3: Decide to build or kill.
Based on Step 2 data (if >70% of users who see the total proceed), write the engineering ticket for the full feature. If not, return to discovery and reframe the problem. Deadline: Week 2, End of Day 5.
MUHASABA (RETROSPECTIVE)
What would we have missed if we had jumped straight to building “guest checkout” without first isolating the real cost‑clarity job?
This question forces the team to confront the most common product fallacy: mistaking a symptom (low conversion) for a root cause (unexpected fees). If we had shipped guest checkout, we might have seen a small bump from reduced friction—but the core trust issue would remain, and churn would resurface. The muhasaba must ask: Did we truly distinguish the user’s “job” from our own assumptions? If the answer is “no,” then next time we need to spend more time in the Problem Quadrant before writing a single line of code.