Why we built comment threads into Shpd
Last March, a studio with eight iOS apps emailed us. Their highest-voted feature had 340 votes. But nobody knew why. Was it a pain point? A nice-to-have? A misunderstanding of the actual problem? They'd shipped something similar six months earlier and it went unused. We realised we'd built half a product.
Votes without context are just noise
Feature voting is seductive in its simplicity. You ask users what they want. They vote. You ship the top five. Done. Except it never works that way in practice. A number tells you demand exists. It doesn't tell you if the demand is real or imagined. It doesn't tell you if ten power users are voting repeatedly while 330 others glanced at a title and clicked.When we launched Shpd, we had the voting board. Clean, indexed for search, visual. It felt complete. But our first customers kept asking the same question: can your users see why someone voted for this feature? Can they add context? Can they say, I need this because my workflow breaks when I try to batch-export?
That's when it hit us. We'd built a megaphone, not a conversation. And conversations are where product decisions actually happen.
The moment we understood what was missing
One of our Studio customers, a team managing five apps in the fitness space, told us they'd shipped a feature that polled at 280 votes. Three weeks after launch, they realised voters wanted something different. The votes weren't for the thing itself; they were for a solution to an underlying problem. Two-thirds of the comments (which they were handling in Slack, not in Shpd) revealed they wanted synchronisation across devices, not the specific UI pattern the team had built.They'd wasted a sprint. And we'd wasted it with them, by not giving them a place to ask and answer follow-up questions inside the product itself.
That conversation should have happened where the vote was cast. It should have been indexed, searchable, and visible to every voter in the portfolio. It should have told the studio exactly what problem they were solving before code was written.
Comments threads as due diligence
We built comment threads into Shpd because feature validation isn't democratic; it's investigative. A studio's job is to work backwards from a vote to the actual customer need. Comments let you do that inside the platform.When a voter leaves a comment on a feature request in Shpd, every other voter sees it instantly. If someone says, I need this for enterprise workflows, that reframes how the studio reads the vote count. If someone replies, Actually, I just want the basic version first, that's directional too. The feature request becomes what it should be: a forum where the studio gathers evidence, not a popularity contest.
We indexed comment threads so they'd be discoverable in search. If your user base is debating whether they want offline mode or sync mode, that conversation should live somewhere Google can find it. It should be part of your public roadmap narrative. Potential customers scrolling your feature board should be able to see how thoughtfully you listen.
Threading in a cross-app world
This became especially important once we shipped Passport, our cross-app voter identity system. Passport lets someone vote across your entire portfolio with a single identity. That means a voter might comment on a feature in one app and then reference their experience in another.A single user might vote for offline messaging in app A and then comment on a related feature in app B with context that only makes sense if you know they voted in both places. Comment threads let you see that conversation as one coherent thread, not fragmented across separate tools.
We could have kept comments siloed per app. It would have been simpler. But studios with portfolios need to see patterns across apps. Comments are where those patterns emerge.
What we learned from shipping it
Once comment threads went live in Shpd, something shifted. Studios started asking better questions of their voters. They stopped treating vote counts as gospel and started treating them as prompts. One multi-app studio told us they'd cut their feature validation time in half because they no longer had to jump between Discord, Slack, and email to understand what a vote really meant.The other thing we noticed: studios started shipping features faster. Not because they were building more, but because they were building the right thing on the first attempt. Comment threads don't just gather feedback; they compress the feedback loop. A question asked and answered in the same place the vote lives doesn't need to be repeated in six other channels.
It's also where you catch the ideas that shouldn't ship. A comment thread that starts with 40 votes and evolves into a debate about whether the request was even well-understood is valuable in a different way. It tells you to ask more questions before committing resources.
Feature voting without conversation is just a popularity poll. What changes your roadmap isn't the number next to a request; it's understanding what the number actually means. When was the last time a vote count told you something that a comment couldn't have told you better?