The 3 fastest-growing SaaS teams we studied all do this: they publish a public roadmap | AWcode — AWcode

As a startup studio, we’ve worked with lots of young SaaS teams who are racing to product-market fit while juggling support, features, and constant feedback. One practice consistently separates the breakaway performers from the pack: They work in public - specifically, they publish a clear, living public roadmap and pair it with continuous changelogs and

2025-09-26 — Imported

As a startup studio, we’ve worked with lots of young SaaS teams who are racing to product-market fit while juggling support, features, and constant feedback. One practice consistently separates the breakaway performers from the pack:

They work in public - specifically, they publish a clear, living public roadmap and pair it with continuous changelogs and user feedback loops.

Why does this single habit move the needle? Because a public roadmap simultaneously:

Below we break down three well-known, high-growth product orgs with effective public roadmapping styles - GitLab, ClickUp, and Supabase - and extract practical patterns you can copy this week.

1) GitLab - “Direction” as a public product strategy (and roadmap)

How they do it

Instead of a single pretty board, GitLab publishes a comprehensive Product Direction site: multi-horizon strategy (3-year view), annual investment themes, and upcoming releases - all public and continuously updated. This gives customers and prospects a candid signal of where the platform is heading and how priorities are set across the DevSecOps lifecycle.

They also document how product is run (principles, processes, ownership) in a publicly accessible product handbook, which points readers back to “Product Direction” for what’s planned. This closes the loop between strategy (why), process (how), and roadmap (what/when). The GitLab Handbook

Why it works

How to replicate (lean version)

  1. Publish a simple “Direction” page with three layers:
    • 12–18 month themes (3–5 bullets, not everything)
    • A now/next/later table linking to issues/epics
    • A monthly changelog anchor (“what shipped”)
  2. Label uncertainty. Use tags like exploratory, draft, or committed to signal maturity and manage risk.
  3. Link feedback in-line. Each roadmap item should have a “Discuss / upvote” link (Canny, Usersloop, GitHub Discussion, etc.).
  4. Assign DRIs visibly. A name or team next to each initiative raises accountability and answerability.

2) ClickUp - Public doc + Canny for suggestions and prioritization

How they do it

ClickUp maintains a public Roadmap doc and explicitly funnels feature requests through Canny. The doc serves as the “what’s planned” home base; Canny concentrates raw requests, votes, and comments into a prioritizable stream the team can act on.

Why it works

How to replicate (lean version)

  1. Stand up a hosted roadmap page (Notion/Docs page or Usersloop’s public roadmap) with:
    • Sections: Now, Next, Later
    • Status badges (Planned/In progress/Released/On hold)
    • Links to discussion threads
  2. Route all requests to one intake. If you already get requests via email/Slack/Twitter, reply with: “Great idea - could you add it here so others can upvote?” Over time, the roadmap naturally orders itself.
  3. Ship a monthly roundup. Post “What shipped” + “What moved” + “Top new requests.” This creates a heartbeat customers come to expect.

3) Supabase - Open-source cadence with public discussions and a prolific changelog

How they do it

Supabase leans into the open-source playbook: they maintain a high-frequency public changelog and push roadmap discussions in the open (e.g., GitHub Discussions on upcoming packages/roadmaps). The cadence - lots of visible progress, clearly dated - gives developers confidence that the platform is moving fast and that their feedback is heard.

Why it works

How to replicate (lean version)

  1. Create a public changelog (auto-generated or hand-rolled) with clear, dated entries and tags (feature, improvement, fix, deprecation).
  2. Move “spicy” debates to public threads. For candidate features, open a thread (“Problem / Proposal / Open questions”) and link it from the roadmap.
  3. Set light target windows. Month/quarter windows (Q4 ’25) beat exact dates for small teams. Mark slipped items with a short note > perfection.

Patterns the winners share

  1. They don’t just list features - they publish direction.
    A sentence or two about why it matters turns a card into strategy. GitLab’s “Direction” shows the playbook.
  2. They make participation obvious.
    ClickUp’s roadmap doc points users to Canny for requests and votes; it’s impossible to miss how to contribute.
  3. They ship publicly, often.
    Supabase’s changelog rhythm is a trust engine. Even modest releases, shipped consistently, create a perception of momentum.
  4. They set expectations explicitly.
    GitLab’s pages state that plans may change; this simple disclaimer maintains credibility when reality shifts.
  5. They give GTM teams a shareable truth.
    A single roadmap link keeps Sales/Success/Support aligned and reduces “When will X be ready?” thrash.

A step-by-step roadmap launch plan for a 1–50 person SaaS

Day 1–2: Decide the container

Day 2–3: Draft the initial cut

Day 3: Wire feedback in

Week 1: Start shipping the heartbeat

Ongoing: Keep it honest

Objections you’ll hear - and how to handle them

“Won’t competitors copy our roadmap?”
Maybe. But in early-stage SaaS, speed, quality, and customer intimacy are larger moats than secrecy. Public roadmaps raise the bar for rivals by forcing them to match your clarity and cadence. GitLab’s posture explicitly acknowledges change and still publishes direction.

“We’ll get yelled at if we miss dates.”
Don’t publish dates; publish windows and confidence labels. Be explicit that direction is subject to change (again, GitLab’s framing is a good model).

“It’s more overhead.”
A monthly 45-minute ritual to update the doc and changelog is far cheaper than dozens of one-off “ETA?” conversations across support and sales.

Metrics to watch after you go public

Do it affordably (and fast) with Usersloop

If you want the ClickUp-style public doc, Supabase-style changelog cadence, and GitLab-style direction - without stitching 3–4 tools - Usersloop gives you a lightweight, all-in-one path:

  1. Public Roadmap (hosted page)
    • Create Now / Next / Later lanes, add statuses, owners, and confidence labels.
    • Expose an upvote / comment surface so customers can participate.
  2. In-app Widget (chat + feedback + announcements)
    • Let users submit ideas straight from your product (no context lost).
    • Announce releases with targeted banners or messages in the widget.
    • Offer helpdesk and support chat in the same place customers discover updates.
  3. Changelog & Announcements
    • Publish concise, tagged release notes (feature, fix, improvement).
    • Auto-notify followers of a roadmap item when it ships, closing the loop.
  4. Prioritization & Planning
    • Aggregate votes, impact notes, and customer segments into your backlog.
    • Convert validated ideas into roadmap items with one click, keeping the public page in sync.

Result: You replicate the best parts of GitLab’s “direction,” ClickUp’s public roadmap + Canny flow, and Supabase’s visible shipping cadence without buying multiple subscriptions - or duct-taping Notion, Canny, and a custom changelog together.

If you’d like, we can turn this into a quick-start package from AWcode: we’ll set up your Usersloop public roadmap, in-app widget, and a 30-day shipping cadence - then A/B test two simple announcement styles to see which boosts engagement and reduces “what’s next?” tickets the most.

Sources & further reading

← All news

Language: English · ไทย · Dansk · Kiswahili