Hermes Bot
13 KiB
PRINCIPLE #1: THE PROBLEM STATEMENT — What Problem Are We Solving?
1. THE SCENARIO
You’re the Product Lead at a fintech startup that just closed Series A. Monthly active users are growing, but retention is flat. Your CEO bursts into your weekly sync: “Our users aren’t saving enough. Let’s build an auto-round-up feature—every purchase, round up to the nearest dollar and stash the difference. It’s what Monzo and Acorns do. Ship it by end of quarter.”
You open your notebook. The spreadsheet of user interview notes stares back at you. The Mujtahid in you whispers: Before you write a single line of a PRD, ask: What is the hukm (ruling) on this decision? What is the maqsad (purpose) we are truly serving? The Product Lead in you adds: Is this a symptom or a root cause? Is this user pain or business pain? And most importantly—which job are we actually being hired to do?
2. DISCOVERY (ISTIQSA’)
PRODUCT_LEAD:
Stop. Don’t touch a wireframe. We’re not building anything until we understand the problem space. I pull out the Opportunity Solution Tree framework. I ask the team: What outcome do we want? “Increase savings rate” is not an outcome—it’s an output. The real outcome? Users feel financially secure enough to focus on other parts of life. That smells like Hifz al-Mal (preservation of wealth) and Hifz al-Aql (preservation of mind/clarity).
I draw the tree. Root node: Improve financial well-being. First-level opportunities: (1) Users don’t know where their money goes. (2) Users lack the discipline to save. (3) Users feel anxious about unexpected expenses. The CEO’s feature—auto-round-up—maps to opportunity #2. But is #2 the root? I schedule 10 user interviews this week. No solution talk. Just JTBD: When you think about saving money, what’s the job you’re trying to get done? The answer might be: “I want to stop feeling guilty about spending on coffee.” That’s an emotional job, not a functional one.
MUJTAHID:
Before a fatwa, I conduct Istiqsa’—exhaustive investigation of the problem space. The Prophet ﷺ said: “The judge must not judge between two people while he is angry.” Anger clouds reasoning. Likewise, the CEO’s excitement for a popular feature is a form of hawa (desire). I ask: What is the maqsad al-shar’i (higher objective) of this product? It is not merely to make users save—it is to protect their aql (mind) from the anxiety of financial insecurity, which is a daruriyyah (essential need) under Hifz al-Aql.
I then map the problem using Maqasid lenses:
- Is this a daruriyyah (essential), hajiyyah (needed), or tahsiniyyah (embellishment)?
- If users don’t save, do they lose their mental clarity (aql)? Or do they just miss an opportunity for optimization?
The CEO’s feature assumes the problem is lack of a mechanism. But Istiqsa’ demands we test that assumption. I ask: What evidence do we have that users actually want to save? If the problem is lack of knowledge (opportunity #1), then auto-round-up is a sad al-dhara’i (blocking the means) that blocks spending—but it may also block the maslaha (benefit) of conscious budgeting. I record all assumptions as zanni (speculative) until proven.
Key question from Istiqsa’: How do we distinguish a symptom from a root cause? A symptom is the surface complaint—“I can’t save.” A root cause is the underlying mafsada (harm) or maslaha gap—e.g., “I have no visibility into my spending pattern, so I feel out of control.” The Mujtahid asks: What is the ‘illah (effective cause) behind the user’s behavior? Is it ignorance, lack of tools, or emotional friction? The Product Lead asks: What is the JTBD that the user is hiring our product to do? Both converge on the same truth: the problem statement must describe the job, not the solution.
3. EVIDENCE (ISTIDLAL)
PRODUCT_LEAD:
Now we gather daleel. Two buckets: Quantitative and Qualitative.
Quantitative: I pull analytics. Our users who attempt to set a savings goal drop off at 70% mid-funnel. That’s a signal. But is it qati (certain)? No—it’s zanni (speculative) because the drop-off could be due to UI confusion, not lack of desire. I need cohort analysis: do users who complete setup actually save more? If yes, then the bottleneck is completion, not desire.
Qualitative: I conduct 10 user interviews. One user says: “I tried rounding up for two weeks, but I felt like I was being punished for buying groceries. I stopped.” That’s a symptom—the feature itself created a negative emotional job (punishment). Another user says: “I want to save automatically, but I also want to know exactly how much I’m saving every month.” That reveals a missing job: transparency.
I map these onto the Opportunity Solution Tree. The evidence points to opportunity #1 (lack of visibility) being more fundamental than #2 (lack of discipline). I update my hypothesis: The job is not “make me save” but “show me my financial reality so I can make confident decisions.”
MUJTAHID:
Evidence in Usul al-Fiqh is categorized by strength:
- Qati al-Thubut (certain transmission): data that is indisputable—e.g., server logs showing drop-off rates.
- Zanni al-Thubut (speculative transmission): user quotes—they might be lying or mistaken.
- Qati al-Dalala (certain meaning): the interpretation is obvious—e.g., “I stopped because I felt punished” clearly indicates emotional pain.
- Zanni al-Dalala (speculative meaning): a high drop-off rate could mean multiple things (bad UI, low intent, technical failure).
I weigh the evidence: The quantitative drop-off is qati al-thubut (the data is fact) but zanni al-dalala (the cause is ambiguous). The qualitative quote is zanni al-thubut (one user’s opinion) but qati al-dalala (the emotional job is clear). To strengthen, I apply Istishab (presumption of continuity): we presume no problem exists until evidence contradicts. Here, the drop-off contradicts the assumption that users want auto-save. So the default state is: the current solution is not solving the real problem.
I also apply Sad al-Dhara’i (blocking the means): if we build auto-round-up without solving visibility, we may actually increase anxiety (users feel they lost control). That harms Hifz al-Aql. The evidence does not support moving forward.
Key lesson from evidence: Distinguish anecdote from data. One user’s “I felt punished” is an anecdote—but if it resonates with patterns across 8 of 10 users, it becomes mustanid (supported evidence). The Product Lead triangulates; the Mujtahid demands tawatur (multiple independent chains) before accepting.
4. SHURA (Consultation)
PRODUCT_LEAD:
I call a cross-functional sync: Engineering, Design, Data, and the CEO. I share the Opportunity Solution Tree and the evidence. I start with the user quotes—let them feel the pain. Then I ask: What do we think the root cause is?
The CEO says: “But auto-round-up works for everyone else.” That’s an appeal to popularity (istihsan bi al-‘adah). I counter: “We need to solve our users’ job, not copy features.”
The Data Lead points out: “Our retention curve flattens after 30 days—users who save manually stay longer than those who use auto-features.” That’s qati al-thubut evidence.
Design says: “What if we build a dashboard first? Show spending breakdown before any saving feature.”
I record all input. I don’t dismiss the CEO—I note his concern as a maslaha (speed to market). But I weight it lower because it contradicts user evidence. I then ask: Who else should we consult? We need to talk to users who churned. I schedule 5 more interviews.
MUJTAHID:
Shura is not a vote. It is a method of ijtihad jama’i (collective reasoning). The Prophet ﷺ consulted the companions even when he knew the answer—to build ownership and gather insights.
I establish adab al-shura (etiquette of consultation):
- No rank-based weighting. The CEO’s opinion gets the same initial weight as the intern’s. True evidence trumps authority.
- Record dissent explicitly. If Engineering says “this is technically hard to roll back,” that becomes a shart (condition) for the decision.
- Seek those with khibra (expertise). The Data Lead’s analysis is stronger than a generalist’s intuition. I assign a weight of 3x to domain experts.
The key mas’ala (issue) is: Is the problem we’re solving the right one? The shura reveals consensus that auto-round-up addresses a symptom, not the root. But we need one more round: consult the ahl al-khibra## THE PRINCIPLE (HUKM)
HUKM: We will not build any solution — not a single line of code, not a prototype, not an A/B test — until we have a validated problem statement that passes the Maqasid Problem Filter and is framed as a Jobs-to-be-Done.
DALEEL:
Quantitative data from our analytics shows a 40% drop in daily active users within the first week of new feature launches — not because the features were broken, but because they solved problems nobody had. Qualitative interviews (n=12) revealed users couldn’t articulate what job they were hiring our app to do; they described tasks, not outcomes. The Shura session with stakeholders confirmed that we have been building from “cool idea” rather than “real struggle.” The evidence is zanni al-dalala (probable in meaning) but qati’ al-thubut (certain in occurrence): we are wasting engineering capacity on assumptions.
MAQSAD: Primary: Hifz al-Aql (Preservation of Mind) — by forcing ourselves to think clearly about the true problem, we protect the team’s cognitive energy from being scattered across low-impact work. Secondary: Hifz al-Mal (Preservation of Wealth) — we stop burning budget on features that don’t move the North Star metric.
SHURUT (Conditions that must be met before the principle is considered fulfilled):
- The problem statement must include a JTBD functional job (e.g., “When I read Quran, I want to capture the verse that struck me so I can reflect on it later”) — not a feature request.
- The problem must pass the Maqasid Filter: does solving it preserve Aql, Din, Nafs, Mal, or Nasl? If none, deprioritize.
- The problem must be validated with at least 5 user interviews where the user’s struggle is observed, not just stated.
- The problem must have a measurable outcome (e.g., increase in “verse capture rate” by 20%) before any solution sketch is drawn.
MUNKATHIRAT (Nullifiers — conditions that invalidate this principle):
- If a stakeholder (including the CEO) bypasses the problem statement and says “just build this feature,” the principle is nullified — we must immediately call a Shura to re-establish discipline.
- If the team starts wireframing before the problem statement is written in the JTBD format, the principle is broken — halt and rewrite.
- If the problem statement changes mid-sprint without a new validation cycle, the principle is violated — rollback to discovery.
THE PROTOCOL
STEP 1: Write the JTBD Problem Card (by Tuesday)
Take the feature request your team is most excited about. Write it on a physical index card. Flip it over. On the back, answer: What job is the user trying to get done? What is the struggle? What progress are they trying to make? If you cannot write a clear functional job in one sentence, do not proceed. This is your “istidlal al-mas’ala” (inference of the problem).
STEP 2: Run the Maqasid Filter (Wednesday)
Bring the problem card to a 30-minute standup with the product triad (PM, designer, lead engineer). For each Maqsad (Din, Nafs, Aql, Mal, Nasl), ask: If we solve this problem, which Maqsad do we serve? How? Give one concrete example. If the problem serves zero Maqasid, kill it. If it serves one but with negative externalities (e.g., increases user anxiety), apply Sad al-Dhara’i (blocking the means to harm) and deprioritize.
STEP 3: Validate with 5 Struggles, Not 5 Opinions (by end of Sprint)
Conduct 5 user interviews. Do not ask “Would you use X?” Ask: Tell me about the last time you tried to do [the job]. What made it hard? What did you do instead? Record each struggle as a quote. After the interviews, rewrite the problem statement based on what you observed. If the statement changes, you have validated the real problem. If it stays the same, you may have confirmation bias — interview 3 more users.
MUHASABA (RETROSPECTIVE)
What would our product look like if we deleted every feature that was built without a validated problem statement?
Take that list. Burn it in your mind. Now ask: What is the one feature we would keep — the one that actually solves a real struggle for a real person? That is your North Star. Everything else is decoration. Start there next sprint.