Steve Jobs Was Insulted in Public. His Answer Revealed Where Product Decisions Should Begin
Published:
When someone publicly told Steve Jobs that he did not understand technology, Jobs paused, conceded part of the criticism, and asked a more consequential question: what will the customer ultimately gain?
Author: Koutian Wu; GitHub: ktwu01
I recently encountered the exchange in a LinkedIn clip labeled as Steve Jobs’s perfect response to an insult. The confrontation makes good short-form content, but treating it as a lesson in verbal composure misses the more useful argument.
The exchange came from a question-and-answer session at Apple’s 1997 Worldwide Developers Conference. An audience member challenged Jobs to explain Java and OpenDoc, said that he did not know what he was talking about, and asked what he had accomplished during his seven years away from Apple. The longer recording preserves both the challenge and the response, without reducing the episode to motivational subtitles.
OpenDoc was a software component framework developed with Apple’s participation. It was designed to let content from different applications work together inside compound documents. Engineers had invested years in it, but Apple discontinued the project in 1997. To the questioner, this was not an abstract portfolio adjustment. Apple had abandoned a technical direction in which people had invested work and belief.
The hostility was real, but so was the grievance behind it.
Jobs paused, took a drink, and acknowledged that the questioner was right about some things. He could not command every technical detail, and Apple had made mistakes.
He then declined to compete with the questioner on knowledge of OpenDoc. He changed the level of the decision.
His central instruction was to start with the customer experience and work backward to the technology.
This line is often flattened into a generic claim about customer obsession. Its harder purpose is resource allocation. If a company sees ten credible technologies but can execute only two or three, how should it decide which ones survive?
Technical novelty cannot answer that question by itself. Neither can the number of years already invested. A team must describe what the customer will gain, why that gain will change behavior or justify payment, and which product capabilities are required to deliver it. Only then should the team select systems and technologies. If that causal chain does not hold, technical sophistication does not create an obligation to keep funding the project.
Jobs used Apple’s LaserWriter printer as an example. Apple did not begin with laser technology and then search for buyers. It recognized a better desktop-publishing experience, then combined laser printing, a page-description language, and the Macintosh into a complete solution.
There is an important limit that short clips often remove. Jobs did not prove that every canceled technology lacked merit, nor did he answer each technical criticism about OpenDoc and Java. He answered a different question: why a company might stop a capable technology even while recognizing its engineering value.
Technical value is not the same as product value. Product value, in turn, does not automatically establish strategic priority at a particular moment.
Apple in 1997 could not preserve every worthy project. A Computer History Museum account describes a company that had lost more than $700 million in the preceding quarter and was burning through cash. Jobs cut languishing projects and concentrated resources on a small product set. In that context, his answer was not merely a marketing maxim. It was a rule for allocating resources under a survival constraint.
The same rule matters even more in today’s AI products and scientific research.
New models, agent frameworks, and datasets make it easy to begin with a technique and hunt for a problem afterward. Research proposals then take the form of using model X to solve problem Y. The model is concrete; the problem is a replaceable blank.
Working backward changes the questions. Who is blocked in which task? What does the current failure cost? How much must performance improve before it changes a decision? How will we test whether the improvement is reproducible rather than a polished demonstration? Once those questions have answers, we can choose a large language model, retrieval, reinforcement learning, a conventional algorithm, or no AI at all.
Benchmark research faces the same trap. Building a collection of tasks and later inventing a reason for their importance resembles building a technology and then searching for customers. A stronger sequence begins by defining the capability that matters, identifying what existing evaluations miss, and testing whether score changes predict performance on real work. Tasks, data, graders, and experiments follow from that measurement goal.
Jobs’s rule is not universal. Basic research often discovers phenomena before anyone can state a customer requirement, and general-purpose technologies may wait years for their most important uses. If every investigation required a short-term user story, science would discard much of its exploratory power.
The rule therefore belongs where resources are constrained and delivery matters: product teams, applied research, engineering programs, and benchmarks intended to represent real tasks. It should not become an excuse to suppress open-ended inquiry.
The exchange also offers a method for handling public criticism. Jobs conceded what the critic had right, refused to pretend expertise he did not possess, and stated the decision framework for which he was accountable. He did not win a detailed argument about OpenDoc. He showed the audience how he intended to lead Apple.
That is harder than producing a clever comeback.
The next time a new technology tempts us to launch a project, we can close the demo for a moment and ask the plain question underneath it.
What will the customer, user, or research community actually gain?
Answer that first. Then work backward to the technology.