How to give customers a public view of a Notion roadmap
Publish the roadmap database to the web from Share, then Publish, and anyone with the link can view it without a Notion account or an invite. Notion's own publishing documentation confirms the page stays read-only for those visitors. They can open it, filter it, switch between views, but they can't edit a row or add themselves anywhere on the page. That's the part that trips people up, because "public view" and "public vote" sound like the same feature and they aren't.
There's no native way to let an open, uninvited audience vote on a Notion database. Voting requires writing to the database, whether that's tagging yourself in a property or changing a value, and Notion only lets people write to a database if they're a member of the workspace or a guest someone invited by email to that specific page. Guest access is explicitly per-person and by invitation; there's no setting that turns a public link into write access for whoever clicks it. So the honest setup has two separate pieces: a published page for seeing the roadmap, and something else entirely for collecting reactions to it.
Step 1: build the roadmap as a database, not a document
Use a database with three properties before anything else: a title (the item, written as a sentence), a Status select (Under review, Planned, Building, Shipped), and a Category select if you group by product area. Add a Board view grouped by Status; that's the view customers will actually look at, and it reads like a Trello board without needing one.
Keep the database itself simple. Every internal note, engineering estimate, or Linear link you don't want customers reading belongs in a different property or a linked page, not buried in the same view you're about to publish. Publishing a page publishes everything visible in that view, not just the columns you meant to show.
Step 2: publish the view, not the whole workspace
Open the roadmap page, click Share, then Publish. Notion generates a public URL for that page alone; nothing else in your workspace becomes visible through it. On paid plans you also get a few settings worth setting deliberately: toggle off "Discoverable on the web" if you don't want the page indexed by search engines, and leave "Duplicate as template" off unless you're fine with someone copying your whole roadmap structure into their own workspace.
Put the published link somewhere customers will find it without asking: a footer link, a support macro, a line in the onboarding email. A public roadmap that only the person who built it knows the URL for isn't doing its job.
Step 3: decide what "voting" means before you build it
This is the step people skip, and it's why so many Notion roadmaps end up as a static list nobody trusts. You have three real options, in order of how much Notion access they require:
- A Person property, for teammates and invited guests only. Notion's help center describes the formula:
prop("Upvoted by").length()counts names tagged in a Person property. It works, but only for people who already have a seat in your workspace. Our guide to building an upvote system in Notion covers the full setup. - A public form that files new requests, not votes on old ones. Notion Forms can be shared with "anyone on the web with link," no account required, and every submission lands as a brand-new row in a Responses table. A form is genuinely good at capturing a request from someone outside your workspace. It cannot find an existing roadmap row and add a vote to it. Ten customers submitting the same request produce ten new rows, not one row with ten votes.
- A dedicated public roadmap tool, if per-customer voting at scale is the actual requirement. Dedicated tools (Canny, Featurebase, and similar boards compared in the best public roadmap tools) let an anonymous or lightly-verified visitor click a vote button directly, something Notion's permission model doesn't offer.
Most teams land on the second option: publish the board, embed a form next to it for "ask for something not here," and manually fold form submissions into the roadmap during planning. It's more manual work than a vote button, and it's honest about what Notion can and can't do.
A construction-inspection tool tries the published-board version
Wardline's roadmap sat in a private Notion database for a year, invisible to the mid-size commercial general contractors who rely on the job-site inspection app it plans. Account managers kept fielding the same question on renewal calls, "is offline photo sync ever shipping?", with nothing to point to but their own memory of a standup. Leandro Corwin, who runs product there, decided the fix was to just publish the thing.
Leandro published the roadmap database as a Board view, grouped by status, and linked it from Wardline's support portal. "First week, we had maybe forty views and zero confusion," he said. "People could finally see 'building' next to offline sync instead of hearing it secondhand from their AM."
The friction showed up when a customer asked how to add a new request to the board. "There's no button for that on a published page, obviously, since it's read-only," Leandro said. "I added a Notion Form under it so people could submit something new. That part worked fine. What didn't work is I originally hoped the form could also let someone second an item that was already there, like filling out the form again for the same request and having it count toward it. It just makes a new row every time. If three customers ask for the same thing through the form, I get three rows that all say roughly the same sentence in slightly different words, and matching them up is on me."
Wardline now runs the published board plus the form, and Leandro does a monthly pass reading new form rows against the existing roadmap items to merge duplicates by hand. "It's maybe twenty minutes a month right now," he said. "I don't love that it doesn't scale, but the read-only board alone was worth doing on day one."
Where the manual merge stops working
Leandro's twenty minutes a month is the honest cost of the published-view-plus-form pattern, and it's a cost that scales with volume, not with effort spent building it well. Three things get harder as a roadmap gets real traffic:
- Matching submissions to existing items is manual and gets slower. A form has no idea "offline sync for inspection photos" and "photos won't save when the signal drops" are the same request; a person has to read both and decide.
- The count you can defend shrinks. A roadmap board with visible vote counts is a stronger argument in a planning meeting than "I read through the form responses and it felt like a lot of people wanted this," but Notion's version only produces the defensible count for people already inside the workspace.
- The request that never reaches the form is invisible. Everything said about the roadmap in a support ticket, a Slack DM to an account manager, or a sales call never becomes a form row unless someone remembers to re-type it. The published board and the form both only see what gets typed into them directly.
That last point is where the real gap sits, and it's upstream of anything a published Notion page can fix. Modem reads feature requests out of support tickets, sales calls, and Slack conversations directly, matches different phrasings of the same ask to one counted topic, and keeps every requester attached to it, whether they ever open your roadmap page or fill out your form. Modem's Notion integration writes those counted topics back into your workspace as pages or database rows, with your approval, so the roadmap you publish keeps its format and the count behind each item stops depending on who happened to type into a form. Modem is the company writing this guide, so read that comparison with the appropriate skepticism. A team fielding a handful of requests a month is genuinely fine with the manual pattern in Step 3 and doesn't need to change anything.
Set this up before your next release call
Publish the roadmap database as a Board view, confirm it's read-only by opening the link in a private browser window, and add a form underneath it for new requests. That's the whole native system, and it answers "can customers see the roadmap" completely. It doesn't answer "how many customers actually want this," which is a different question with a different fix.
