This is why the smartphone failed in the early 1990s
General Magic nearly built the smartphone in the early 1990s, and that is what makes the story so useful. The lesson is not that they lacked imagination. It is that imagination without constraint became expensive wandering.
A product needs someone to disappoint
The detail from the recent Planet Money episode that stayed with me was Tony Fadell’s mom sitting in user testing and saying, “I don’t get it. What is this thing for?”
*A still from the documentary, General Magic, directed by Sarah Kerruish and Matt Maude, of General Magic co-founder Marc Porat holding the Sony Magic Link during a press launch in New York City, in 1993.
Sarah Kerruish & Matt Maude/Screenshot by NPR*
That is the sentence every builder should fear.
Not because your mom is your ICP. She probably is not. But because confusion from a real person is more valuable than admiration from another engineer.
General Magic had a fictional customer named Joe Sixpack. He was the imagined ordinary guy on the couch, beer in hand, watching TV. But they did not seem to have a painful job he needed done. Joe Sixpack did not need email in his pocket if he did not already live in email.
A customer is not a demographic. A customer is a constraint on your choices.
This is where “building for users” gets flattened into startup theater. You can say “busy parents” or “developers” or “small businesses” and still have no idea what to build. A real customer tells you what not to build.
If your customer is “a solo developer maintaining three side projects,” you probably do not build a dashboard with twelve tabs. If your customer is “a DevRel lead preparing a conference demo on a flight,” offline mode matters more than another analytics chart. If your customer is “someone who has never used a computer,” a 200-page manual is not onboarding. It is evidence that you lost the thread.
That is the product power of a real user. They make your bad ideas harder to defend.
The fence is the product
Pirkei Avot, a tractate within the foundational work of Jewish text - the Mishnah (spanning 200 BCE - 200 CE), opens with a strange instruction from the Men of the Great Assembly: “Be deliberate in judgment, raise up many disciples, and make a fence around the Torah” (Pirkei Avot 1:1).
A fence sounds negative. It blocks. It narrows. It says no.
But in rabbinic thinking, the fence is not the enemy of the thing. The fence protects the thing from becoming theoretical. It turns values into behavior.
That is what constraints do in product work. They protect the actual mission from the fantasy version of the mission.
General Magic had the talent, capital, and ambition to keep expanding the possible. Games. Emojis. Sound effects. A calendar that eventually went back to the Big Bang. These are funny details now because they are so obviously absurd in hindsight, but every builder has a version of this.
You start with “let people capture notes quickly,” and then someone says, “What about graph view?” Then sync. Then collaboration. Then AI summaries. Then a plugin system. Then permissions. Then a marketplace. Then you are six months in and the original note capture still feels slow.
A good constraint is not a lack of vision. It is a fence around the part of the vision that matters first.
The rabbis understood this in legal form. Builders need to understand it in product form. A fence is the line that keeps your product from becoming a tribute to your own cleverness.
Too much money can make you less honest
The second lesson from the episode is more uncomfortable: General Magic may have had too much money too early.
This sounds like a fake problem. Most indie builders would love to test it personally. But capital changes the feedback loop. When you have enough money, you can replace painful prioritization with hiring. You can replace borrowing with inventing. You can replace shipping with expanding scope.
Planet Money describes General Magic attracting Sony, Motorola, Mitsubishi, Philips, AT&T, and others. That level of backing creates its own gravity. The product stops being a small wager against reality and becomes a platform everyone has already agreed is important.
At that point, customer confusion becomes easier to explain away. The tech is early. The market is immature. The partners need alignment. The ecosystem is not ready.
Sometimes that is true. Often it is cope with better vocabulary.
The Talmud has a useful phrase for this: “If you grasped too much, you grasped nothing; if you grasped a little, you grasped something” (Yoma 80a). The line appears in a legal context, but it is also a brutal product principle.
General Magic tried to grasp the future. Not one wedge into the future. The whole future.
Email. Phone calls. games. messaging. agents. an operating system. custom hardware. a new interaction model. a communications network. a pocket device before the pocket-device world existed.
That is not focus. That is a product roadmap written by awe.
The smaller grasp is not less ambitious. It is the part of ambition that can survive contact with reality.
You see the same thing with AI products now. A team says they are building “the operating system for knowledge work.” That usually means they do not know whether the first user is a lawyer, recruiter, analyst, support rep, founder, engineer, or student.
But when a team says, “We help immigration lawyers turn intake notes into first-pass petition drafts,” everything tightens. The UI tightens. The data model tightens. The sales motion tightens. The evaluation tightens. The no’s become obvious.
Small is not the opposite of big. Small is how big becomes legible.
Leaders are not always managers
One of the sharpest parts of the Planet Money segment is David Epstein’s distinction between General Magic’s leaders and its managers.
https://davidepstein.com/inside-the-box/
They had legendary programmers. Icons. People others wanted to impress. That is leadership of a kind. But it did not mean they had the operational discipline to set deadlines, clarify priorities, and kill attractive work.
This is a pattern I have seen over and over in technical teams. The most respected person in the room is often the person least inclined to say, “No, that is not this release.”
Because saying no feels pedestrian. It feels managerial in the least glamorous sense. It requires being the person who interrupts the fun.
But product work needs that person.
The calendar story is perfect. The software engineer writes the calendar from 1904 to 2096. Reasonable enough. Then someone says historical apps might need earlier dates, so it goes back to year 1. Then another group objects to the religious framing, so it goes back to astronomical time.
On paper, every objection has a kind of logic. That is what makes scope creep dangerous. It rarely arrives as stupidity. It arrives as a clever edge case wrapped in moral or technical seriousness.
And if nobody has the authority to say “not now,” the edge case wins.
The Talmudic story of the Oven of Akhnai in Bava Metzia 59b is often read as a story about authority. Rabbi Eliezer brings every possible proof that he is right, even a heavenly voice. Rabbi Yehoshua stands up and says, “It is not in heaven” (Bava Metzia 59b).
Meaning: once the Torah has been given into human hands, decision-making has to happen through the agreed process. Not through charisma. Not through miracle. Not through the most impressive voice in the room.
That is a product lesson too.
Great teams do not only need brilliant arguments. They need a legitimate way to end the argument.
Without that, the calendar goes to the Big Bang.
Constraints make taste visible
A lot of builders say they want creative freedom. I get it. Nobody wants a product manager turning every weird idea into a Jira ticket shaped like beige paste.
But the General Magic story suggests the opposite problem is just as dangerous. Total freedom can hide the absence of taste.
Taste is not the ability to imagine more. Engineers are rarely short on that. Taste is the ability to choose less and mean it.
Dr. Seuss wrote Green Eggs and Ham using only 50 different words because Bennett Cerf bet him he could not. The constraint did not make the book smaller. It made it sharper. Every parent who has read it seventy-three times knows the result worked.
NASA had hard physical constraints. Weight, power, materials, time, safety. Pixar has story constraints. A film has to make you care, not merely show you what the rendering system can do. Good constraints force the work to become communicative instead of ornamental.
General Magic had too many places to hide. If the device was confusing, it could be because the network was early. If the software was bloated, it could be because the future needed richness. If customers did not understand it, it could be because customers had not caught up.
Constraints remove hiding places.
A deadline asks, “What matters by Friday?” A customer asks, “What pain are you solving?” A budget asks, “What can you borrow?” A small team asks, “What can three people maintain without lying to themselves?” A narrow use case asks, “What does this need to do well before it does anything else?”
Constraints turn taste from a vibe into a decision.
This matters more now because AI makes expansion cheap. You can generate more screens, more copy, more features, more code, more tests, more docs, more personas, more strategy. The cost of adding has collapsed faster than the discipline of choosing.
That means constraints are no longer mainly imposed by reality. You have to impose some yourself.
The builder’s job is to choose the right no
The point is not to romanticize scarcity. Some constraints are stupid. Some deadlines are fake. Some budgets are abusive. Some managers kill the work because they cannot understand it.
But the answer to bad constraints is not no constraints. It is better ones.
For an indie builder, that might mean:
- One user type for the first version
- One painful workflow
- One primary platform
- One week to ship the ugly working thing
- One metric that tells you whether anyone cares
- One rule that every new feature must replace an old assumption For a developer, it might mean using boring infrastructure until the product earns novelty. General Magic built enormous amounts from scratch. Sometimes that is necessary. Usually it is ego wearing a systems-design hoodie.
For a product person, it might mean writing the “not for” list before the roadmap. Not for enterprises. Not for teams. Not for power users. Not for people who need SSO. Not for everyone yet.
That kind of narrowing can feel like cowardice when you are close to the work. But it is often the first honest move.
Rabbi Tarfon says in Pirkei Avot, “It is not your duty to finish the work, but neither are you at liberty to neglect it” (Pirkei Avot 2:16). I hear that differently in product terms now.
Pirkei Avot cover with Bukharian Judeo-Persian translation (1901-1902)
You do not have to build the whole future. You are also not free to avoid the hard, boring work of deciding what piece of the future you are responsible for now.
General Magic wanted to build the future in one breathtaking motion. Apple later built a more constrained version of that future through the iPod, the iPhone, the App Store, and a market that had learned what the internet in your pocket was for.
The difference was not imagination. General Magic had plenty.
The difference was the shape of the no.
So the question for your product is not whether you have enough freedom. You probably have more than you think.
The better question is: what constraint would make your next decision obvious?