- App fatigue is a measurable drop in installs and engagement, not a feeling.
- You're fighting for attention, not screen real estate. Pick the surface your user already lives in.
- Use the friction hierarchy and the three-question test before defaulting to an app.
Most "we need an app" briefs are wrong from the first conversation. Not wrong fundamentally, just wrong by default. The team chose an app before they chose a problem. That's the failure mode. App is the answer when the question is "how do we put our product in front of users?" But it's a terrible answer when the question should be "where does our user already pay attention?"
Those are different questions, and the team that picks the wrong one will spend twelve to eighteen months and a six-figure budget shipping something nobody downloads. The pattern plays out the same way every time. The teams that catch it early save twelve to eighteen months and a serious budget line. The teams that don't, find out the hard way. The open record of the industry has paid for these lessons in public.
App fatigue isn't a feeling. It's a metric.
The numbers, roughly. The average smartphone user has about 80 apps installed and opens 9 of them daily. The other 71 are dead weight. Installed once, never opened again. App-store install rates have been flat for three years. The cost of acquiring a paid user via a new install runs $5–20+ in most categories, and that's just to get them to install. Onboarding drop-off after first launch is routinely 40–60%. Day-30 retention on a new consumer app is in the low single digits.
This is what app fatigue means in practice: users have decided they have enough apps. Yours has to displace a daily-opened one to earn a slot. Most don't. Most can't. Most shouldn't even try.
What you're actually fighting for.
The single sentence every product team should write above the whiteboard: you're fighting for attention, not screen real estate. Owning a slot on the home screen is irrelevant if the user never opens it. Owning two minutes of their attention each day, in a surface they already check. That's what wins.
A WhatsApp message opens 98% of the time within five minutes. An SMS, same. An email opens in the high-50s percent if you've earned the inbox. A push notification to your own app opens at maybe 20%, and that's once the user has installed and not muted you. A first-time app launch, after install and onboarding, is 30% on a generous day. The math is brutal: you spent $10 to get the user to install you, and in a good week you'll have their attention twice.
Compare that to a message fired into a surface the user already has open all day. Cost: pennies. Open rate: 98%. Latency: seconds. The product surface was free. The user didn't have to be convinced of anything. They didn't have to download anything. They didn't have to remember you existed.
The friction hierarchy.
Every surface has a friction cost — the effort the user has to spend to engage with you. The higher the friction, the more your product has to be worth before they bother. Ranked, low to high:
Why teams default to apps anyway.
Three reasons, none of them good:
- The deck shows an app. The investor pitch had screenshots in a phone frame. So now you build that. The screenshot drove the design decision retroactively.
- The team can build one. You have engineering. Apps are a known shape of work. WhatsApp Business APIs, Alexa skills, embedded Slack apps: those are unfamiliar. The safer move is to do what you already know how to do, even if it's the wrong shape.
- It feels like the real product. An app on the App Store feels legitimising. A web page feels small. A WhatsApp bot feels temporary. That's emotion, not strategy.
None of those describe a user. The app-by-default decision happens upstream of the customer, in the room where the bet is made. That's the failure mode the CPO Piece is supposed to catch, and the failure mode that a missing or stretched CPO Piece guarantees.
The three-question test.
Before you build an app, three questions. Use them in this order:
- Where does your user already pay attention? Not where they say they would, but where they already do. If the honest answer is "WhatsApp, six hours a day," that's your surface. If it's "iPhone home screen alongside Strava and Citymapper", fine, that's your surface, and you're competing with both.
- What's the cost of getting onto a new surface vs reaching them on an existing one? Include CAC, onboarding drop-off, retention, and the cost of being forgotten. Be honest.
- What's the smallest, sharpest version that proves the value? Often it's an SMS. Sometimes it's a single web page. The MVP isn't an app. The MVP is the smallest surface that proves the bet.
If you can still defend the app after those three questions, fine, build it. Some products do need apps. Real-time tools (Uber). Hardware-paired devices (Tesla, Whoop). Offline-heavy workflows (field-services tools). Deep system integration (camera, sensors, payments at scale). Long-session content (Netflix, Spotify). The native app earns its install when the value can't live on a lighter surface.
Most products don't fit those categories. Most products are pretending they do.
Industry examples, paid for in public.
The canonical case is Quibi. Raised $1.75 billion. Launched April 2020 as a short-form video app, mobile-only by design. Six months later, shut down. Among the public post-mortems: the team built an app that required a fresh download for content nobody had a daily-use case for. Short-form video was already what YouTube and TikTok did, on surfaces users already opened. Quibi tried to win a slot on the home screen and lost. Six months, nearly two billion dollars.
The graveyard of standalone apps from companies that already had user attention is its own genre. Meta's Slingshot, Poke, Riff, Lifestage, Bonfire, Hobbi. Each one a bet that "users will install another thing from us." Each one shut down within months because the right answer was always Messenger, Instagram, or WhatsApp: surfaces the user already had open. The lesson cost Meta hundreds of engineering-years across the decade.
Then the inverse. Companies that recognised the lesson and changed approach:
Domino's publicly diversified from app-only ordering around 2015, launching the AnyWare campaign: ordering via Twitter, Slack, Apple Watch, Alexa, smart TVs, even via a pizza-emoji text message. The strategic call was to meet customers on the surface they already use, regardless of how silly the surface looked in isolation. Domino's reported a sustained shift in digital ordering share and a step-change in customer reach in the years that followed.
UK challenger banks are another case study. Monzo, Revolut and Starling launched mobile-app-only on purpose. It was part of their brand story versus incumbent banks. Within four years, all three added desktop or web banking back. Customers wanted to do bigger tasks (manage statements, do tax work, reconcile transactions seriously) on a larger screen. The app-first religion couldn't survive contact with how customers actually used the product.
Wordle is the inverse-inverse. A single static web page built by one developer for his partner. No app, no account, no install. Acquired by The New York Times in early 2022 for a low-seven-figure sum. Built daily-user retention most apps would commit fraud for, on a surface that took zero install. The lesson everyone took quietly: it's not about the surface, it's about the value the surface delivers per second of user time.
ChatGPT is the most recent. Launched web-only in November 2022. Built over a hundred million users before the native mobile app shipped in mid-2023. The app came after the product was already in daily use elsewhere. The install was the user pulling the product to themselves, not the team pushing it onto a home screen. By the time the app shipped, the question wasn't "will anyone download this". It was "the millions who already use this want it on their phone now."
The pattern across all of these (Quibi's failure, Meta's app graveyard, Domino's AnyWare pivot, the challenger banks adding web back, Wordle's pure-web phenomenon, ChatGPT's web-first rollout) is the same. Default to a new app, fail. Build where the user already lives, win. The brutal install-and-retention math doesn't care about the strength of your idea. The math wins regardless.
Where this lands.
If your team is about to build an app and nobody has asked the surface question, that's a CPO Piece gap, almost certainly. The senior product call is where the surface decision should land, and the surface decision is the most leveraged call in the whole product strategy. Get it wrong by default and you spend a year building the wrong thing well.
Take the Diagnostic if you suspect that's where you are. Or run the three-question test yourself, in the room, before the next sprint plan. If the app still survives, fine, build it. If it doesn't, you just saved twelve months and several hundred grand.
Next issue: N°36, returning to Diagnostics. What forty-seven product function diagnostics actually surface.