Portfolio

Purpose and Scope

This note documents the methodology I use to construct hypothesis-led analytical memos, similar in rigor and structure to those produced in management consulting and investment research.

The objective is not to explain what to think about a specific industry or company, but how to think when the problem statement is ambiguous and domain knowledge is incomplete. The focus is on hypothesis formulation as a tool for structured learning, not as a mechanism for prediction or opinion.

This piece is written for readers who are serious about analytical work—consulting, product strategy, investing, or research—and who want to understand the reasoning process that sits behind consulting-grade memos. It assumes comfort with structured thinking and does not attempt to simplify concepts for a general audience.

This note does not provide:

Ready-made industry frameworks
Case interview tricks
Company-specific analysis
Motivational or career advice

Instead, it lays out a repeatable mental process for turning unclear problem statements into testable, decision-oriented analyses.

The methodology outlined here has been developed and refined through repeated application in hypothesis-led analytical memos, several of which are published elsewhere in this portfolio.

First Principle: What Hypotheses Actually Are

A hypothesis is often misunderstood as a guess about the answer.
In analytical work, this framing is incorrect and actively harmful.

Hypotheses are not predictions. They are structured tools for learning.

A well-formed hypothesis is valuable not because it is right, but because it creates clarity under uncertainty. It does this in two ways:

If the hypothesis is true, it explains a meaningful portion of the problem space
If the hypothesis is false, it allows an entire class of explanations to be ruled out

In both cases, uncertainty collapses.

The goal of hypothesis-led analysis is not to arrive at the correct answer as quickly as possible, but to systematically eliminate weak explanations and converge on a small set of plausible mechanisms.

Hypotheses function less like opinions and more like experiments. They are provisional, falsifiable, and designed to force contact with evidence. A hypothesis that cannot be tested is not analytical; it is rhetorical.

Early hypotheses are not meant to be precise. They are meant to be directionally correct enough to guide investigation. The analyst’s job is not to be right upfront, but to propose structure early and revise aggressively as evidence accumulates.

The Single Biggest Beginner Mistake

The most common mistake beginners make is deceptively reasonable:

“Let me understand everything first. Then I’ll form hypotheses.”

This approach is structurally flawed.

In complex systems, complete understanding is never available upfront. Waiting for clarity before forming hypotheses leads to analysis paralysis or shallow summarization.

Experienced consultants reverse the sequence. They propose explanations in order to understand the system.

Without hypotheses, there is no filter for relevance. Every fact appears important. Effort accumulates without progress.

The consultant mindset asks instead:

“What is a complete but imperfect explanation I can test immediately?”

An imperfect hypothesis that can be tested is more useful than a vague understanding that cannot be operationalized.

Start From the Outcome, Not the Domain

When domain knowledge is limited, starting with industry detail is often inefficient.

A more reliable approach is to start from the outcome.

Outcomes impose constraints. Domains do not.

An outcome such as:

“The business did not reach self-sustaining scale”

immediately forces attention onto systemic mechanisms rather than incidental factors.

Starting from the outcome leads to sharper questions:

What must have failed for this to occur?
Which failures could persist even with growth?

Outcome-first thinking anchors analysis and prevents unfocused exploration.

Decompose the System, Not the Company

Consultants analyze systems, not companies.

Any business system can be decomposed into:

Demand-side behavior
Supply-side behavior
Unit economics
External constraints

When outcomes repeat across firms, at least one of these components is structurally broken.

This decomposition works even when domain knowledge is shallow. It keeps hypotheses abstract enough to generalize and concrete enough to test.

Generic Business System Decomposition

The “What Must Be True?” Question

Once the system is decomposed, hypothesis generation becomes logical.

The most powerful question is:

What must be true for this system to work?

These necessary conditions are then inverted:

What if demand does not return?
What if trust is expensive?
What if costs fail to decline with scale?

Each inversion becomes a candidate hypothesis.

This approach ensures coverage without relying on intuition.

From Conditions to Hypotheses

A condition becomes a hypothesis only when it:

Describes a mechanism, not a judgment
Refers to persistent behavior
Can be tested independently

For example:

“Execution is weak” is not a hypothesis
“High supplier churn prevents consistent service quality from forming” is

Hypotheses must be structural, not moral or emotional.

Testability Is Non-Negotiable

A hypothesis that cannot be tested is an opinion.

A simple test applies:

Can I imagine a chart, table, or metric that could disprove this?

If not, the hypothesis fails.

Testability forces precision, prevents narrative drift, and anchors analysis in evidence.

Coverage Over Perfection (MECE, Properly Understood)

Early hypothesis sets do not need to be perfectly MECE.

They need to be collectively sufficient.

MECE emerges through testing, not before it. Over-optimizing for MECE too early leads to abstraction without insight.

Clarity is the output of analysis, not its input.

Choosing Hypotheses That Matter

Strong hypotheses:

Explain many examples
Hold across time
Collapse complexity into mechanisms

Weak hypotheses explain one company or one episode.

A useful test is:

If this hypothesis is true, does it materially change how I understand the problem?

If not, it does not belong.

The 3–5 Hypothesis Constraint

Consulting-grade analyses rarely rely on more than three to five core hypotheses.

Beyond this, clarity degrades and abstraction fails.

Many hypotheses may be explored initially. Discipline lies in what survives into the final structure.

Clarity is achieved by saying only what must be true.

The Hypothesis Generation Procedure

When domain knowledge is limited:

Define the outcome precisely
Decompose the system
Ask what must be true for success
Invert the conditions
Phrase hypotheses structurally
Enforce testability
Cut to three to five hypotheses

This guarantees fast convergence from ambiguity to structure.

Hypothesis Generation Procedure

Application Note

This methodology underpins the analytical memos published elsewhere in this portfolio.

In each case, hypotheses determined what needed to be learned and in what order. Data and research were pulled in selectively to test mechanisms, not to describe industries.

The approach is deliberately domain-agnostic and repeatable.

What This Methodology Enables

This methodology does not eliminate uncertainty. It manages it productively.

It prevents unfocused exploration and premature conviction. It enables structured learning under incomplete information.

Hypotheses are not answers.
They are the tools that make clear reasoning under ambiguity possible.

How I Structure Hypothesis-Led Analytical Memos