A public roadmap page that sets expectations instead of promises
A public roadmap tells customers what you're working on and roughly what comes after, without signing you up to dates you'll miss. The now, next, later format does that well. Anticode can keep the items in a CMS collection and take feature requests through a form; what it can't do is let visitors vote on or comment on items.
Why now, next, later
Dates on a public roadmap page turn every slip into a broken promise. A now next later roadmap swaps dates for confidence levels: what's being built, what's queued, what you're considering. It also shows customers why their request isn't at the top without a long explanation.
| Column | Meaning | How specific to be |
|---|---|---|
| Now | Being built; expect it within weeks | Specific: what it does and who it's for |
| Next | Planned after the current work; the scope may change | Clear problem, looser solution |
| Later | Under consideration; no commitment | The problem you're thinking about, not a feature |
| Shipped | Done, with a link to the changelog | Date it shipped |
Write items as problems the customer recognises ("export invoices to your accountant") rather than internal project names. Add a line at the top saying the roadmap changes and isn't a contract; it saves awkward conversations with customers who read "later" as "soon".
Keeping items in a collection
A product roadmap website goes stale when updating it means editing a designed page. Keep the items in a CMS collection instead, with fields for the title, a short description, the column (now, next, later or shipped) and the date it last changed. Entries are edited in the dashboard; the collection is served at its own address and each item can have its own page at /<collection>/<slug>, which is useful when you want to link a customer to one item from a support reply.
Move shipped items to a shipped column or a separate changelog page rather than deleting them. A visible record of things that were promised and delivered is the best argument that the rest of the roadmap is real.
Taking feature requests
The simplest option is the contact form, which asks for name, email and a message. If you want structured requests you can sort, a custom form tied to a site function can ask for the product area, the problem, how often it happens and the customer's plan, with up to 30 plain-text fields. The function's thank-you page can say how you handle requests, such as "we read every request and reply when it moves onto the roadmap".
- Ask for the problem, not the feature. "What were you trying to do?" tells you more than "what should we build?"
- Ask for the customer's email so you can tell them when it ships; that one follow-up builds more goodwill than the roadmap itself.
- Send requests to where you triage. Notion, Airtable or a Google Sheet for a product backlog; Slack so the team sees them.
Why there's no voting
Many roadmap tools let customers upvote items and comment on them. That needs accounts, a live count and visitors interacting with each other, and published Anticode pages don't do any of that: there are no visitor accounts on design-engine sites, and the pages run no scripts. That is a partial fit, and it's worth being clear about.
It's also less of a loss than it sounds. Vote counts tend to reward the loudest customers and the oldest items, and they create pressure to build things because they're popular rather than because they're right. Counting requests yourself, from the form submissions, gives you the same signal with context attached. If public voting matters to your product, use a dedicated feedback tool and link to it from your roadmap page.
Building it
Describe it: "a public roadmap for our invoicing app in now, next and later columns, from a collection, with a feature request form". The Architect asks up to three questions where the answer changes the build and shows a plan first. Choose a design system that matches the product's site; Technical (IBM Plex Sans) and Swiss (Inter Tight) suit a roadmap page for SaaS. Publish it as a page on your main Anticode site or on its own address.
Limits
- No voting, comments or customer logins.
- No private roadmap for selected customers. Every published page is public.
- No sync with your issue tracker. Items are edited in the dashboard, not pulled from Jira or Linear.
Questions people ask
How often should a public roadmap be updated?
At least monthly, and whenever something ships. Show the date of the last update on the page so readers know it's alive.
Should a startup publish its roadmap at all?
If customers keep asking what's coming, yes. Keep it at the level of problems, so competitors learn little they couldn't guess.
Can customers see each other's requests?
No. Requests arrive privately in your dashboard. Publish the ones you decide to work on as roadmap items.