Saved posts was the single most-requested feature for a long stretch. People asked for it constantly, I shipped it, and I was genuinely glad to finally have an answer for “how do I come back to this later.” A few weeks in, the honest number is in, and it’s not flattering: almost nobody goes back and actually looks at what they saved. Including me.
What I Expected vs. What Actually Happened
I expected saved posts to function like a reading list — you save something because you don’t have time right now, and you come back to it later when you do. That’s not what’s happening. People save at a healthy rate. The return-and-view rate on saved items is low, and it’s been low consistently enough that it’s clearly not a rollout problem or an awareness problem. It’s a behavior problem, and it’s worth being honest about instead of just quietly shipping the feature and moving on.
Why This Isn’t Actually Surprising, in Hindsight
The save action captures a specific moment — you’re scrolling, something looks interesting, and saving costs nothing, so you do it. That moment passes. The version of you that opens the saved list later isn’t in the same scrolling headspace, doesn’t have the same context for why that post mattered, and is starting from a flat list with none of the momentum that made the original post catch your attention in the first place. Saving is nearly frictionless. Returning requires deliberately recreating an interest that’s already faded.
This is the same shape of problem as a bookmarks folder, a Watch Later playlist, or a “read it later” app — a category of feature that exists across a dozen products, and struggles with the same return-rate problem in all of them. I don’t think I built saved posts badly. I think I built a version of a feature type that has this problem built into its premise.
What I’m Not Going to Do
I’m not pulling the feature. People still ask for it, still use it, and the save action itself has real value even when the return visit doesn’t happen — sometimes just marking something as “worth remembering” is the actual point, independent of whether you ever look at the list again. Killing a feature because its usage pattern doesn’t match my mental model of how it should be used would be solving my problem, not the users’.
What I Might Actually Try
A gentle resurface, not a nag. Something low-key that occasionally puts a saved post back in front of you at a moment closer to when you’d actually want it — not a notification, just a subtle nudge back into view. This treats the actual problem (context fades) instead of pretending the feature just needs better visibility.
Being honest that “save” might mean something different than “read later.” Maybe the actual value of the save action is closer to a bookmark of interest — a signal, not a queue — and the fix isn’t making people return to a list, it’s stopping the pretense that the list is meant to be worked through.
The Bottom Line
I built saved posts because people asked for exactly this, and I don’t regret it. What I’ve learned since shipping it is that the feature people request and the feature they actually use don’t always match, and the honest response to that gap is examining it, not pretending it isn’t there. Saved posts might just be a graveyard by nature. That doesn’t necessarily mean it’s the wrong feature. It might just mean I’ve been thinking about what “saving” is for incorrectly.
