One changelog post. 8 minutes. Here's what it actually did for Marcus's SaaS.
Marcus builds TaskFlow — project management for small marketing agencies. 47 paying users. He's been building constantly, fixing bugs, adding features every week. His users have no idea.
One day an email lands in his inbox: "I had no idea you added time tracking last month, I've been doing it manually this whole time." That email is the moment most founders don't notice until it's too late. A user who almost churned. Not because the product was bad. Because they didn't know it had gotten better. Marcus sets up ReleaseLog. His public page is live in minutes. He sends one email to his 47 users about the new changelog page. 18 subscribe.
Next update, recurring task templates. He types rough notes into the AI writing assistant. It turns them into a polished update in seconds. He hits publish. 18 emails go out automatically. Sarah, one of his users, reads the email at lunch. Clicks through. Sees the roadmap. Submits a feature request: "Would love auto-assign for recurring tasks." Two other users already submitted the same idea. Marcus adds it to his roadmap in 30 seconds. Sarah sees her idea on the roadmap. Feels heard. Tells a colleague about TaskFlow. That colleague signs up the next day.
One changelog post. 8 minutes to write. 18 users informed. 1 user re-engaged. 1 feature request that shaped the next sprint. 1 word of mouth referral.
Marcus didn't run ads. He didn't post on Twitter. He just told his users what he built.
That's what ReleaseLog exists for. Changelog, roadmap, and feature requests in one place so your users always know what changed, what's coming, and that their feedback is being heard. tryreleaselog.com
Have you ever lost a user who would have stayed if they'd just known about a feature you'd already built?
"They didn't churn because of the product. They churned because they didn't know it got better." That's the cleanest articulation of this gap I've read. 4 users in on my own thing and I keep noticing this exact signal — features ship, users don't see them.
Q: do you track the second-order effect? i.e., did the re-engaged user end up referring someone, or is that too noisy to attribute back to one changelog post?
Hey! I just launched on product hunt, if you had the time to check it out. Would be much appreciated http://producthunt.com/posts/releaselog
The second-order attribution is honestly hard to close cleanly you'd need the referral to self-report which most don't. The closest signal ReleaseLog surfaces is whether the user who submitted the feature request opened the email when it shipped. That loop closing request in, update out, user notified is the moment trust compounds. Whether they referred someone after that is a conversation not a metric. Four users is enough to start closing that loop manually though. Do you know which of your four users has given you feedback you've actually shipped?
The Marcus case is a great illustration of a wider problem: solopreneurs build constantly but rarely 'announce' anything - even to themselves.
Same dynamic happens internally. You ship a feature, context-switch to the next crisis, and three weeks later you've forgotten what moved the needle. There's no changelog for your own decisions.
I'm building a Notion OS for solopreneurs at $0-5K MRR with a weekly review that does exactly this - surfaces what shipped, what decisions got made, and which ones still need to be revisited. Six linked databases: clients, projects, tasks, revenue, decision log, weekly review. The weekly review is basically a changelog you write for yourself.
The '8 minutes' framing is interesting. Do you find the biggest resistance is founders thinking it takes more time than it does, or that they just don't see the retention value until after they lose a user?
This comment was deleted 4 months ago