What We Learned Reading a Week of In-App Feedback

We set aside time to read every in-app feedback submission that had arrived over a recent stretch — all of it, in one sitting, sorted by hand. No dashboards, no sentiment scoring, no third-party analytics layer skimming for keywords. Just the team, a long table, and a stack of submissions we could mark up in pencil.

The goal wasn’t to respond — we already do that. The goal was to look for patterns. What do users actually ask for, in their own words, when they have an open text box and a moment of frustration or delight? After triaging messages one at a time for a long time, we wanted to see the shape of the whole.

Here’s what the shape looked like.

Why we set aside the time to read it all

Triage-as-you-go misses patterns. When you read one submission at a time, every message feels urgent and individual. Stepping back and reading the whole batch at once is a different exercise — themes emerge that no single message contains. We blocked the time, paused new feature work, and treated the inbox as a single document instead of a stream. The themes didn’t show up until we did.

The other reason was practical. The inbox had been growing faster than the team’s ability to read it without skimming. We weren’t missing anything urgent — the triage flow catches that — but we were missing the quieter signals. The repeated mention of a gauge label that didn’t quite parse. The handful of users asking, in different words, for the same thing. Those signals only show up when you read the corpus, not the items.

The breakdown

Most of what came in were bug reports for issues already on our radar. A meaningful share were feature requests we hadn’t considered. A smaller slice were thank-you notes — unprompted, often paragraph-length. And a few were users simply testing whether the box did anything. Every category mattered, but the proportions surprised us. We expected more bugs, fewer thank-yous, and zero testers.

The test-pings were the biggest surprise. People type “is this on?” or “hello?” into the box and wait. We replied to every one of them with a real, human answer. A few wrote back asking if we were a bot. That confusion is its own data point — users have been so conditioned by feedback forms that vanish into nothing that they’re checking the box before trusting it. We try to earn that trust back one reply at a time.

The patterns nobody talks about

The submissions clustered around moments, not features. People wrote in after a missed regulation update, a confusing icon, a moment of relief when offline maps actually worked. The same map symbol came up again and again. So did one particular gauge label. The pattern isn’t “users want more features.” It’s “users want fewer moments of doubt.” Removing friction beats adding capability, week after week.

Once we saw that pattern, the queue reordered itself. We pulled forward a cluster of small fixes that had been sitting in the consider pile — a clearer legend, a re-labeled toggle, a re-ordered settings menu, a tighter empty state on the regulations screen. None of them were features. All of them were friction. They shipped quickly after the read-through, and the related submissions in the inbox tapered off as they landed.

The journal-style submissions

A good portion of the feature requests read like journal entries. No greeting, no sign-off, no expectation of a reply. Just a sentence: “wish I could see last year’s water temp here.” These users weren’t asking us to do anything. They were writing down what they wanted, and the feedback box happened to be the closest notepad. We started flagging journal-style entries as their own bucket because they’re often the highest-signal requests in the inbox.

The reason they’re high-signal is that the user wasn’t performing. They weren’t framing their idea, justifying it, or selling it to us. They were just naming a gap. When someone takes the time to sell a feature, they often inflate the use case. When someone jots down a one-sentence wish, the use case is exactly what’s on the screen. The journal entries are the closest thing to overhearing a user think.

Bug reports we already knew about (and why that’s good)

The heavy overlap with our known-issues list is a healthy sign. It means users are encountering the same problems we’ve already triaged. If users reported bugs we’d never seen, we’d be flying blind. If they only reported issues we’d never fix, we’d have a values mismatch. The overlap means the inbox and the engineering queue are looking at the same map. We replied to every report, even when the fix was already on its way out.

The replies matter. A user who reports a bug and gets silence assumes they’re shouting into a closet. A user who reports a bug and hears back — even just “we’re on it, here’s the issue, here’s roughly when the fix ships” — assumes they’re being heard. The cost of the reply is a couple of minutes. The cost of the silence is a churn risk we can’t measure but can feel. Every bug report got an answer, and we’ll keep doing that.

Feature requests we hadn’t imagined

The requests we’d never considered are where the inbox earns its keep. One user asked for a way to mark a spot as “already fished today” so they wouldn’t loop back to it. Another asked for a temperature trend arrow instead of the raw number. Neither feature was on any list. Both were obvious in hindsight. Some of the new requests shipped soon after the read-through, more are queued, and the rest sit in the long consider pile — all of it visible in the in-app Development Queue, where users can watch a request move from requested to live.

What’s interesting is the geography of the requests. Users in the Pacific Northwest asked for different things than users in the Mountain West, and Great Lakes users asked for things that surprised both. The inbox is a map of how the app gets used in conditions we don’t get to see. Reading the whole batch at once is the closest we get to standing in every parking lot, river bank, and forest road our users are standing in this season.

Thank-you notes as data

The thank-you notes sound sentimental until you read them. They’re specific. “The new gauge graph saved my Saturday.” “Offline mode held up at altitude with no signal.” “First app that didn’t make me make an account before showing me the map.” Thank-you notes tell you what’s working, which is harder to learn than what’s broken. We started tracking them by feature so we’d know which surfaces to leave alone.

The feature with the most thank-you notes was offline maps. The regulations layer was close behind, followed by the gauge graphs and the no-account-required onboarding. Those are the surfaces we have explicit user permission to stop touching. Designers love to polish. Sometimes the highest-leverage thing is to recognize what’s already working and route the polish energy somewhere else.

How the week changed the inbox going forward

The read-through changed two things. First, we now batch-read the inbox on a regular cadence — not just triage but read, top to bottom, looking for shape. Second, we added a “journal entry” tag during triage so we can surface the quiet, no-response-expected requests separately. They were getting lost in the daily flow, and they shouldn’t be. The inbox is louder when you read it slowly.

A third change followed quickly: we started publishing more of what we ship back to users. The in-app Development Queue had always been there, but after the read-through we made a point of moving items into “shipped” promptly, so users could see their request go from queued to live. The submissions that mention the Queue have gone up since. People check it. People reference it. The loop got shorter without anything else changing.

The other change was attitudinal. After reading a long run of submissions back to back, you stop thinking of users as a category. You start recognizing handwriting — the user who always writes in lowercase, the one who sends bug reports as numbered lists, the one who sends a thank-you every few months when a small thing goes right. Treating those as a dataset feels wrong. They’re correspondence.

We don’t think we’ll learn everything we need from one read-through. The patterns will drift. The proportions will shift as the app changes and as the user base grows. But the practice of stopping work to read what users actually wrote — in their words, without keyword extraction, without trend lines — felt like some of the most important product research we’ve done.

Every submission is a fingerprint of someone using the app. The Development Queue is in-app — Settings → Development Queue — and it’s where the shipped fingerprints live.