A changelog and roadmap your users actually read

I've looked at a lot of public roadmaps from small products, and many tell the same story: a burst of enthusiasm, a long "Planned" column, and then nothing moves for months. The changelog next to it says "Bug fixes and improvements" three times in a row.

I wrote earlier about why I keep a public changelog at all, and an older post covers why a public roadmap is worth having. This post is about the harder part for a solo developer: keeping both alive week after week, with no product manager, so the people who ask for things actually find out what happened.

Why nobody reads them

When I look at my own old changelogs, the problems are easy to spot:

1. They're written for me. "Refactored auth middleware" means something to me. To a user it means nothing.

2. They're disconnected from the requests. Say someone asks for CSV export by email, and it ships a few months later. The changelog says "Added export". The person who asked never connects the two.

3. The roadmap promises dates I can't keep. I'm one person. Dates slip, and every slipped date is a small broken promise.

4. Nothing ever gets a "no". Requests I'll never build sit in "Open" forever, and that's its own kind of dishonesty.

Use statuses, not dates

The most useful change for me was to stop putting dates on the roadmap. Every request has a status instead, and the status is the promise.

In Pullwish, feature requests move through Open, Planned, In progress, In review, Approved for release, Done and Declined, and the public roadmap groups them by status. That gives visitors an honest picture without a single date:

• Open means "I've seen it, and people can vote on it."

• Planned means "I intend to build this." I try to keep this column short. If it keeps growing, I'm lying to myself.

• In progress means I'm actually working on it right now. For one person, that should be one or two items.

• Done is where it lands when it ships.

• Declined is the one most solo developers skip, and the one I've come to value most.

Declining a request feels rude, but it's the opposite. A short comment saying "I'm not going to build this, and here's why" respects the person's time far more than silence. They can stop waiting and look for a workaround. Pullwish describes the status as "not moving forward right now, but kept for context", which is exactly how I use it: the request and the reasoning stay visible.

Let votes start the conversation, not end it

Voting is how I find out what matters without running surveys. Users can vote and comment on the public board, and anonymous voting is an on/off switch per project.

I don't build strictly by vote count, though. A popular request might be a weekend job or a three-month rewrite. Pullwish has priority scoring that weighs votes, comments, affected users and revenue, which is a better starting point than raw votes. It's still only a starting point. The decision is mine, and I try to explain it on the request when I move something to Planned or Declined.

That explanation matters. Comment threads come with status updates, so when a status changes, the reasoning sits right next to the request. People who voted can see why, not just what.

Write the changelog for the person who asked

The rule I use now: every changelog entry should make sense to the person who requested the feature, even if they've forgotten they asked.

• Lead with what they can do now, not what I changed. "You can now export your entries to CSV from Settings" beats "Added CSV export endpoint".

• Keep the summary to one line. Most entries need nothing more than the summary.

• Tie it to the request. When a feature request moves to Done or Approved for release, Pullwish creates a changelog draft for it. Bug reports get the same when they're resolved or closed. So the entry starts out linked to the request, the votes and the roadmap card, and the loop closes in one place. I covered the details of linked and internal entries in the changelog post, so I won't repeat them here.

• Skip the noise. Dependency bumps and internal refactors don't belong in a public changelog.

Make it a short weekly routine

The roadmap dies when updating it becomes a project. So I treat it as a small weekly routine instead:

1. Close what shipped. Move shipped items to Done and go through the changelog drafts that creates.

2. Publish only when it's live. A draft stays a draft until the release is actually out.

3. Move one thing forward. Pick the next item from Planned and move it to In progress. If nothing moved this week, that's fine, but I want to notice it.

4. Answer the new requests. Every new request gets a status: Open, Planned or Declined. My goal is that nobody waits long for a first answer.

5. Prune. If something has sat in Planned for months and I know I'm not getting to it, I move it back to Open or decline it, with a comment.

Because I build in Cursor, a lot of this happens without opening the dashboard. The Pullwish MCP has a publish_changelog tool that publishes the entry for a feature or bug with a summary and an optional description. When the agent and I finish a feature, I ask it to draft the entry for that request and I approve the wording before it goes out. If something goes out by mistake, unpublish_changelog takes it off the public changelog without deleting the text. The words are still mine. I won't publish release notes I haven't read.

Put it where your users already are

Most users will never go looking for your roadmap. The public board, roadmap and changelog live together on your Pullwish project page, so the place where someone requested a feature is the same place they'll see it marked done. You can see ours on the Pullwish public board.

Two more ways to reach people:

• Webhooks. Pullwish sends a changelog.published webhook when an entry becomes public. It formats the payload for Discord, Slack and Microsoft Teams URLs, so a community channel can get new entries automatically. Entries linked to internal items are skipped.

• Inside your own app. The public API has GET /changelog for published entries and GET /roadmap for items grouped by status. Internal items are left out of both. API access needs Indie or higher (€19/month); the board, roadmap and changelog themselves are on the free Hobby plan. New accounts get Indie free for 14 days with no card.

The honest summary

A roadmap and changelog people read aren't really about the tool. They come down to three habits: statuses instead of dates, an answer for every request (including "no"), and changelog entries written for the person who asked.

If you want to see how feature requests, bug reports, the roadmap and the changelog fit together, try the live demo from the menu on pullwish.com. No sign-up needed.

AI Disclaimer: This article was drafted with AI assistance from my own notes on how I use Pullwish. I reviewed, edited and fact-checked it against the product before publishing.