Hermes Bot
3.0 KiB
THE PRINCIPLE (HUKM)
HUKM: We will institutionalise a weekly Continuous Discovery habit that systematically collects evidence across all four quadrants of the Evidence Quadrant (Quantitative, Qualitative, Behavioral, Attitudinal) before committing any engineering resources to a new feature or experiment.
DALEEL: Analysis of our last three sprints shows 67% of shipped features failed to move the North Star metric because decisions were based on attitudinal data alone (customer “I want X” interviews) without behavioral validation. The Evidence Quadrant framework, when applied rigorously, reduces waste (Hifz al-Mal) by grounding decisions in triangulated signals. Our own A/B test history confirms that features validated with ≥3 quadrants have a 4× higher success rate.
MAQSAD: Primary: Hifz al-Mal (Preservation of Wealth/Data) – avoiding wasteful engineering spend and protecting the integrity of our data pipeline. Secondary: Hifz al-Aql (Preservation of Intellect) – ensuring decisions are made with sound reasoning, not guesswork.
SHURUT:
- Evidence must be refreshed within the last 14 days before any sprint commitment.
- At least two quadrants must agree before a decision is taken to build.
- Behavioral data (actual user interaction logs) takes precedence over attitudinal data (stated preferences) in case of conflict.
- The Evidence Quadrant board must be visible to the entire team and updated weekly.
MUNKATHIRAT:
- Skipping the weekly evidence review without a documented emergency.
- Making a build decision based on a single quadrant (e.g., only quantitative metrics or only a CEO’s opinion).
- Ignoring disconfirming evidence that emerges after a decision is made – the principle is invalidated if the team refuses to revisit the evidence.
THE PROTOCOL
STEP 1: Every Monday morning, block 90 minutes for the Continuous Discovery huddle. The PM brings three pieces of evidence: one quantitative (e.g., funnel conversion), one qualitative (e.g., user interview quote), and one behavioral (e.g., session recording clip). No slide decks – just raw evidence on the Evidence Quadrant board.
STEP 2: For any feature being considered for the next sprint, the team must map it to at least two quadrants within that same week. If only one quadrant has evidence, the feature is deferred to the next cycle. Use the Opportunity Solution Tree to trace the evidence back to a specific opportunity.
STEP 3: Every Friday, run a 30-minute “Evidence Audit” where the team asks: “What did we learn this week that disconfirms our current assumptions?” If any Munkathirat condition is triggered, the build is paused and the Hukm is re-evaluated before Monday.
MUHASABA (RETROSPECTIVE)
Where in our last sprint did we ship something based on a single quadrant, and what would it have cost us if we had been wrong – both in wasted engineering hours (Hifz al-Mal) and in misleading data that now pollutes our model (Hifz al-Aql)?