ASO Is Product Work, Not Marketing — A Developer's Case

In most teams, App Store Optimization lands on whoever owns "marketing." The keywords get handed to a growth contractor, the screenshots go to a designer, and the developers go back to building features. I want to argue that this org chart is backwards. ASO is not a marketing channel you bolt on after the app is built. It is product work, and treating it as anything else leaves compounding growth on the table.

I've shipped and iterated on enough store listings to have changed my mind about this. Here's the case.

The store listing is your first feature

Before a user taps a single button in your app, they interact with a product surface you built: the icon, the title, the screenshots, the first three lines of the description. That surface has a conversion rate. It has a funnel. It responds to iteration. By every definition we apply to in-app screens, the store listing is a screen — it's just the one that runs before install.

When a designer treats the onboarding flow as product work but the store listing as "marketing assets," they're drawing a line that the user doesn't experience. To the user it's one continuous journey: search result → listing → install → onboarding → aha moment. Optimizing four of those five steps and outsourcing the middle one is a strange way to build a product.

Keywords are user research in disguise

Here's what changed my thinking most. Keyword research is usually framed as a marketing tactic — find high-volume, low-competition terms, stuff them in the metadata. But look at what a keyword actually is: the exact language a user typed when they had the problem your app solves. That is the purest user research you will ever get. It's unprompted, it's at the moment of intent, and there's a lot of it.

If your app is a habit tracker and the data shows people searching "stop doom scrolling" far more than "habit tracker," that is not a metadata insight. That's a positioning insight. It tells you what job users are hiring your app for, in their words. A marketing team will use it to rank. A product team will use it to rename features, rewrite onboarding copy, and maybe reprioritize the roadmap. The second team wins.

Retention and ranking are the same signal

The old model of ASO was mechanical: right keywords in the right fields, watch the rank. That model is mostly dead. Modern store algorithms lean heavily on behavioral signals — install-to-open rate, day-1 and day-7 retention, session frequency, uninstall rate. The store is asking, in effect, "when we send someone this app, are they happy a week later?"

Sit with what that means. You cannot optimize your ranking without optimizing your retention. The single highest-leverage ASO move available to most apps is not a keyword change — it's fixing the day-1 drop-off. And fixing day-1 drop-off is, unambiguously, product work: onboarding, activation, the first-run experience, the moment the user first gets value. The store now rewards the same thing your PM already wanted. ASO and product strategy have collapsed into the same activity, and a lot of teams haven't noticed.

What this looks like in practice

If you accept that ASO is product work, a few things change about how you operate:

• Developers read reviews. Not because it's their job to reply, but because one-star reviews are bug reports and feature requests with a distribution penalty attached. A review that says "crashes when I add a photo" is telling you about a bug and dragging your rating and suppressing your rank. Three problems, one root cause, and it's engineering's to fix.
• Screenshots get versioned like features. You A/B test them, you write them down, you attribute conversion changes to specific edits. "We changed screenshot 2 and install rate moved 4%" is a product experiment, and it should live in the same place as your other experiments.
• The listing ships with the release. New feature that changes what the app is for? The store listing changes in the same cycle, because the listing is part of the product's story, not an afterthought handled two sprints later.

The counterargument, fairly stated

The honest objection: ASO involves real marketing craft — competitive keyword strategy, paid UA interplay, seasonal timing, localization economics. A senior developer is not automatically good at any of that, and pretending the marketing discipline doesn't exist would be its own mistake. That's true. The claim isn't that developers should own every part of ASO or that specialist skill doesn't matter. It's narrower: the parts of ASO that move the needle most — retention, positioning, the listing-to-onboarding continuity — are product decisions, and they suffer when they're treated as someone else's post-launch cleanup. Keep the specialists. Just stop drawing the org-chart line in a place the user never feels.

The reframe

Try this the next time you plan a release. Instead of "we'll build the feature, then hand it to growth for ASO," ask: what does this feature change about who searches for us, what they expect, and whether they'll still be here in a week? Answer those in the same room where you decide what to build. That's not marketing borrowing your engineers. That's product finally including the surface that runs before install.

The apps that compound aren't the ones with the cleverest keyword stuffing. They're the ones that treated the entire journey — search to aha — as one product, owned by the people who build the product.