FeatQ

Roadmapping software

Ship a public roadmap your users can vote on

FeatQ connects visible product direction to the requests behind it, the customers who support it, and the changelog entry that closes the loop after delivery.

A public roadmap tool shows direction without exposing the whole plan

A public roadmap tool gives customers a readable view of product direction. It translates an internal backlog into a small set of meaningful items and honest states. The point is not to publish every task, dependency, estimate, or debate. It is to show which customer problems are being considered, planned, built, or completed.

Internal roadmapping software serves a different audience. A private plan may include staffing, technical dependencies, security work, contractual obligations, confidence levels, and target dates. Those details help the delivery team coordinate, but they can confuse or overcommit a public audience. A product roadmap tool can support both views while keeping their purposes distinct.

Publish when visibility improves the conversation. A public view gives support and sales a shared answer, lets customers find existing work before asking again, and creates a stable place to explain status. Keep an item private when disclosure would reveal security work, confidential commitments, sensitive strategy, or an idea too uncertain to represent as direction.

Openness also has costs. Competitors can read the same page. Customers may treat a broad intention as a promise. A stale item can weaken trust faster than no roadmap because it presents old direction as current truth. The maintenance rule is simple: only publish the level of commitment your team can keep accurate.

Public direction

Show a curated set of customer-facing outcomes and their current states. Keep the language broad enough to remain accurate as implementation details change.

Private delivery plan

Keep staffing, dependencies, risks, estimates, and confidential work in the internal system where the delivery team can manage them without creating a public commitment.

Maintained boundary

Review public items whenever priorities change. Remove stale assumptions, explain meaningful status changes, and keep the page smaller than the internal backlog.

Status columns work better than hard public dates

Most public roadmaps use coarse buckets because product delivery contains uncertainty. Planned, In Progress, and Shipped tell a customer how far work has moved without pretending that an early estimate is a deadline. Now, Next, and Later provide a time-horizon version of the same idea. Both patterns communicate order and confidence rather than a calendar promise.

FeatQ uses status-based columns. Requests move through New, Considering, Planned, In Progress, and Done. The early states keep intake and evaluation visible without placing every request on the roadmap. Planned signals a real decision, In Progress means work has begun, and Done records the shipped outcome.

Define each state in operational language. Considering should not mean quietly rejected, and Planned should not mean interesting but uncommitted. A status is useful only when the team applies it consistently. If priorities change, update the state and explain the change instead of leaving an item in a reassuring but false column.

Hard dates can still fit launches with high confidence, but they need visible caveats. Microsoft 365 is the notable public example: it publishes estimated dates with extensive disclaimers. For most products, buckets are the safer norm because they communicate direction while leaving room for discovery, dependencies, and quality work.

A maintenance cadence keeps the status language credible

Review new and considering items frequently enough that intake does not become a holding area. The review should confirm that duplicates are combined, request descriptions still name a real customer problem, and the strongest demand has an owner for the next product decision. This is queue maintenance, not a promise to advance every popular idea.

Review the published roadmap on a slower, deliberate cadence. Confirm that every Planned item still has a real intention behind it and every In Progress item reflects work that has actually begun. If an item moves backward, update it promptly and add enough context for customers to understand that direction changed.

Treat delivery as a status checklist. Before announcing a release, confirm that the request is Done, the changelog explains the customer-visible outcome, and the interested audience can be notified. This routine prevents the common gap where engineering finishes the work but the public roadmap remains stuck in an earlier state.

Voting belongs on the roadmap

A voter is a customer who supports a request or joins its discussion, rather than a teammate running the board. FeatQ does not charge for each voter and supports up to 10,000. That allows broad participation without making each additional customer a new billing event.

Voting connects product direction to visible demand. A customer finds an existing request, adds support, and becomes part of the audience interested in its outcome. The team sees the request rise relative to other ideas, considers it alongside strategy and effort, and changes its status when a decision is made.

The loop is request, vote, status change, then notification. That sequence is stronger than a roadmap built only from internal themes because every public item can retain the customer problem that justified it. It is also stronger than a suggestion box where votes accumulate without any visible product response.

