Hermes Bot
40 lines
4.2 KiB
Markdown
40 lines
4.2 KiB
Markdown
## 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. |