Building a Public Roadmap for a Product No One's Waiting On Yet

Tuesday morning. I'm staring at a Notion board titled "DevOS Roadmap" with exactly four items on it. The analytics dashboard tells me this page has received 11 views total — three of which are me checking if it rendered correctly. Nobody's requested a feature. Nobody's complained about priorities. The roadmap exists for an audience of approximately zero humans.

And I updated it anyway.

Here's the thing. Building a public roadmap for a pre-revenue product feels ridiculous. It's accountability theater for a show with no audience. Except it isn't — or at least, not entirely. There's a logic here, even if it looks absurd from the outside.

Why This Feels Backwards

The conventional wisdom says roadmaps are for managing customer expectations. You ship one when users start asking "when is feature X coming?" or when enterprise clients want to see a 12-month vision before signing an annual contract. The roadmap solves a communication problem that exists because people care about your product.

When nobody cares yet? Publishing a roadmap feels like printing menus for a restaurant that hasn't opened. A bit delusional, honestly. I've questioned this decision more than once.

At Velocity Digital Labs, we run eight products. Most are early-stage. Some have paying users. Some don't. DevOS has a waitlist but hasn't launched. JustAnalytics is live but still finding its footing. ClickzProtect has actual customers, but "actual" here means a number I could count on my hands with fingers left over.

None of these products have the user volume to justify a roadmap from a communication standpoint. Zero of them have had a user request a roadmap. And yet every single one has a public roadmap page.

Why? Three reasons, and only one of them is about users.

Accountability Without an Audience

The first reason is selfish. I need the roadmap more than any user does.

When you're a solo founder — or close to it, one founder and one ops manager — you don't have a product manager breathing down your neck. No sprint reviews. No stakeholder meetings where you explain why the thing you promised last quarter still isn't done. The absence of external pressure sounds nice until you realize it also means nothing stops you from wandering.

Feature creep. Shiny object syndrome. The pull of whatever tutorial showed up in your feed this morning.

I've done this. Spent two weeks refactoring code nobody would see while the landing page conversion stayed broken. Not proud of it.

Without some forcing function, it's easy to lose weeks on infrastructure that doesn't matter while the actual product sits there, unchanged.

A public roadmap creates artificial accountability. Even if nobody reads it, the knowledge that someone could read it changes behavior. That Notion board with 11 views? It's a record of what I said I'd build. If I abandon it, the evidence is there. That feels different from a private task list.

