What We Learned from Our First 13 Feedback Submissions

Thirteen pieces of feedback doesn't sound like a lot. In traditional product research, you'd barely clear the warm-up phase. But when each submission is structured — role, recurring problem, current workaround, frequency, desired outcome — thirteen turns out to be surprisingly rich.

Here's what we've seen so far, what surprised us, and how it's already changing what we build.

Pattern #1: The workaround field is the most valuable

We ask people to describe their current workaround, and this field consistently delivers the sharpest insights. When someone says "I export to a spreadsheet and manually tag each entry," that tells us more about the real problem than any feature request ever could.

Workarounds reveal the shape of the pain. They show you what people have already tried, what they're willing to tolerate, and where the friction is highest. If five people describe similar workarounds, you're looking at a real opportunity — not a hypothetical one. The examples in Customer Feedback Examples show why the raw wording matters so much.

Pattern #2: Frequency matters more than severity

Some of the most emotionally charged feedback described problems that happen once or twice a year. Important? Maybe. But the problems people described as "daily" or "weekly" — even when the language was calmer — are the ones that compound into genuine dissatisfaction.

This confirmed something we suspected: frequency should carry more weight in our triage system than raw severity alone. A moderate problem that happens every day causes more cumulative damage than a severe problem that surfaces quarterly. That logic now feeds directly into the scoring model we describe in From Feedback to Triage, and into the scorecard we use to compare signals consistently.

Pattern #3: People want to see what happens next

Multiple submissions mentioned wanting visibility into how their feedback is being used. Not just "thanks, we'll consider it" — but actual evidence that their input changed something. This was the single clearest signal in our early data, and it's why we made the public dashboard a priority.

The desire for feedback loops is almost universal. People will invest time in giving you good input if they believe it matters. The moment they suspect it's going into a void, they stop. That's one reason building in public is a structural choice for us, not just a tone choice.

What surprised us

The specificity. We expected vague feature requests — "make it faster," "add integrations." Instead, we got detailed descriptions of workflows, pain points with timestamps, and concrete scenarios. Structured intake works. When you ask the right questions, people give you signal instead of noise.

We were also surprised by the role diversity. Product managers, customer success leads, founders, and individual contributors all showed up in the first thirteen. Each group described similar problems from different angles, which made clustering much more productive than we expected.

What this means for the roadmap

Three immediate changes came out of these thirteen submissions:

First, we accelerated the public dashboard to give contributors visibility into how feedback flows through our system. Second, we added frequency as a weighted factor in our triage scoring. Third, we started building the clustering view that groups related problems together. We also realized the incentive layer described in the engagement credit system mattered more than we expected because better contributors improve the quality of the whole dataset.

None of these were on our original timeline. All of them came directly from the first batch of real customer input. That's exactly how this is supposed to work.

If you haven't submitted feedback yet, now's a good time. The roadmap is still forming, and early voices carry disproportionate weight. If you want the same structure we use internally, start with the Product Evidence Kit.