Hermes Bot
84 lines
9.3 KiB
Markdown
84 lines
9.3 KiB
Markdown
# PRINCIPLE #4: THE PRODUCT DECISION — THE PRINCIPLE AS DEFINITION OF DONE
|
||
|
||
**Maqsad:** Hifz al-Din (Preservation of Purpose)
|
||
**Framework:** Decision Quadrant — Reversible vs Irreversible / High Stakes vs Low Stakes / Data-Rich vs Data-Poor
|
||
**Core Insight:** The *hukm* itself is the Definition of Done. Not a checklist. Not a ship date. The principle.
|
||
|
||
---
|
||
|
||
## 1. THE SCENARIO
|
||
|
||
You’re the Product Lead at a growing fintech startup. Your CEO storms into your weekly sync. “We’re shipping the instant-payout feature next sprint. Marketing has already announced it. Engineering says two weeks. Go.”
|
||
|
||
You open your notebook. The Mujtahid in you asks: *What is the hukm? What is the maqsad?* The Product Lead in you asks: *Is this reversible? What’s the evidence?*
|
||
|
||
Your CEO expects a simple “yes.” But you know: a feature launched without a principled Definition of Done is a fatwa issued without daleel. It binds the team, the user, and the business — sometimes irreversibly.
|
||
|
||
---
|
||
|
||
## 2. DISCOVERY (ISTIQSA')
|
||
|
||
**PRODUCT_LEAD:** Let’s start with the problem. The CEO says “instant payouts.” That’s a solution, not a job. What’s the Job to Be Done? “I need my money now because my rent is due tomorrow and I can’t wait three business days.” That’s a JTBD: *Help me access my earned wages immediately when I face an urgent cash need.*
|
||
|
||
Draw an Opportunity Solution Tree. Root: “Users abandon our platform because payout speed is slower than competitors.” First branch: “Reduce payout delay.” Second branch: “Increase trust in timing.” Third branch: “Provide emergency liquidity.” The CEO jumped to a solution (instant payouts) without exploring the tree. We need to climb back up.
|
||
|
||
**MUJTAHID:** *Istiqsa’* means exhaustive investigation of the problem space. Before we issue a *hukm*, we must determine the *maqsad* — the intended purpose. What is the *maqsad* of this feature? *Hifz al-Mal* (preservation of wealth)? Yes — faster access to money. But also *Hifz al-Nafs* (preservation of life) — if a user can’t pay rent, that’s a threat to shelter and stability. And *Hifz al-Din* — the *din* of the product itself: its core purpose. What is the *din* of this fintech? “Help users manage their finances with dignity and speed.” Instant payouts preserves that purpose — if done right.
|
||
|
||
Now classify the decision type. Use the **Decision Quadrant**:
|
||
|
||
| | Reversible | Irreversible |
|
||
|---|---|---|
|
||
| **High Stakes** | Type 2 (reversible, high stakes) — e.g., a pricing experiment you can roll back | Type 1 (irreversible, high stakes) — e.g., changing the core payout architecture |
|
||
| **Low Stakes** | Type 4 (reversible, low stakes) — e.g., button color | Type 3 (irreversible, low stakes) — rare, but e.g., deleting old data |
|
||
|
||
Instant payouts is **Type 1** if it changes the underlying ledger system — irreversible because rolling back would break accounting records. It’s **Type 2** if it’s a front-end flow that can be toggled off. The CEO wants Type 2 speed but the engineering team suspects Type 1 complexity. We must discover which quadrant we’re in *before* we decide.
|
||
|
||
**PRODUCT_LEAD:** So discovery isn’t about “should we build instant payouts?” It’s about understanding the decision type. If it’s Type 1 (irreversible, high stakes), we need heavy evidence. If Type 2, we can experiment. The Definition of Done for discovery is: *We know which quadrant this decision lives in.*
|
||
|
||
**MUJTAHID:** Correct. In Usul al-Fiqh, the *hukm* changes based on the *shart* (condition). The *shart* here is reversibility. A reversible decision allows a *zanni* (speculative) ruling. An irreversible decision demands *qat’i* (certain) evidence. The *maqsad* (preservation of purpose) guides the threshold. If the feature threatens the product’s core *din* — e.g., by introducing fraud risk — then *sad al-dhara’i’* (blocking the means to harm) applies even before we have full evidence.
|
||
|
||
---
|
||
|
||
## 3. EVIDENCE (ISTIDLAL)
|
||
|
||
**PRODUCT_LEAD:** Now we gather daleel. Quantitative: What percentage of users request instant payouts? What is the current payout speed? What is the churn rate for users who wait 3 days? Data from analytics: 12% of users have complained about payout speed. 30% of those churn within 30 days. That’s a signal.
|
||
|
||
Qualitative: User interviews. “I needed the money for an emergency. I switched to a competitor that offered same-day.” That’s a JTBD insight. Also: “I’m worried about fees — if instant payouts cost me $5, I’d rather wait.” So the evidence is mixed — urgency exists, but price sensitivity is high.
|
||
|
||
**MUJTAHID:** In Usul, we classify evidence by *wurud* (source) and *dalala* (indication). Quantitative data (analytics) is *zanni al-thubut* (speculative in origin) — it depends on instrumentation accuracy. User interviews are *zanni al-dalala* (speculative in meaning) — one user’s story doesn’t prove the whole population. Both are *zanni*.
|
||
|
||
For a Type 2 (reversible) decision, *zanni* evidence suffices. But if this is Type 1 (irreversible, high stakes), we need *qat’i* evidence. What would be *qat’i*? A controlled experiment with statistical significance. Or a regulatory requirement (text of law is *qat’i al-thubut*). Or a clear *maslaha* (public benefit) that outweighs harm — but that’s a *ijtihad* judgment, not raw data.
|
||
|
||
Handle uncertainty: The Mujtahid applies *istishab* — presumption of continuity. The current state (3-day payout) is presumed valid until evidence proves otherwise. The burden of proof is on the change. So we ask: “Do we have enough evidence to shift from the default?” The Product Lead asks: “Is the evidence strong enough to justify the risk of reversal?”
|
||
|
||
**PRODUCT_LEAD:** That’s the same question. The evidence threshold depends on the quadrant. For a reversible experiment (Type 2), we need just enough evidence to justify the experiment — *zanni* is fine. For an irreversible architecture change (Type 1), we need *qat’i* evidence — multiple data sources, consistent user feedback, and a clear business case.
|
||
|
||
Current evidence: 12% complaint rate, 30% churn among complainers. That’s a strong *zanni* signal. But we don’t know if instant payouts will actually reduce churn — correlation ≠ causation. We need to test. So the evidence points to Type 2 decision: run a controlled experiment with a subset of users.
|
||
|
||
**MUJTAHID:** Agreed. The evidence does not reach *qat’i* for an irreversible change. Therefore, the *hukm* should be: proceed with a reversible experiment, with clear *shurut* (conditions) and *munkathirat* (nullifiers). The *maqsad* of *Hifz al-Din* (preserving the product’s purpose) requires that we do not harm the core experience. If the experiment introduces fraud, we must block it (*sad al-dhara’i’*). The Definition of Done for evidence gathering: *We have enough daleel to classify the decision quadrant and set the evidence threshold.*
|
||
|
||
---
|
||
|
||
## 4. SHURA
|
||
|
||
**PRODUCT_LEAD:** Time to consult. I schedule a 30-minute decision sync with the CEO, Engineering Lead, and Head of Risk. I bring the Opportunity Solution Tree and the Decision Quadrant. I present the evidence: “We’re in Type 2 territory — reversible, high stakes. Here’s the data. Here’s the user story. Here’s the risk of fraud. I recommend an experiment on 10% of users for two weeks.”
|
||
|
||
The CEO pushes back: “Marketing already announced. We can’t do a partial rollout.” The Engineering Lead says: “We can build a toggle, but the ledger change is one-way if we commit.” The Head of Risk says: “Fraud risk is high — we need to cap payouts at $200 per day.”
|
||
|
||
**MUJTAHID:** Shura is not a vote. It is a structured consultation where each voice is weighted by *khibra* (expertise) and *taqwa* (responsibility). The Mujtahid listens to all, but the final *hukm* is based on evidence and *maqsad*, not consensus.
|
||
|
||
Let’s weight:
|
||
- CEO: Authority, but also bias toward speed. Weight: medium on evidence, high on strategy.
|
||
- Engineering Lead: Technical feasibility. Weight: high on reversibility, low on user need.
|
||
- Head of Risk: Expertise on harm prevention. Weight: high on *sad al-dhara’i’*.
|
||
- Product Lead (you): Synthesis of evidence and *maqsad*. Weight: highest on the *hukm*.
|
||
|
||
The dissent here is the CEO’s objection to partial rollout. That dissent must be recorded. The Mujtahid asks: “Can we satisfy the CEO’s need for a full launch while keeping reversibility?” Answer: Yes — launch to 100% but with a kill switch (toggle) and strict *shurut* (max payout, KYC check). That makes it reversible in practice.
|
||
|
||
**PRODUCT_LEAD:** So the consultation produces a refined *shart*: full rollout, but with a toggle and risk controls. The Definition of Done for shura: *We have documented all stakeholder input, weighted it by expertise, and recorded dissent. The final decision is not a compromise — it’s a principled ruling based on evidence and maqsad.*
|
||
|
||
**MUJTAHID:** Exactly. The *shura* itself is part of the *ijtihad*. It doesn’t replace the *hukm* — it informs it. The *hukm* will be: “Ship instant payouts as a reversible experiment with clear nullifiers.” That is the Definition of Done. Not a ship date. Not a feature list. A principle.
|
||
|
||
---
|
||
|
||
*End of Part 1. Part 2 will deliver the Principle (Hukm/Daleel/Maqsad/Shurut/Munkathirat), the Protocol (3 steps), and the Retrospective (Muhasaba).* |