Reviews are the roadmap: how we read the App Store and the support inbox

We do not have a roadmap document. We have a weekly habit: read everything users said this week, look at what they did, and decide the next release from that. It is less tidy than a planning meeting and it has produced better products.

What counts as a pattern

One person asking for something is a data point. Three people asking for the same thing, in their own words, without prompting, is a pattern, and patterns go in the next release. The threshold is deliberately low because our apps are young; at a larger scale it would be higher.

Three kinds of signal

• Complaints point at bugs and at promises the store page made that the app did not keep. They are the most urgent and the easiest to fix.
• Requests point at the next feature. Own-voice narration in Dreamify was a request before it was a feature.
• Silence points at features nobody uses. If no review, no message and no usage chart mentions something, it is a candidate for removal.

Reply to everything

Every review gets a reply from the person who owns the app. Not a template. Shoppers read the replies and judge the studio by them. Reviewers update their ratings more often than you would guess when the thing they complained about is fixed and someone tells them.

Data settles arguments

Feedback starts arguments; usage ends them. If reviews say the deck is too long but the data shows people finishing it every morning, the reviews are a minority and the deck stays. If reviews say nothing about the timer but the data shows people leaving the app rather than using it, the timer has a problem nobody wrote down.

What we ignore

Requests that would turn the app into a different app. Feature lists copied from competitors. Anything that fails the five questions we ask before building. The inbox decides what to improve; it does not decide what the product is.