The Two Problems

Here's a thought experiment. Go ask ten people — a business school graduate, a startup founder, a fund analyst, your uncle who owns three dry-cleaning shops — to define what a business is.

You'll get ten different answers. The MBA will cite value creation and competitive moats. The founder will gesture at her product roadmap. The analyst starts with EBITDA. Your uncle says it's about keeping the machine running and getting home by 6pm.

They're all right. They're also all describing different parts of the same elephant.

Why this lens matters to an investor

Before the framework: the reason an operator's lens creates investment alpha is specific. Markets price what they can see — revenue growth, margin progression, multiple expansion in analyst models. What they cannot see, until it's too late to be early, is the machine that produced those outcomes.

The operator reads the machine before it shows up in the financial statements. The investor who can do the same sees the gap between what exists and what's currently priced. That gap — when correctly identified — is the entire investment thesis. Everything else is timing and position sizing.

Here's the operator's version: a business is an entity that has exactly two problems. That's it. Two. Everything else is detail.

Problem One: Demand

Your business exists because someone has a need. They want a thing, a feeling, or a problem to disappear. Your job: find those people, understand what they'll pay, and keep them coming back. The metric is revenue — and all the variables that causally determine it.

Willingness to pay is probably the most underrated concept in business. People pay $7 for airport coffee they'd never buy at home. They maintain gym memberships last visited in February — and feel entirely fine about it. They pay a 40% software premium for a product that's maybe 15% better because someone they trusted recommended it. Understanding why willingness to pay exists — and how quietly fragile it is — is most of the demand problem.

The metric that actually matters

Here's the first thing that separates operator thinking from analyst thinking: the metric the market watches is almost never the metric that causally determines the outcome you care about.

Consensus metrics are priced. Driver metrics usually aren't.

Warby Parker: the Street watches same-store sales growth. The metric that actually matters is new store unit-level contribution margin and months-to-cash-flow breakeven for each new location. If that number is healthy, revenue growth follows mechanically — you're just opening more stores whose economics already work. If it's deteriorating, revenue growth is borrowed time. You're deploying capital into locations whose economics are softening, and the headline won't reflect it until the vintage effect is too large to hide.

For an AI software company selling API access, the causal metric isn't revenue growth. It's the slope of cost-per-token versus the slope of average selling price. If your inference costs are declining faster than your ASPs are compressing, you're building a margin moat. If ASPs are falling faster than costs, you're in a race to zero and the infrastructure you're building is a liability, not an asset. Revenue growth in both scenarios can look identical for years.

Problem Two: Supply

The second problem is supply. Someone has to actually make the thing.

Every business has a production system. You're assembling inputs — people, materials, software, time, energy — and converting them into what your customer pays for. The metric is cost: what does it take to produce one more unit, and how does that number behave as you scale?

The supply problem is where a lot of businesses quietly die — often while their demand charts are still pointing happily upward, which is exactly the kind of irony the universe enjoys. Unit economics are upside down. Margins compress as you scale. Inputs get expensive faster than pricing can keep up. You're growing into a burning building and calling it momentum.

Two industries make the point sharply — and they couldn't be more different.

An AI software company selling an API

The demand problem: developer adoption, API call volume, application stickiness. Your API becomes a dependency embedded in someone else's product. Clean flywheel.

The supply problem is entirely physical: compute. Every inference request costs real GPU cycles. Output tokens are more expensive than input tokens because generation is sequential — one autoregressive forward pass per token, no batching around that at the margin. Your supply chain is NVIDIA allocation, data center power contracts, and inference engineers whose entire job is shaving dollars off cost-per-token and milliseconds off latency.

The interesting dynamic: at first, demand growth and supply costs grow proportionally. But with disciplined optimization — better batching, inference efficiency improvements, longer context caching, newer hardware generations — the unit economics can improve significantly with scale. The supply problem isn't "buy more GPUs." It's "build a better factory with the GPUs you have."

A defense company selling directed-energy weapons

Defense inverts the demand timeline entirely. Your customer is a government. Your sales cycle can span a decade. Winning a program of record creates a protected multi-year revenue stream that resembles nothing in consumer or enterprise software. The demand problem is relationship-dense, politically complex, and slow — but once won, durable. Budget cycles have institutional memory. Switching vendors mid-program is expensive and politically uncomfortable for everyone.

The supply problem is a different kind of hard. You're engineering with exotic materials: precision optical components, high-voltage power electronics, thermal management systems sophisticated enough to prevent the laser from burning itself out before it burns anything else. The physics impose supply constraints: beam coherence at range, atmospheric distortion, power density requirements. These aren't commodity inputs from standard procurement. They require years of specialized R&D, government-qualified supply chains, security clearances, and ITAR compliance overhead that adds real cost without adding real margin.

The supply problem for a laser company is the decade of R&D that went into making the beam stay coherent at 5 kilometers. That's a genuine moat — but it's also a cost you carry forward, amortized into every unit, every upgrade cycle, every follow-on program. The moat and the cost are the same thing.

And professional services, briefly

Take any major consulting firm. The demand problem: build something intellectual — analysis, advice, strategy — and convince a CFO or board that it's worth a significant premium to their business. The demand problem lives entirely upstream of the invoice: reputation, relationships, the brand that makes a call worth taking.

The supply problem is talent inventory management. You're running a people-throughput machine: hire smart people, staff them on client work, bill them at a multiple of their fully-loaded cost, promote the ones who eventually bring in their own clients, and obsess over utilization — billable hours as a percentage of available hours — with factory-floor intensity. Two problems. One firm. Completely different levers.

The dual demand problem

One complication before the framework settles: some businesses don't have one demand problem. They have two, simultaneously, for customers whose interests can conflict.

Google serves users and advertisers. Both are customers. Both have willingness-to-pay functions. The model only works when both sides stay healthy. Over-optimize one — degrade organic results to pack in more ads — and you erode the asset that made the advertiser side valuable in the first place.

Yelp built this and then systematically dismantled it. Early Yelp solved the user demand problem cleanly: local reviews people actually trusted. Then capital allocation moved aggressively toward advertiser monetization. Advertiser demand grew; user trust in the reviews gradually eroded; advertiser demand eventually followed the users down. They solved one demand problem by neglecting the constraint that sustained the other.

The insight: in a dual-demand business, you're not optimizing toward a target. You're managing against a constraint — don't degrade one customer relationship below the threshold at which it loses value to the other. Running a business against a constraint is a fundamentally different operating mode than chasing a growth number.