Why 99% of apps fail — and how to be the 1% that doesn’t
This post is from my recent webinar with FlutterFlow. You can watch the entire webinar here →
Note: this post was generated from the webinar using AI. I’ve manually edited it for context and added the graphics/illustrations.
Everyone has an opinion about what you should build next. Your loudest user. Your investor. The founder in the room. You.
Your data has an opinion too. Most teams never ask it.
I ran a FlutterFlow workshop last week on the decision loop we use at Flywheel when a product is live, the backlog is infinite, and “add a feature” is the default answer to every stalled metric.
That default is usually wrong.
The 80% problem
Pendo analyzed 615 software products in 2019. Eighty percent of features were rarely or never used.
That number should sit on the wall next to every product board.
When usage, retention, or revenue stalls (insert any KPI failure here), most teams assume the product is missing something. So they ship the next thing. Then the next. Then they wonder why the graph doesn’t move.
The missing piece is rarely another feature. It is a process for knowing which work will land in the 20% people actually use.
The best products are not built on luck, gut, or vibes. They are built through science.
The loop we use has four phases:
KNOW → DECIDE → SHIP → VALIDATE → back to KNOW.
If you skip Validate, you don’t have a loop. You have a line:
Guess → Build → Ship → Hope.
That line is how you produce the 80%.
KNOW: measure what predicts success
Most dashboards stop at the easy numbers: downloads, signups, DAU, MAU, revenue, uninstalls. Those tell you the app exists. They do not tell you it is working.
Note: this is the number one problem I see in new and inexperienced product teams. They’re looking at the wrong numbers.
What you want is an activation event: the one behavior, performed within X days, that predicts whether someone sticks around.
Facebook’s growth team did not invent “7 friends in 10 days.” They ran the regression. Of everyone who retained, what did they do that churned users didn’t? Add seven friends in the first ten days. Chamath, then head of growth, said the team “talked about nothing else.”
Slack’s version: 2,000 messages in a workspace. Below that, almost nobody stays a year. Above it, most do.
Once you have that number, product work gets simpler. You design the first session around reaching it. You stop polishing photo albums when the job is “help this person find seven friends.”
If you cannot name the activation event in one sentence, you do not have one.
The second half of KNOW is segmentation. Spotify does not measure “average user retention.” A 25-year-old hip-hop listener who joined via invite is a different KPI than a 45-year-old podcast listener who only opens the app in the car. Wrapped is the public face of that infrastructure.
Superhuman had high churn until they looked at who was leaving. People who barely send email. The people who live in inbox — founders, execs — loved it. They stopped trying to build email for everyone and designed for high-volume senders.
A “healthy” 30% retention number often hides 80% who churn and 20% who love it. The average user does not exist. Stop optimizing for them.
Write down two things:
- What behavior in your app, within X days, predicts someone stays?
- Which segment do you actually want to keep — and what does their retention curve look like, separately?
DECIDE: the user’s voice, then a criterion
Founders are strong-willed. Useful, until it becomes a substitute for watching someone use the product.
App Store reviews and support tickets are biased toward the loudest and angriest. They never tell you what quietly satisfied users love, or why quietly churning users left.
Duolingo does not “do research when there’s a question.” Interviews, in-app capture, surveys, and behavioral signals from their bandit algorithms run at the same time. Research is plumbing, not a project. That is how you catch the gap between what people say they want and what they do.
A standing cadence of three interviews a month changes more products than another quarter of guessing. A power-user panel you can tap on demand is even better.
Then prioritize against a metric gap, not affection.
Burbn was check-ins, photos, plans, points, badges. Systrom and Krieger looked at the data. Users ignored everything except photos. They did not add features. They deleted 90% of the product: take a photo, apply a filter, share. That decision — from data, not affection — was Instagram.
The Pendo 80% is what happens to companies that do not cut.
Good looks like:
- Every backlog item has an explicit metric gap attached
- Expected impact estimated before you build
- A shared framework (RICE, ICE, or a simple impact × complexity matrix)
Start with high-impact, low-complexity. Kill high-complexity, low-impact. If you cannot say how you would prove the value, that is a signal.
Write down the last three things you shipped. What specific metric was each supposed to move? If you cannot answer, you are flying blind.
SHIP: release without blowing yourself up
Pokémon Go launched worldwide on day one. Servers melted in hours. The fix was not “more servers.” It was phased rollout: region by region, capacity tested against real load before expanding.
Most teams still do: build → test internally → push to 100%. Every ship is a bet. If a feature breaks, your options are roll back the entire release or eat it. The cost of being wrong is the cost for everyone.
Mature mobile teams separate deploy from release.
- Feature flags: code in production, exposure controlled
- App Store phased rollout (roughly 1% → 2% → 5% → 10% → 25% → 50% → 100% over a week)
- Metric-gated: if KPIs dip, the rollout stops itself
- Power users first — they are more tolerant, they will tell you the truth, and they already care
Do not ship a non-hotfix at midnight Friday if nobody is watching the weekend. Manual or phased beats automatic for anything that is not an emergency.
The test is specific: if you noticed a bad release tomorrow at 5 p.m., how would you stop it? If the answer is “wait for store review,” the release process is incomplete.
Monitoring is the other half. If users are the ones telling you the app is broken, you are already losing. By the time someone writes a one-star review, ten more silently uninstalled.
Crashlytics, Sentry, performance traces, key-flow alerts routed to a named person — that is the floor. Cost: an afternoon. Upside: stop running on luck.
Write down: how would you have heard about your last bug if no user had complained?
VALIDATE: close the loop or it is not a loop
This is the step almost nobody runs.
Before you ship, write the hypothesis: If we do X, metric Y moves by Z, and we look on date D.
Duolingo noticed that users who hit a 10-day streak were dramatically less likely to churn. Hypothesis: a notification when the streak is about to die will lift retention. They defined success up front. Result: +0.5% DAU, +2% new-user retention. Flat would have been a kill. Because success was declared before, not rationalized after.
If you launch seven features at once, you cannot attribute anything. You learn nothing. The next backlog item is another guess.
Review at two weeks and six weeks against the prediction. The window depends on volume and the metric. A home-screen change with a thousand daily users can show in two weeks. A 10-day streak mechanic needs longer — in the first fortnight you only get a few overlapping cycles.
Then decide: iterate, expand, or kill. Failed increments are data. Duolingo made it almost impossible to permanently lose a streak (freeze, restore) because they learned the streak itself was the activation event. Protecting it mattered more than purity.
A/B tests are how you keep a control group. Booking.com runs more than a thousand concurrent experiments. About 90% fail. That is not incompetence. Their bar for “keep it” is high. Their ex-design director: “If it can be a test, test it. If we can’t test it, we probably don’t do it.”
Duolingo’s bandit picks the best push per user. Same principle.
You do not need Booking’s infrastructure to start. Testing should become the default verb for shipping — especially on the three highest-leverage, lowest-complexity surfaces for most apps:
- Onboarding
- Pricing
- Push / re-engagement
In that order. Those three beat most “big new features” while you are still a funnel, not a loop. We covered the funnel version in the previous workshop. Most early apps still are funnels. Fix the top before you romanticize virality.
Write down, for the next thing you ship: the exact metric, the exact lift, the exact review date. Then write one A/B test you could run this quarter on onboarding, pricing, or push.
How to use this this week
Do not install the entire loop on Monday.
Grade the app honestly — today, not aspirationally. If you are between two answers, pick the lower one. We built an 8-question maturity index for this: flywheel.so/resources/tools/mobile-product-maturity-grader. It returns a phase breakdown, your three weakest dimensions, one highest-leverage move, and a tier: Reactive, Informed, Proactive, or Systematic.
Then:
- Find the gap with the most leverage, not the one that bothers you most.
- Put one move on the roadmap with a date. One real change beats ten aspirational ones.
- Re-grade next quarter. When you close one gap, the next becomes obvious. That is the loop running.
The unevenness of your profile is the diagnostic. Most teams are a tier lower than they thought in one specific place.
The loop is the product. Features are experiments inside it.
If you want help closing the weakest dimension, we will walk it with you for 30 minutes. No pitch. flywheel.so · hello@flywheel.so
The workshop recording is on FlutterFlow’s YouTube.
Build less. Measure the 20%. Repeat.
