The Four-Square Grid Steve Jobs Drew, and What Apple Could No Longer Fund

A founder should remove an impressive AI feature when its path to revenue extends beyond the company’s next runway decision. The feature may be technically strong, but the roadmap must answer a harder question: can the company survive long enough for this work to matter?

In 1997, Apple had too many answers and too little time. The company was losing money, its product line had spread across a confusing collection of computers and peripherals, and Michael Dell had publicly suggested that Apple should shut down and return the money to shareholders.

Steve Jobs had recently returned. During one product review at Apple’s headquarters in Cupertino, he stopped the discussion and drew a simple grid. Consumer and professional sat on one axis. Desktop and portable sat on the other. Apple would concentrate on one product in each square.

Projects disappeared. Some were technically ambitious. Some had teams, internal advocates and years of work behind them. Apple cut much of the product line because the company could no longer fund every plausible future.

Walter Isaacson documents the episode in his biography Steve Jobs. The grid did not prove which four products would win. It forced Apple to admit what its resources could support.

The feature had technical value and bad timing

I have seen the smaller version of this decision inside early AI products.

The feature usually demos well. A user types a loose instruction, the system gathers information from several sources, reasons through the request and produces a polished result. It feels like the clearest evidence that the product deserves to exist.

Then the commercial questions begin.

Who has asked to pay for it? How much human checking does each output require? Does it shorten a sales cycle already in progress? Can the current team make it reliable before the next funding, hiring or payroll decision?

A feature can have long-term value while failing every near-term test. That tension matters most for founders building from Accra, Lagos or Berlin while selling across several markets. Customer budgets differ. Procurement takes longer in one market than another. A contract that looks close from Ghana can spend weeks inside a European buyer’s internal review.

Runway keeps moving while the demo waits.

This is where teams often protect the feature because removing it feels like reducing the ambition of the company. The better interpretation is narrower: the company is sequencing ambition around survival.

Put revenue timing on the roadmap

A roadmap normally shows build order. A runway decision requires another layer: the earliest credible date each item can affect cash.

For every major feature, I would write down four things:

• The named customer problem it solves.
• The buyer currently discussing that problem.
• The remaining work required before that buyer can use it.
• The earliest credible route from use to payment.

“Users will love this” cannot carry a runway decision. Neither can a large theoretical market. The useful evidence is closer to the ground: two buyers have requested the same workflow, one has agreed to a paid pilot, and the team can deliver the required version with the people already available.

This is also why a flawless demo can be dangerous. It creates a sense of progress while hiding the distance between technical completion and a signed contract. I explored that gap in What If Your Flawless AI Demo Still Has No Buyer?.

The calculation does not need false precision. If an AI agent needs another quarter of evaluation, integrations and exception handling, while a simpler reporting feature can unlock an active contract this month, the order becomes easier to defend.

Removal creates a test, not a funeral

Deleting the feature permanently may be unnecessary. Remove it from the funded roadmap and define the evidence that would earn its return.

That evidence might be three customers requesting the same capability, a paid design partner, or a distribution agreement that changes the economics. Until then, keep the research notes and stop assigning engineering time.

This distinction protects the team from two expensive reactions. The first is continuing because the feature already consumed months of work. The second is throwing away useful learning because the company cannot build the full version today.

The same discipline applies to hiring. A senior engineer may expand what the company can build, yet shorten the time available to find revenue. Pausing a Senior Engineering Hire examines that trade directly.

Make the runway decision visible

Jobs’s four-square grid worked because it made scarcity visible. Apple could debate individual products for months. The grid forced every product to compete for one of four funded positions.

A founder can do the same with a single page.

List the next runway decision, the cash required before it arrives, the customers closest to paying and the work standing between them and payment. Then place each roadmap item beside one of those customers. Anything without a credible connection belongs below the funding line.

The most impressive AI feature may return later with better models, stronger demand and more room for evaluation. For this afternoon, the founder’s job is simpler: move the team onto the work that can produce evidence, a usable result and a payment before the calendar makes the decision instead.