# The 3 fastest-growing SaaS teams we studied all do this: they publish a public roadmap | AWcode **Published:** 2025-09-26 · **By:** 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 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: - **Builds trust** (“we’re listening, here’s what’s next”) - **Reduces churn** (customers see momentum and upcoming value) - **Focuses the backlog** (votes and comments sort signal from noise) - **Aligns go-to-market** (sales and success can point to what’s planned/GA) - **Compounds SEO and credibility** (shipping logs are proof, not promises) 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](https://about.gitlab.com/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](https://handbook.gitlab.com/handbook/product/) **Why it works** - **Credibility through context.** Not just a list of cards; you see *the reasoning* and *themes* guiding what ships next. That fosters enterprise-grade confidence even in SMB buyers. - **Expectation management.** Direction pages explicitly state that plans can change - useful transparency that protects trust when priorities shift. - **Internal alignment.** Sales, success, and community advocates can share one canonical source of truth. **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](https://help.clickup.com/hc/en-us/articles/6327807151639-Roadmap)** 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** - **One link to rule them all.** A single URL is shareable by support, success, and sales. New users get instant visibility. - **Qual + quant together.** Comments explain *why* something matters; votes show *how many* care. The combo hardens prioritization. - **User participation boosts buy-in.** When customers see their request appear on the roadmap (even tagged “under review”), satisfaction rises before you write a line of code. **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](https://supabase.com/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** - **Momentum reduces risk.** A steady changelog (with statuses and target timelines where possible) reassures teams evaluating a core platform. - **Community co-design.** Discussions become living artifacts of decisions; newcomers can see rationale, trade-offs, and constraints. - **Launch marketing = roadmap marketing.** Each shipped slice earns attention, backlinks, and social proof. **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** - **Hosted doc** (fastest) or **dedicated roadmap tool** (Usersloop public roadmap, Linear+Productlane, Canny board). Aim for one shareable URL. (Linear + Productlane is a popular pairing for publicizing selected projects.) **Day 2–3: Draft the initial cut** - **Now (0–8 weeks):** 3–6 items, each with one-line problem statements. - **Next (1–2 quarters):** 5–10 candidate items; mark confidence level. - **Later (2+ quarters):** themes only (e.g., “Team accounts,” “Analytics v2”). **Day 3: Wire feedback in** - Every item gets a **“Discuss / upvote”** link. - Add a **“Submit an idea”** button that lands in your intake (e.g., Usersloop form or widget). **Week 1: Start shipping the heartbeat** - Publish a **monthly “What we shipped”** update, even if small. - Add **status badges** and **owner initials** for each item. **Ongoing: Keep it honest** - If something slips, change the badge and add a one-sentence reason. - Close the loop with requesters when an item ships (email/DM/Usersloop auto-notify). --- ## 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 - **Changelog engagement:** unique views, time on page, scroll depth - **Request quality:** duplicates down, “problem statements” up - **Conversion & expansion:** win-rate lift where roadmap items match prospect needs - **Churn notes:** fewer “product moving too slow / no visibility” reasons - **Support deflection:** fewer “is X planned?” tickets as your roadmap gains awareness --- ## 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](https://usersloop.com) 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 - GitLab’s public **Product Direction** (strategy, themes, upcoming releases). [about.gitlab.com](https://about.gitlab.com/direction/) - GitLab’s public **Product Handbook** (how product is run; points to Direction). [The GitLab Handbook](https://handbook.gitlab.com/handbook/product/) - ClickUp’s **public Roadmap doc** and guidance to submit suggestions via Canny. [help.clickup.com](https://help.clickup.com/hc/en-us/articles/6327807151639-Roadmap) - Supabase **public changelog** and **open roadmap discussions** (GitHub Discussions). --- **How this post looks on the live site:** Rendered in a windowed news reader inside the AWcode OS desktop, alongside other posts. --- **Canonical HTML version:** https://awcode.com/news/the-3-fastest-growing-saas-teams-we-studied-all-do-this-they-publish-a-public-roadmap **About this document:** This is a plain-Markdown mirror of an AWcode.com page, served so that LLMs and agents can read the content without executing the site's retro-OS JavaScript UI. The HTML page at the canonical URL above carries the same content and is also fully indexable.