Votes are evidence, not automatic commands. ProductPlan's 2024 State of Product Management Report, based on a Q4 2023 survey with more than 1,440 responses, found that customer feedback was the primary product-strategy driver for 27 percent of respondents and that 39 percent kept a feedback repository. A repository becomes more useful when the evidence is connected to decisions customers can see.

Leadership pressure still changes priorities. ProductPlan's 2026 State of Product Management Report, based on 250 product leaders, found that more than 60 percent of prioritization frameworks are overridden by leadership escalations. A visible vote count does not prevent those decisions. It makes the tradeoff explicit and gives the team a factual basis for explaining why direction moved.

Close the loop with a changelog

A roadmap is forward-looking. A changelog records what actually shipped. Keeping both on the same board prevents planned work from disappearing when delivery finishes. The original request, its customer support, and the release outcome remain connected instead of becoming separate records in separate systems.

In FeatQ, moving a request to Done places it in the board changelog. The people who voted for the request can be notified that the feature is available. That final message is the payoff for maintaining the earlier states: customers do not have to revisit the roadmap repeatedly to discover whether something changed.

Release communication also improves the next prioritization cycle. A changelog creates a durable record of which customer problems became product work. Support can share the announcement, product can compare delivered work with demand, and customers can see that participation leads to an observable outcome.

Pendo's February 2019 Feature Adoption Report found that 80 percent of features in the average software product were rarely or never used, with up to $29.5 billion in cloud-software research and development tied to unused features. A roadmap does not guarantee adoption, but linking plans to explicit demand and notifying the interested audience gives each shipped item a clearer path to use.

Pendo's second annual State of Product Leadership Survey in February 2019 found that 35 percent of product teams cited customer feedback as the primary driver of their best feature release. The useful habit is not publishing more promises. It is preserving the chain from customer evidence to decision, delivery, announcement, and later adoption review.

Real public roadmaps worth studying

Eight first-party examples checked in July 2026

GitHub

Exploring, In Design, Preview, GA, organized by quarter

Microsoft 365

In development, Rolling out, Launched, with estimated dates

Obsidian

Active, Planned, Launched

Zed

Currently Working On, Coming Up Next

PostHog

Voting and subscriptions on roadmap items

GitLab

Direction page with What’s Coming links to public epics

Buffer

Roadmap and What’s New portal on a dedicated subdomain

Cal.com

GitHub milestones used as the roadmap

Study the vocabulary before the visual design

GitHub uses Exploring, In Design, Preview, and GA, organized by quarter. Obsidian uses Active, Planned, and Launched. Zed reduces the public horizon to Currently Working On and Coming Up Next. Each system chooses labels that match the confidence it can communicate accurately.

A roadmap does not require special software at every scale

GitLab publishes a direction page with links from What's Coming to public epics. Cal.com uses GitHub milestones. Buffer runs a roadmap and What's New portal on a dedicated subdomain. The common lesson is a maintained public structure, not one mandatory implementation.

Participation can be part of the artifact

PostHog adds voting and subscriptions directly to roadmap items. That turns the page from a broadcast into an evidence and update channel. Microsoft 365 takes a different route with estimated dates and disclaimers. Both show that public roadmapping works best when the communication contract is explicit.

Borrow a pattern only after naming your audience

A developer platform may benefit from public issues, milestones, and detailed release stages. A broad business product may need plain customer language and fewer states. Copying another company's labels without its audience and delivery process can create a roadmap that looks familiar but communicates poorly.

Before choosing a structure, answer four questions: who reads the page, what decision should a reader understand, how often can the team maintain it, and what level of uncertainty is safe to show? The answers determine whether the right shape is detailed quarters, two broad horizons, status columns, public epics, or simple milestones.

Spreadsheets and Trello are fine until communication becomes the work

A spreadsheet or Trello board is a reasonable starting point. It stores ideas, supports basic grouping, and lets an internal team move cards through stages. If the audience is small and one person owns every update, the general-purpose tool may be enough.

The first break appears at customer participation. Customers cannot reliably find a duplicate before submitting, support cannot point several people to one shared request, and there is no native vote count attached to the problem. Staff begin copying names into cells or cards, which turns demand measurement into manual record keeping.

