Apple is Removing the Headphone Jack
23 June 2016 ‧ 2 min read
If the rumors that have been spreading for a few months are correct, Apple will remove the 3.5mm headphone jack on the next iPhone. Over the past few days, an intense debate has unfolded in the tech community about whether this is the right decision, and whether this is the right time for it.
Personally, I fall on the side of not liking it. I rely on my corded in-ear headphones most of the time. Wireless ones, particularly of the in-ear variety, are simply not quite there yet — they are bigger, less comfortable, hardly last a whole day without recharging, and Bluetooth audio quality and reliability can’t always match pure analog transmission over a headphone cord. Eventually, I do agree that wireless headphones will be way better than wired ones, but we are not at that point yet. Corded Lightning headphones, on the other hand, provide no real user benefit, and are incompatible with every other audio-outputting device I own.
Time and sales figures will tell whether Apple made the right decision.
Looking at this decision as a Product Manager, however, I admire it. Changing products is hard. Removing features is the hardest form of change — no matter how you do it, some users will find their use cases no longer supported, or their workflows negatively impacted. Additionally, removing a feature rarely provides any tangible short-term user benefit. In the case of the headphone jack, while some sources have claimed that the reason for ditching it is to make the iPhone slimmer, others have pointed out that e.g. the iPod Nano already has a slimmer case despite sporting a headphone jack. So, almost certainly there will be no direct user benefit from removing the jack. The easy product management decision, therefore, would be to keep the jack. Seems to be an easy tradeoff: No tangible benefits vs. pissing off some of your users.
Feature removal does offer one huge longer-term benefit though: It reduces product complexity. Product complexity makes changes more expensive, since more cases have to be taken into account. It makes testing harder. It increases security risks since it opens additional attack vectors and increases the amount of code that could have exploitable bugs. It can make the product more difficult to learn and master. Due to all of these factors, it makes development cycles longer and more expensive. And product complexity is not linear: Since every feature has a multiplicative effect on the number of feature combinations, the effect is exponential.
Apple has a great track record of containing and even reducing complexity. They have axed features early (e.g., floppy and CD drives, legacy ports) and have introduced new features only reluctantly and when there was a overwhelming case to be made for introducing them (e.g., NFC, bigger screen size). I don’t know what in Apple’s product development process ensures that the complexity-reducing solution is favored, even if it reduces user benefits in the short term, but I admire it.