When a feature request comes from someone who's about to leave
Last month, a studio lead messaged us: 'I just watched a user request dark mode, then disappear from the app entirely three days later.' She wasn't asking for a feature. She was asking why the data hadn't told her sooner.
The moment we knew retention and feature votes had to talk to each other
Feature voting tools show you what users want. Retention data shows you who's staying. Most teams treat these as separate conversations. You get votes on your roadmap, and churn numbers on a spreadsheet, and you never connect the two.
We started asking studio leads: 'When someone votes for a feature and then stops using the app, do you know?' Most answers were some version of 'not really.' One founder told us he'd spent three months building a heavily requested feature, shipped it, and watched his retention actually drop. Turned out the people asking for it had already left.
That conversation changed what we built for Portfolio members. Not a magic churn predictor. Just a simple, honest overlay: Attribr retention status attached to each feature request. Who voted. Whether they're still active. Who left in the past week, the past month.
What you actually see when you open the voting board now
You log into your Shpd dashboard, pull up a feature request with, say, 147 votes. You scan the voter list. Some names have a green dot. Some are greyed out. Attribr tells you who's churned. Not predictively. Just factually, tied to your actual in-app activity.
This matters because it flips your prioritisation logic. A feature with 50 votes from active users, right now, becomes more valuable than a feature with 100 votes where half the voters quit last month. You're not guessing whether those votes still represent real demand. You're seeing it.
One studio built a notification preferences panel because Attribr showed 34 votes for 'notification control,' but 18 of those voters were already gone. They shipped it anyway for the 16 still active. Retention on those 16 went up 12%. The off-target votes had been noise.
The uncomfortable conversations it forces you to have
Here's the thing nobody says out loud: retention data can make you look bad. If your most requested feature correlates with users leaving, that's a problem. If your roadmap is full of votes from people who've already churned, your prioritisation process might be broken.
We've had founders stare at their Attribr overlay and realize: 'We've been building for ghosts.' Not maliciously. They just didn't have the data to see it.
The overlay doesn't solve that. It just makes you see it. And seeing it is where the work starts. You can then ask proper questions. Is this feature unpopular because it doesn't solve the real problem? Are the people voting for it using the app differently than your core base? Is there a segment churning that we're not paying attention to?
Some studios have stopped building the 'most voted' features entirely after seeing Attribr data. Others doubled down on those features because they realised the voters who mattered most wanted them. Both responses are better than the blind one.
Why this lives in Portfolio and not Studio
Attribr overlay is available to Portfolio members (£99 per month). That's not a gatekeep. It's a honesty call. You need to be at the scale where cross-app voter identity matters and where retention analytics are already part of your product conversation. Studio members (£19 per month) are often single-team shops. They don't need this yet.
Portfolio teams typically run 10 to 30 apps. They have serious retention curves. They have enough volume that Attribr data is statistically meaningful. They're also the teams most likely to be fleeing Canny's price shift and coming to Shpd. For them, this overlay is part of the reason.
What it doesn't do (and why that matters)
Attribr doesn't predict who will churn next. It doesn't explain why people left. It doesn't recommend which features you should build. Those are tempting moves; they'd feel powerful. But they're also where retention data gets misused.
What Attribr does: it connects two data sets that should never have been separated. It makes the honesty visible. A founder in a portfolio with five apps can now see, in real time, whether the features people are asking for come from people still using the app.
The intelligence is yours to build on top of that. And that's the only way to do it well.
If your studio is managing multiple apps and you've never cross-checked your feature requests against who actually stayed, does that surprise you more, or does it answer questions you've been asking?