The dashboard that made sense of what our users actually wanted

Starting with the problem, not the dashboard

Most product feedback tools give you a spreadsheet. Rows of votes. Maybe a pie chart. Useful if you're managing one app. Useless if you're running five, or ten, or thirty.

When we started Shpd, we knew our users would be like that Berlin founder: juggling multiple iOS and Android apps, each with its own voter base, each sending signals about what to build next. The problem wasn't collecting votes. The problem was seeing patterns across the whole portfolio.

So we didn't design a dashboard first. We watched a few founders work. We asked what questions they asked themselves every Monday morning. 'Which features are gaining momentum?' 'Where are my voters most engaged?' 'Do I have a feature request that's popular in one app but buried in another?' Those questions shaped what we built.

Breaking down what the dashboard actually shows you

The dashboard has four main views. The first is portfolio momentum. You're looking at a timeline of all feature requests across your apps, ranked by votes and engagement over the last seven days, thirty days, or custom range. You see which requests are trending, which are stalling, which got a surge of activity overnight. More importantly, you see it cross-app. A feature request for 'dark mode' might have fifty votes in one app and thirty in another. The dashboard shows you both, together, so you're not blind to the demand signal spreading across your portfolio.

The second view is per-app analytics. Drill into any single app. See voter demographics (when they joined, how active they are), feature request performance (comments per request, votes per day), and a heatmap of which categories are getting the most attention. This is where you spot if one of your apps is being starved of feature feedback. Maybe your newer app isn't getting the attention it deserves, or one has become a feedback magnet.

The third is voter behavior. This one's honest about engagement. You can see how many voters have voted once and never returned, how many are serial voters, what the average comment depth is. One founder told us this view alone changed how she communicated with her community. She realised most voters were lurkers, not commenters, so she stopped worrying about thin comment threads and started paying attention to vote volume instead.

The fourth is the shipping impact tracker. When you mark a feature as shipped in Shpd, we send a push notification to every voter who voted for it. The dashboard shows you exactly how many got the notification, how many opened it, and which shipped features drove the most follow-up engagement. This matters because it closes the loop. Your voters see their influence. You see that shipping features keeps people coming back.

The number that kept us honest

During our first month, a customer asked if we had retention data. 'Do voters come back after their feature ships?' That's a different question from 'Do voters vote?' We didn't have an answer. So we added a retention overlay (available in our Portfolio plan with Attribr integration) that shows you, for each shipped feature, whether the voters who asked for it are still active in your apps. It's brutal data sometimes. A feature you shipped that you thought would keep people engaged doesn't. A minor feature you shipped on a whim brought back lapsed users. The dashboard showed us that our own assumptions about what matters to voters were often wrong. We'd bet money on what would resonate, ship it, then watch the data tell a different story. That's what a good dashboard should do. It should surprise you, not confirm what you already think.

Why we didn't add a predictive layer (yet)

We get asked a lot if the dashboard predicts which features you should build next. We don't do that. We deliberately don't. Here's why: prediction works only if you're comfortable outsourcing your judgment. For a studio running multiple apps, serving different audiences, dealing with technical debt, partner demands, and competitive pressure, that's a bad trade. What we do instead is give you the data in a shape you can actually think about. Comments grouped by theme. Voters segmented by engagement level. Timeline views that show you if a request is gaining or losing momentum. A founder who spends an hour in the dashboard every month knows their users better than any algorithm could tell them.

One exception: we added an AI insights digest for Portfolio plan users. It's not a prediction engine. It's a weekly email that highlights emerging request themes, unusual voter behaviour, or cross-app patterns you might have missed. It's like having a junior analyst who reads all your feature requests and tells you what stood out. The difference is it doesn't decide for you. You still do.

The moment it clicked

Last month, a founder from a five-app studio called our support line almost hyper. She said, 'I just saved a year of build time.' What happened? She was looking at the portfolio momentum view and realised a feature she was about to start building had already dropped fifty places in the rankings because voters moved on to something else. Six months ago, she wouldn't have seen that pattern. She would have followed her roadmap, built it anyway, shipped it to silence. Instead, the dashboard showed her the signal. She pivoted. Built the thing voters were actually asking for now.

That conversation told me we'd built something that earned its place on a founder's screen. Not because it's pretty. Not because it gamifies feedback. Because it answers the question studios actually need answered: 'What do my users want, and is it changing?'