Apple's native apps are missing something obvious. So is your product roadmap.
- Michael Amenta
- Jun 16
- 4 min read
Updated: Jun 17
Why is it that it took eleven years for the best-funded technology company in the world to allow an iMessage to be marked unread?
Why are local holidays still not integrated into Apple's native Clock app so we can sleep in bliss for nine precious days per year? Enhancements like these are small to develop, have obvious value, and have been raised in customer forums for years.
Maybe Apple feels that quality-of-life investments in native apps have nothing to do with their ability to sell iPhones (especially as compared to the enormous psychological moat they've dug in the form of the color of speech bubbles). But to posit another theory, Clock and Messages have no integrated feedback loops. As native apps, they come pre-loaded and have no review mechanism within the App Store. There also isn’t a built-in feedback channel, which some apps include in their experience.
The consequence is clear. Without a healthy customer feedback pipeline, well-funded teams on the largest revenue-producing product at one of the world’s most valuable companies have little incentive to make small and obvious improvements.
Problems that aren't measured are problems that don't exist on anyone's roadmap.
Know what you don't know
I’ve noticed a pernicious fallacy in product manager behavior: PMs often feel that, if a problem within their product exists, they’ll know about it. In reality, friction prevents reporting. If feedback isn't delightful and easy to submit, most users won’t do it. Qualtrics found that only 29% of customers communicate directly with organizations after bad experiences, which is down 7.5 points in four years. Instead, they quietly resent your product. Churn will increase and word-of-mouth referrals will decline without an understanding of why the product isn’t growing as fast.
How can a PM prevent this? It's unglamorous work, but 5-10% of a PM's time should be dedicated to customer support and/or real product usage. This is what Teresa Torres calls continuous discovery: the discipline of building customer feedback into the daily rhythm of product work rather than treating it as a periodic event.
In a B2C product line, one can sit directly in their customer's shoes. For example, Uber's CPO, Sachin Kansal, drives for Uber and Uber Eats every month, in a process he calls "extreme dogfooding". Outside of B2C, the provision of regular customer support is essential. Even though call centers, bots, and AI can provide support more cheaply, the point isn't the cost — it's the assurance of quality.
Drive impactful change with internal SLAs
In my first product role, I managed a data aggregation service that experienced frequent and passionate complaints from customers that were often escalated to executives. But the problem wasn't in our power to solve: it was simply "garbage in, garbage out". When one obscure company in a group of 3,000 had a bad revenue conversion rate, every industry, country, and custom group containing this company had obviously bad data for all revenue metrics.
However, customer complaints went to the aggregates team where it was exposed, not to the owners of the company data product that was making the errors — because no one was individually analyzing the obscure company. I complained to the customer data team, but we weren't their paying customers, so they didn't prioritize us. The problem was the absence of a feedback loop from real problems to those who could resolve them.
So we created one. We used our aggregations engine to parse company data for outliers among both peer groups and time series within the same company. Then, we wrote a program that automatically generated bug reports to the appropriate team. Because these bug reports were automated, large in volume, and visible in publicized quality reports, the company data team jumped into action. Overnight, our quality problems were gone—the "Bug Zapper 3000" created a feedback loop that caused my team's product support costs to plummet.
Later, we repeated the process on a data delivery team where our customers furiously complained about the underlying data that we didn't produce and couldn't control. So we again created a feedback loop. We negotiated an SLA with customers that connected our data team to the end users via a KPI associated with the customer's quality standards.
All of this can be avoided with better organizational design. Amazon's API mandate and follow-up frameworks, including IT showbacks and Team Topologies by Matthew Skelton and Manuel Pais, design organizations so that internal platform teams act as formal service providers to internal customers. These solutions are what Rohan Mahtani refers to when he says that 'incentives beat instructions, every time'. The instruction to improve quality almost always exists, but the incentive structure often points elsewhere until a feedback loop changes it.
Infrastructure that makes problems impossible to ignore
Waiting for complaints assures that you'll miss important areas for impact. So the best PMs build more than products; they build the organizational infrastructure that makes problems impossible to ignore.
Apple's native apps are recognizable examples of this issue, but the same invisible gap exists in almost every product. The difference between teams that find it and teams that don't is customer sightlines.
Build a feedback loop and problems will announce themselves. Don't build it and they'll stay invisible until your users quietly leave for someone who did.