The Android Blindspot: When Marketing Demands a Feature the Site Already Has
Table of Contents
The Request That Didn’t Make Sense
In the high-pressure environment of retail e-commerce, the friction between marketing departments and IT teams is a well-documented phenomenon. Usually, this tension manifests as a clash between ambitious deadlines and technical constraints. However, a recent account from a developer—who we will call Hamish—highlights a different, more absurd kind of friction: the complete lack of awareness regarding a product’s own existing capabilities.
While working for a major British retailer, Hamish found himself on the receiving end of a high-priority directive. The company’s website manager, a key member of the marketing team, had proposed a “brilliant” strategic move to boost conversion rates and increase sales: the integration of Apple Pay into the checkout process. Management, seeing the logic in reducing friction for iOS users, approved the initiative immediately, and the task landed on Hamish’s desk as an urgent requirement.
There was only one problem. The website already offered Apple Pay.
Verifying the Obvious
For any developer, receiving a ticket to build a feature that already exists is a confusing moment. Hamish first attempted to verify the site’s current state by simply visiting the storefront. The Apple Pay option was there, plain as day. More importantly, Hamish had personal history with the feature; he had been part of the original engineering push to enable the payment method and vividly remembered the deployment process.
To ensure he wasn’t missing a critical bug or a regional outage, Hamish didn’t just rely on his own browser. He coordinated with the IT department and the finance team to confirm that the payment gateway was not only active but successfully processing transactions. The money was flowing into the company’s coffers via Apple’s ecosystem, confirming that the feature was fully operational and stable.
This left only one question: why did the person in charge of the website believe the feature was missing?
The Android Revelation
When Hamish approached the website manager to clarify the request, the manager remained insistent. She claimed that Apple Pay was nowhere to be found during her audits of the site. To prove her point, she pulled out her device to show him the checkout screen.
The device in her hand was an Android phone.
The company’s website had been built with a standard, dynamic payment logic: it detected the user’s device and operating system in real-time, presenting only the payment options relevant to that specific hardware. Because the manager was browsing on Android, the site correctly hid the Apple Pay button to avoid user confusion—precisely how the system was designed to work. Yet, because she was the only one testing the site on a non-Apple device, she concluded the feature was entirely absent.
The Cost of Corporate Silos
The incident serves as a stark example of “device bias” and the dangers of narrow testing parameters within corporate environments. When senior decision-makers rely on a single device for quality assurance, they risk making strategic decisions based on an incomplete picture of the user experience.
In the aftermath, Hamish reflected on the political handling of the situation. While he chose to use the moment as a teaching opportunity to highlight the disconnect between senior management and the technical reality of the platform, he wondered if a more “strategic” approach would have been better. In many corporate cultures, the most effective way to gain visibility is to “fix” a problem that didn’t exist, reporting a speedy resolution to a crisis that was entirely imaginary.
Instead, the IT team opted for transparency, revealing the gap in the marketing team’s understanding of their own digital storefront. It was a victory for truth, if not necessarily for the IT team’s internal optics.