The second break appears at status communication. An internal card can move from one list to another, but the people who asked for the work do not automatically see the change. When delivery finishes, someone has to reconstruct the audience, write an announcement, and send it through another system. If that step is missed, the roadmap says progress happened but the feedback loop remains open.

A dedicated public roadmap tool connects the request, vote, status, roadmap placement, changelog entry, and notification. The benefit is not that it stores cards more attractively. It removes the manual joins between evidence, product direction, and customer response.

The agent workflow keeps delivery connected to public status

FeatQ exposes a standard streamable-HTTP MCP endpoint at /api/mcp. A board-scoped bearer key authenticates the connection, and any compatible client can use it, including Claude Code, Cursor, Codex CLI, or another tool that implements the protocol. MCP is included on every plan.

An agent can list requests sorted by votes, inspect the full context of a selected request, and generate an implementation specification. After the team approves the work, the agent builds and verifies it. The same connection can update request status so the public-facing system reflects the real delivery state.

Human product judgment remains the control point. A high vote count identifies demand, but strategy, effort, risk, and timing still determine what enters the plan. MCP removes repetitive copying after that decision. It does not let the public queue schedule engineering by itself.

This is where a roadmap becomes operational. The agent starts from the same request customers supported, works from its context, and records the resulting status change. Read the client setup and five-tool reference in the MCP documentation.

How FeatQ handles public roadmapping

Start with one board at a shareable FeatQ address. Customers can review current requests, add an idea, or support an existing one with a vote. Product teams use the ranked queue as one input to prioritization and apply a clear status when the decision changes.

The roadmap is status-based rather than date-driven. Planned and active work becomes visible without turning an estimate into a public deadline. When work reaches Done, the changelog records the shipped outcome and the interested audience can be notified. The board, roadmap, and release record remain parts of one process.

Pricing supports wide participation. FeatQ is $29 per month, $19 per month billed yearly at $228 per year, or $199 once through the 50-seat Lifetime founding deal. There are no per-user fees, and the bill is identical with 10 voters or 10,000. A 14-day money-back guarantee applies.

Setup is designed to be direct. Create the board, share the link, and it can be live in minutes without a sales call. The same plan includes the embeddable widget and MCP connection, so the public roadmap can meet customers inside the product and development agents inside the delivery workflow.

Frequently asked questions

Practical answers about agents, voting, embeds, and pricing.

A public roadmap tool publishes product direction in a form customers can understand. It organizes work into clear status or time-horizon groups, connects items to customer requests, and keeps progress visible. A useful tool also supports voting and a changelog so the roadmap is part of a complete feedback loop.

Use a public roadmap when customer input and visible progress improve the product conversation. Keep security-sensitive, contractual, operational, or uncertain internal work private. Many teams use both: a coarse public view for direction and a detailed private plan for dependencies, staffing, and dates.

Usually no. Broad statuses or buckets such as Planned and In Progress, or Now, Next, and Later, communicate direction without turning estimates into promises. Microsoft 365 is a notable exception: it publishes estimated dates with prominent disclaimers.

Users vote on the requests connected to the roadmap. Those votes rank demand on the board, while the team decides which requests move through New, Considering, Planned, In Progress, and Done. Each board supports up to 10,000 voters without changing the price.

The roadmap communicates forward-looking and active work. When a FeatQ request reaches Done, it appears in the board changelog and the people who voted for it can be notified. The original request, its votes, status history, and shipped outcome remain connected.

Yes. FeatQ includes a standard streamable-HTTP MCP endpoint on every plan. An agent can list requests by votes, inspect request context, generate a specification, update request status, and read board statistics through a board-scoped bearer key.

FeatQ is $29 per month, $19 per month billed yearly at $228 per year, or $199 once through the 50-seat Lifetime founding deal. Every payment option includes the board, voting, status-based roadmap, changelog, widget, and MCP access, backed by a 14-day money-back guarantee.

Still have questions? Contact us

Create your public roadmap

Put requests, votes, status-based direction, shipped updates, and agent access in one focused customer feedback loop.

View FeatQ pricing