When Marketing Requests a Feature That’s Already Live: A Symptom of Misaligned Communication

The incident that sparked the discussion

A few years ago a senior marketer at a large British retailer pitched a “brilliant idea” – adding Apple Pay to the checkout flow. The proposal cleared the usual approval gates and landed on the desk of Hamish, an IT engineer responsible for the e‑commerce platform. Hamish’s first reaction was disbelief: the checkout already displayed an Apple Pay button when accessed from an iPhone.

He verified the claim in two ways:

1. A quick manual test on the live site showed the Apple Pay widget.
2. He remembered being part of the original rollout that integrated the payment gateway two years earlier.

Despite the evidence, the request moved forward. Hamish consulted the finance team, who confirmed that Apple Pay transactions were already being recorded in the accounting system. The only remaining question was why the marketer could not see the option.

What the evidence tells us

• Feature flagging and device detection – The site used a responsive script that only rendered Apple Pay for Safari on iOS. When the marketer opened the page on an Android phone, the button was hidden, leading her to assume the feature was missing.
• Lack of shared test environments – The marketing team did not have a sandbox that mimicked the production device‑detection logic, so they could not reproduce the experience without an Apple device.
• Documentation drift – The original implementation notes were stored in a legacy Confluence page that had not been updated after a later redesign, meaning newer team members were unaware that Apple Pay was already live.

These facts are not unique to this retailer. A quick scan of recent posts on the r/techsupport subreddit and the Stack Exchange Server Fault tag shows a growing number of “feature already exists” tickets, especially around payment methods, accessibility tweaks, and SEO meta‑tags. The pattern points to a broader communication gap between product‑oriented groups and the engineers who keep the ship afloat.

Counter‑perspectives: Why the request might still have value

1. Validation of the user experience

Even if a feature works, a request can act as an informal audit. The marketer’s inability to see Apple Pay on Android highlighted a blind spot: the checkout experience was not consistent across devices. A short usability study could have surfaced the same insight without the extra ticket, but the request forced the team to document the behavior.

2. Opportunity for metrics and A/B testing

When a feature is presumed missing, teams sometimes add instrumentation to confirm adoption rates. Hamish’s investigation could have been leveraged to add a tiny analytics snippet that reports the percentage of visitors who see Apple Pay, giving the business a data‑driven argument for promotional spend.

3. Cultural reinforcement of “ownership”

From a management standpoint, allowing the marketer to raise the request and seeing it closed quickly demonstrates responsiveness. It reinforces a culture where non‑technical stakeholders feel heard, even if the outcome is “nothing to do.” That feeling can be as valuable as the actual work.

Lessons for both sides of the aisle

Marketing / Product	IT / Engineering
Keep a public feature matrix that lists enabled payment methods, supported browsers, and any device‑specific logic.	Provide self‑service test pages that surface the same conditional UI elements without needing a full‑stack deployment.
Use feature flags with clear naming conventions (e.g., payment.apple.enabled) that can be queried via a simple API or dashboard.	Document feature‑toggle states in the same source of truth used for CI/CD pipelines, so the status is never “unknown.”
Conduct cross‑functional demos after major releases, inviting marketing, finance, and support to verify the end‑to‑end flow.	Automate device‑coverage tests with tools like BrowserStack or Sauce Labs, and publish the results in a shared report.

When “the work is already done” becomes a problem

The underlying frustration Hamish expressed – “we could have scored bonus points for a speedy delivery” – reflects a deeper issue: credit is often tied to visible effort rather than outcome. In environments where ticket counts drive performance metrics, engineers may feel compelled to “re‑do” work just to log activity.

A healthier approach is to recognize closure as a legitimate contribution. Closing a ticket with a concise “feature already live, see documentation X” should carry the same weight as delivering new code, especially when the closure prevents duplicated effort.

Closing thoughts

The Apple Pay episode is a micro‑example of a recurring theme: marketing and product teams sometimes request work that already exists, not out of negligence but because the visibility of that work is fragmented. By tightening documentation, providing shared test environments, and treating verification as a first‑class activity, organizations can reduce the noise of redundant tickets while still honoring the collaborative spirit that drives ideas forward.

If you’ve ever been asked to “fix” something that was already functioning, share your story with the On Call column. The conversation is only as useful as the anecdotes it collects.