القائمة
State a falsifiable hypothesis, then build a Markdown table comparing what you'd Expect to see if it's true vs. the Actual data (or what data is needed). Use for designing analysis plans, pinpointing where reality diverges from expectation, or step 3 of a strategic analysis.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Apply the 5 Whys technique to drill from a surface problem to a root cause. Outputs five sequentially numbered "Why?" lines with brief answers, ending in a root-cause statement. Use after an issue tree to drill the critical branch deeper, or any time the user wants to test whether the apparent cause is the actual cause.
Structure a recommendation top-down — Barbara Minto's Pyramid Principle. Outputs a single-sentence top-line answer, three to five supporting arguments, and one layer of evidence under each. Use to convert analysis into executive communication, or to structure a board-meeting talk track.
Tier-1 strategy-consultant analysis using seven frameworks in sequence — MECE, Issue Trees, 5 Whys, Hypothesis-Driven, Pareto, So What?, and Pyramid Principle. Use when the analysis needs both deeper root-cause drilling AND executive-ready communication structure. Heavier than the 5-framework master; reach for it on high-stakes work.
Tier-1 strategy-consultant analysis tailored for edtech / online-learning problems — activation, completion, learning outcomes, monetization. Same five frameworks with edtech-aware MECE defaults, vocabulary, and root-cause priors.
Tier-1 strategy-consultant analysis tailored for fintech / payments / lending / fraud problems — approval rates, fraud loss, delinquency, regulatory friction. Same five frameworks with fintech-aware MECE defaults, vocabulary, and root-cause priors.
Tier-1 strategy-consultant analysis tailored for public-sector / civic-ops problems — backlogs, processing cycle time, citizen satisfaction, procurement. Same five frameworks with government-aware MECE defaults, vocabulary, and root-cause priors.
| name | hypothesis-driven |
| description | State a falsifiable hypothesis, then build a Markdown table comparing what you'd Expect to see if it's true vs. the Actual data (or what data is needed). Use for designing analysis plans, pinpointing where reality diverges from expectation, or step 3 of a strategic analysis. |
Don't boil the ocean. Start with a hypothesis — a specific, falsifiable claim about why the problem exists — then identify exactly what data would confirm or refute it. This is how consultants avoid running 40 analyses when 2 would do.
The visual trick: a comparison table that shows what you'd expect to see if the hypothesis is true next to what the data actually shows (or what data is required if not yet collected). The point of divergence is where the answer lives.
**Hypothesis:**.**Hypothesis:** [One-sentence falsifiable claim.]
| Variable | Expected (if hypothesis true) | Actual / Required Data |
|---|---|---|
| Variable 1 | Expected pattern | What we observe / need |
| Default | When to flex |
|---|---|
| 4–7 variables | If only 3 truly diagnostic variables exist, use 3. Don't pad. |
| At least one control row | Don't flex this — confirmation bias is the most common failure mode. |
| One hypothesis per table | If multiple hypotheses, output multiple tables. |
| Variables are measurable | Don't flex this — unmeasurable variables aren't testable. |
The control row test: at least one row should describe something that should NOT match if the hypothesis is true. If everything in your table is set up to confirm, you're not testing — you're rationalizing.
Problem: A B2B software company raised list prices 18% in January. Six months in, new-logo bookings are down 22%.
Hypothesis: The price increase is the dominant driver of the bookings decline (rather than competitive shifts or pipeline quality issues), and the impact is concentrated in deal sizes under $50K where price sensitivity is highest.
| Variable | Expected (if hypothesis true) | Actual / Required Data |
|---|---|---|
| Win rate by deal size band, Q1 vs. Q3 | Should drop sharpest under $50K, modest under $250K, near-flat above $250K | Need to pull from CRM — segment win rates by ACV band before/after Jan 1 |
| Stage where deals stall | Late-stage stalls (procurement / pricing review) should rise; early-stage should be flat | Q3 stage drop-off: late-stage stalls 38% (Q1: 12%) ✅ matches |
| Discount approval rate | Sales should be requesting more discount approvals to close deals | Discount-request volume up 2.4× ✅ matches |
| Competitive losses citing price | Win/loss survey should show "too expensive" rising as a top-3 reason | Q1: 14% → Q3: 41% ✅ matches |
| Win rate above $250K (control) | Should be near-flat — large deals less price-sensitive | Q1: 28% → Q3: 26% — near-flat ✅ supports hypothesis |
| Pipeline quality score (control) | Should be unchanged — would invalidate hypothesis if it shifted | MQL → SQL conversion stable; no quality shift ✅ supports hypothesis |
| Recent competitor pricing moves | Should show no major change | Two competitors held prices; one raised 10% (similar trajectory) ✅ supports hypothesis |
The two control rows (>$250K win rate, pipeline quality) are designed to invalidate the hypothesis. They didn't — that's strong evidence. Without them, the table would just be confirmation bias.
strategy-consultant — hypothesis testing is step 3 of 5. Run mece-framework and issue-trees first to surface the hypotheses worth testing.Adapted from Analyst Academy on YouTube — 5 Consulting Frameworks to Solve Any Problem. MIT-licensed; see LICENSE.