(Yes, this is basically tricking myself into discipline. I'm not proud. But it works.)

The roadmap also forces prioritization decisions. Can't put "maybe add AI agents" on a public roadmap — you have to actually decide. Is it "Now," "Next," or "Not doing"? That clarity matters. Vague internal notes let you defer forever. A public status forces a choice.

The SEO Argument Nobody Makes

Here's the unsexy truth. A roadmap page is content. Content gets indexed. Pages get ranked. And ranking takes time.

Google's timeline for new pages to rank meaningfully is somewhere between 3-12 months, depending on domain authority and competition. If you wait until your product has users to publish a roadmap, you've lost those months. The page starts climbing when you finally need it, not when it would've been useful.

For a pre-revenue product, the roadmap is low-effort SEO surface. It's a page that:

Contains keywords your future users search for
Gets updated regularly (Google likes freshness)
Links to your main product pages (internal linking helps)
Can rank for "[product name] roadmap" queries — low volume but high intent

Someone searching "ClickzProtect roadmap" or "DevOS feature list" is already aware your product exists and wants to evaluate it. Capturing that traffic matters even if it's single digits per month right now.

We've seen this pattern across the VDL portfolio. Pages published early, even with minimal content, tend to outperform pages published later — even when the later pages are more polished. The head start matters.

Annoying? Sure. I'd rather skip the SEO homework and just build features. But Google doesn't care what I'd rather do.

A Signal for the Three People Who Care

The third reason: early users are disproportionately valuable. And a roadmap speaks to them specifically.

When a product has millions of users, the roadmap is customer service — managing expectations at scale. When a product has twelve users, the roadmap is something else entirely: a signal that you're serious.

Think about it from the early adopter's perspective. They've found your product before anyone else heard of it. They're considering betting time or money on something unproven. One of their core anxieties: is this founder going to abandon this thing in three months?

A public roadmap — one that gets updated, one that shows actual progress — is evidence of commitment. It says: I'm thinking about this systematically. I have a plan. I'm not going to disappear.

That matters when you're asking someone to try VeloCards for crypto spending, JustEmails for email infrastructure, or JustAnalytics for privacy-first analytics. Early adopters are taking a risk. The roadmap lowers their perceived risk, even if they never look at it directly.

(And some do look at it. Not many — but the ones who do are exactly the users you want. They're evaluating seriously, not just kicking tires.)

What Actually Goes in a Pre-Revenue Roadmap

Okay, so you're convinced (or at least not rolling your eyes hard enough to stop reading). What do you actually put on this thing?

Here's the structure I use across VDL products:

Now — what I'm actively building this week or month. No more than 3 items. If you have 12 things in "Now," you're lying to yourself.

Next — what's coming after the current work. Could be 4-8 items. These should be things I've actually thought through, not wishlist items.

Considering — ideas that might happen but haven't been prioritized. The "maybe" pile. Where features go to wait indefinitely.

Not doing — this is the underrated section. What have you explicitly decided NOT to build? Why? This is often more valuable than the "yes" list because it shows you're making real tradeoffs, not just saying yes to everything.

For early-stage products, I also include a "Recent" section — what shipped in the last 30-60 days. This shows momentum even when the current list is short.

One more thing: link to related content where it makes sense. If the roadmap mentions "improved bot detection," link to a post explaining how ClickzProtect detects click fraud. If it mentions email deliverability improvements, link to JustEmails documentation. The roadmap becomes a hub, not a dead end.

The Contrarian Part

Here's where I lose some people. I think most public roadmaps are too polished. Too formal. Too much like what a PM at a Series B company would produce.

The indie hacker version of a roadmap should be messy. Personal. Opinionated.

Linear's public roadmap is beautiful and corporate. It works for them. For a pre-revenue product from a solo founder? That aesthetic is wrong. It signals a team and resources you don't have.

My roadmaps have notes like "probably should do this but honestly dreading it" and "users keep asking but I'm not convinced it matters." Messy. Real. That's the whole point of building in public — the glossy PM deck version is a lie anyway.

Don't try to look like a company you're not. The authenticity is the feature.

Also — and this is controversial — I think roadmaps should include timeframes even when you're probably wrong about them. "Q3 2026" is more useful than "soon" or "later." Yes, you'll miss deadlines. Yes, that's embarrassing. But the specificity forces real planning, and early users understand that solo founder timelines slip. (They slip at big companies too, honestly. At least you're being upfront about it.)

What This Means If You're Building Something Early

So here's the practical takeaway. If you're working on a product that doesn't have users demanding a roadmap:

Ship one anyway. Today. Doesn't need to be fancy. A public Notion page works. GitHub Projects works. A markdown file in your repo works. The format matters less than having something.
Update it on a schedule. Weekly or monthly. The cadence is the discipline. Build the habit before you need it. I update ours every Monday morning, whether or not anything changed — sometimes the update is just "no changes this week, still working on X."
Make it findable. Link it from your homepage footer. Link it from your docs. Add a /roadmap route. The SEO benefits only work if it's indexed.
Be honest about what's not happening. The "Not Doing" section is where trust gets built. Anyone can list features they want to build. Showing what you've explicitly declined — and why — demonstrates real decision-making.
Connect it to your content. Reference the roadmap in blog posts. Reference blog posts from the roadmap. The internal linking helps SEO and helps users understand your product more deeply.

A Prediction

By mid-2027, the default expectation for indie products will include a public roadmap from day one. Not because users demand it — but because founders will realize the self-accountability benefit outweighs the mild embarrassment of having nobody read it.

The tools will get easier. Linear, Notion, and GitHub will ship better public board defaults. Some startup will raise money specifically to make "roadmap pages for indie hackers" a product category. (Canny's already adjacent to this but hasn't fully nailed the pre-revenue use case.)

And the early movers — the founders who published roadmaps when their user count was laughable — will have a head start. Pages already ranking. Update habits already formed. Early adopters already converted.

I could be wrong. Probably am about half of this. Predictions are just guesses wearing a blazer. But I've been updating roadmaps for products nobody uses for long enough that I'm betting on the pattern.

Start now. Update weekly. Let it sit there, embarrassingly empty, until one day it isn't.

Frequently Asked Questions

Should pre-revenue startups have a public roadmap?

Yes. A public roadmap isn't about satisfying existing users — it's about creating accountability for yourself, building an SEO footprint before you need it, and giving early visitors a reason to check back. The roadmap becomes a forcing function for decision-making even when nobody's watching.

What tool should I use for a public roadmap with few users?

Keep it simple. A Notion page, a GitHub Projects board, or even a markdown file in your repo works fine at this stage. Don't pay for Canny or ProductBoard until you have actual feedback volume to manage. The tool matters less than the habit of updating it.

How often should you update a pre-launch roadmap?

At minimum, monthly. Weekly is better. The cadence matters more than the length of each update. A one-line status change beats an elaborate quarterly review that never happens. Build the muscle before you need it.

What should a public roadmap include at the early stage?

Three buckets: what you're working on now, what's next, and what you've considered but deprioritized. Be honest about the deprioritized items — explaining why you said no is often more valuable than what you said yes to.

Follow the Studio

Velocity Digital Labs is a multi-product studio building 8 active SaaS products with a 1-founder + 1-manager + N-AI-agents structure. Receipts, dollar-signs, cap-table-honest. No VC platform-play — just shipping.

See the products → · Browse all VDL blog posts