Who Saw the Connection? #06 — Walkman × Subtraction × Product Thinking
In 1979, Sony was preparing to sell a cassette machine with what looked like an obvious defect: it couldn't record.
That sounds less strange now because we already know the Walkman. We know the headphones, cassette tapes, belt clips, joggers, commuters and teenagers staring out of train windows with their own soundtrack playing directly into their ears. Sony's employees in 1979 had none of that hindsight. What they knew was the cassette recorder, and cassette recorders recorded things. The clue was rather aggressively present in the name.
Removing that capability did not look like innovation. It looked like taking a useful product and making it worse.
Yet that decision helped create one of the defining consumer products of the 1980s. And the interesting lesson isn't really “less is more.” That phrase has already survived enough corporate presentations.
The more useful idea is this: sometimes a requirement survives only because nobody has bothered to ask whether it still belongs.
It Started With a Man Who Didn't Need Half the Product
Sony co-founder Masaru Ibuka travelled often and liked listening to music. Sony already made the TC-D5, a high-quality portable stereo cassette recorder, but “portable” was generous. It weighed around 1.7 kilograms. You could absolutely travel with it, in the same sense that you can travel with a desktop monitor if you're sufficiently committed.
Before another trip to the United States, Ibuka asked for something simpler. He didn't need to record anything. He just wanted a lightweight machine that could play stereo music while he travelled.
Sony already had a small monaural recorder called the Pressman. Engineers modified it by removing the recording circuitry and adapting it for stereo playback. Much of the technology already existed; the real shift was in what the technology was being asked to do.
Ibuka took the modified machine on his trip, liked it and showed it to Sony chairman Akio Morita when he returned. Morita heard more than a convenient travel gadget. He saw the possibility of young people carrying music with them throughout the day.
Today that sounds obvious, which is one of the unfair things about successful products. Once the behaviour becomes normal, everyone develops excellent retrospective product instincts.
In early 1979, it wasn't obvious at all.
The Missing Feature Looked Like the Whole Problem
When Morita pushed the idea internally, people questioned whether anyone would buy a cassette player that couldn't record. Their skepticism made sense. They were evaluating the product through the category they already understood.
If a cassette machine is supposed to record and play, then removing recording is a downgrade.
But Morita was quietly changing the category.
The old product was a portable recorder. The new job was personal listening.
Once you define the problem that way, recording stops being an essential capability and becomes baggage.
That distinction is where the software analogy becomes interesting, because we do this constantly. We inherit a system, an application or a workflow and assume everything already inside it is part of the requirement. Often it isn't. Sometimes it's simply part of the history, wearing a lanyard and attending refinement meetings.
The question quietly changes from “What does the user need?” to “Which parts of the old thing do we need to preserve?”
Those are not the same question.
How Software Jiras the Walkman Out of Existence
Imagine a company has spent ten years building a large enterprise platform. It has dashboards, reporting, exports, approval workflows, user administration, bulk actions, custom fields and enough settings to make the preferences screen mildly threatening.
Then somebody says the company needs a mobile version.
The obvious question is: which desktop features need to be available on mobile?
Reporting? Probably. Admin? Maybe. Workflow configuration? Someone will insist. Export? Apparently Excel has constitutional protection.
Six months later, you've rebuilt the desktop application on a smaller screen and forced users to operate it with their thumbs.
The more useful question is different: what is the person actually trying to do while they're mobile?
Maybe the answer is simply to view a request, approve or reject it, and leave a comment. If that's the job, you're not building a smaller copy of the desktop system. You're building something else.
Sony didn't shrink the TC-D5 while preserving every capability. It isolated the behaviour Ibuka cared about and optimized around it.
Now imagine the Walkman project inside a modern delivery process. Somebody creates an epic called Portable Cassette Experience — Feature Parity With Pressman. Recording, microphone support, speaker output and backward compatibility all become acceptance criteria. Architecture schedules a review. Someone suggests keeping recording “for future flexibility.” Another person asks whether we should abstract cassette transport behind an interface in case the company moves to another magnetic-media provider.
Three quarters later, Sony has successfully Jira'd the Walkman out of existence.
That joke lands because software teams really do preserve things this way. A feature exists, so it feels safer to keep it. Documentation mentions it. Someone requested it years ago. Nobody remembers the original reason, but removing it now sounds risky.
Eventually, the old product begins writing the requirements for the new one.
Inherited Requirements
I think inherited requirements is a useful way to describe this.
An inherited requirement is something we assume a new system needs because the previous system had it, not because we've established that the current use case still requires it.
Cassette machines record. Admin portals have dashboards. APIs expose CRUD for every entity. Mobile apps need parity with web. Replacement platforms are expected to mimic the legacy system, including several behaviours everybody already hates but has learned to work around with impressive muscle memory.
Some of those requirements are valid. Users may depend on them. Removing them carelessly can cause real damage.
But they should still have to answer one question:
Does the job we're designing for actually require this?
That question matters even more in software because features rarely stay as small as they look in the backlog.
Suppose someone asks for a simple capability: allow an order to be edited after submission. On the screen, that might be one button. Behind it, you may now need permissions, audit history, versioning, concurrency handling, downstream synchronization, new event semantics and rules about what happens if the order has already entered fulfilment.
Then somebody asks whether an edit should retrigger notifications.
A meeting appears.
The button was cheap. The state space wasn't.
This is why the cost of a feature is not just the sprint that builds it. It is the set of future decisions that feature keeps forcing the system to make.
The Walkman Wasn't Really a Cassette Player
Another part of the story reinforces this.
The player alone wasn't enough. Morita understood that if people had to carry the large, heavy headphones common at the time, the idea of personal portable music would feel considerably less portable. Fortunately, Sony had lightweight headphones under development, and those became part of the experience.
That sounds like a small detail, but it changes how you think about the product.
The Walkman wasn't really the cassette mechanism.
It was the ability to carry music with you.
The machine, headphones and physical freedom all belonged to the same user experience even though they came from different technical components.
Software has the same problem with boundaries. We draw frontend, API, database, queue and payment service as separate boxes because those are convenient things for engineers to own.
Users experience workflows, not boxes. They are irritatingly uninterested in how clean our service boundaries looked in Miro.
A payment experience is not the payment service. It includes checkout, authorization, callbacks, state changes, retries, confirmation and whatever happens when one system succeeds while another times out.
A technically neat architecture can still slice the product in the wrong places.
Sony's useful move was to stop asking how to improve a recorder and start asking what personal listening required.
Everything else became negotiable.
The First Month Didn't Look Like History
Sony introduced the Walkman in 1979, but the launch wasn't an instant victory. The initial press reaction was modest, and first-month sales were weak compared with Sony's initial production run.
This is one of those details that gets lost once a product becomes iconic.
People didn't immediately understand why they would walk around wearing headphones. The behaviour itself was unfamiliar, so Sony had to demonstrate it. Employees went into Tokyo wearing the product. People were encouraged to try it. The value became much clearer once someone actually put on the headphones and experienced music following them through the city.
Then demand accelerated.
By the 1980s, the behaviour no longer looked strange. The Walkman became one of the objects that defined the decade, and the supposedly missing recording function stopped looking missing at all.
The category had changed.
That's what makes inherited requirements difficult to challenge. Before the new idea works, removing something looks like incompleteness. Afterward, people wonder why anybody assumed it had to be there.
Software Has Done This Too
Instagram offers a useful later parallel. Before Instagram, Kevin Systrom and Mike Krieger had worked on Burbn, a broader mobile social product with several behaviours around location and sharing. Over time, the photo-sharing behaviour became the thing worth centring.
The useful point isn't that Instagram was “simpler.” Plenty of simple products are terrible. A blank screen has excellent feature discipline and surprisingly poor retention.
The interesting decision was recognizing that something previously treated as one feature inside a broader product might actually deserve to become the product itself.
That's close to the Walkman move.
Sony could have continued improving a portable recorder. The Instagram team could have kept improving a broader social application. In both cases, the harder question was whether the product boundary itself was wrong.
That kind of subtraction is often more difficult than adding another capability because it requires someone to say, with confidence, that something does not belong.
Senior Engineers Eventually Get Paid to Prevent Things
There is a career angle here that I think matters, especially in software.
Early in your career, value is easy to demonstrate through addition. You built the API, introduced caching, created the service, automated the workflow and shipped the feature.
Later, some of the highest-value decisions start sounding strangely unimpressive.
We don't need another service.
This doesn't need to be configurable.
Don't introduce Kafka here.
The existing database is fine.
That abstraction solves a problem we don't have.
We can delete this whole layer.
Those decisions don't make great screenshots. There is no flashy sprint demo for a service that never existed.
Nobody puts a slide up saying, “Here are the 4,000 lines of code Amrish convinced us not to write.”
Maybe they should. It would at least be the first architecture presentation where the codebase got smaller by the end.
Good engineering judgment isn't only knowing how to build more things. At some point, it becomes knowing which things should never be built in the first place.
That is not minimalism for its own sake. It is understanding the cost of every decision you allow into the system.
Complexity Usually Arrives Looking Completely Reasonable
Most bloated systems were not designed by people trying to create a mess. Complexity usually enters politely.
“Let's keep it configurable.”
“We might need it later.”
“Can we support both?”
“For compatibility with the old system…”
“It's only one extra field.”
None of those statements is obviously reckless. That's why they accumulate so easily.
Over time, a focused product can become an archive of old assumptions, each one individually defensible and collectively exhausting.
The Walkman is useful because Sony made a decision that would have been easy to reject as incomplete.
You can listen.
You cannot record.
In 1979, that sounded like something was missing. A few years later, nobody looked at someone jogging with a Walkman and wondered why they couldn't record an interview.
The product had escaped the category that originally judged it.
What Sony Actually Removed
The Walkman doesn't prove that fewer features always produce better products. It doesn't justify cutting functionality users genuinely need, and it certainly shouldn't become a clever excuse for shipping half-finished software and calling it focus. Product teams already have enough vocabulary for defending questionable decisions.
The useful lesson is narrower.
Requirements should earn their place in the system you're building now.
Not because the old product had them. Not because a competitor lists them. Not because they've survived six years of backlog grooming. And not because somebody says, “We've always had it.”
Masaru Ibuka wanted music while travelling without carrying a heavy recorder. Sony engineers modified something the company already knew how to build. Akio Morita heard the result and saw a behaviour that the existing product category didn't describe very well.
Others saw an incomplete cassette recorder.
Morita saw personal music.
That's the interesting part of the story.
Software teams are very good at documenting everything we add. Roadmaps contain features. Sprint reviews demonstrate features. Release notes announce features. Career documents list everything delivered.
There is usually no ticket for the thing somebody questioned early enough that the team never had to build it.
Maybe there should be.
Because one of the most influential consumer products of the twentieth century wasn't defined only by what Sony managed to fit inside it.
It was also defined by what Sony was willing to leave out.
Sources & Further Reading
Sony's corporate history provides the detailed account of the Walkman's development, including Masaru Ibuka's request, the modified Pressman, Akio Morita's decision to commercialize a playback-only device, the internal skepticism and Sony's early attempts to demonstrate the new behaviour.
37signals' Getting Real provides a useful software counterpart through its arguments around fewer features, less software and the long-term cost of unnecessary complexity.
Instagram's early history offers a later example of a broader product narrowing around the behaviour that ultimately became its centre.
About the Person Who Apparently Wants Fewer Features Now
I'm Amrishkhan Sheik Abdullah, a Technical Lead and software architect based in Dubai. I spend much of my time around backend systems, APIs, microservices and distributed architectures — environments where one innocent-looking requirement can acquire enough downstream consequences to qualify as a family tree.
I write about software architecture, distributed systems, engineering decisions, AI developer tooling and the strange places good engineering ideas show up when you're paying attention.
Who Saw the Connection? is my series about exactly that: true stories where somebody looked at a familiar product, industry or assumption and noticed something everybody else was looking straight through.
Read More of My Writing
I publish longer engineering articles, architecture deep-dives and stories that occasionally begin with cassette players and end with me questioning your product backlog.
Writing: amrishkhan.dev/blog
Elsewhere on the Internet
Portfolio: amrishkhan.dev
GitHub: github.com/amrishkhan05
DEV Community: dev.to/amrishkhan05
LinkedIn: linkedin.com/in/amrishkhan
Apparently my current engineering strategy is to look at every “mandatory” feature and wonder whether Sony would have deleted it before someone turned it into an epic.
Top comments (0)