FeatureWish Turns Scattered Requests Into a Shared Roadmap

A feature request that arrives in an email can be easy to remember. The next one may appear in a direct message, then another in Slack, followed by a sales call that raises the same issue in different words. As a SaaS product gains paying customers, the problem is no longer a lack of ideas. It is knowing which requests represent real demand.

FeatureWish is built around that problem. It gives a SaaS team one place to collect requests, let users vote on them, publish a roadmap and record shipped work in a changelog. The aim is to replace a scattered record of customer conversations with a visible signal that can guide product decisions.

From conversations to ranked requests

The basic workflow is straightforward. Users post feature requests to a feedback board, then upvote requests that match what they need. A team can see which ideas attract support instead of relying only on the loudest individual customer or the most recent sales conversation.

That does not turn voting into an objective product strategy. A request with many votes may still be costly, unsuitable for the product, or less important than a smaller request tied to a critical customer. FeatureWish can organise the demand signal, but the team still has to interpret it and decide what to build.

The useful distinction is that requests become shared objects rather than private notes. Customers can see whether someone has already raised an idea, and product teams have a single place to review what users are asking for. For a growing SaaS business, that is the core job of this feature board.

A public roadmap closes part of the loop

Collecting requests is only one part of feedback management. Customers also need to know whether their input went anywhere. FeatureWish lets teams share a public roadmap for upcoming work and maintain a changelog for shipped features.

When a feature is shipped, users who voted for it are notified automatically. That gives the feedback process a visible endpoint: a request is posted, other users support it, the team decides whether to build it, and voters hear when the result is available.

This is useful for teams that want their roadmap and release communication in the same general workflow as their requests. It also makes a product decision more legible to customers, even when the answer is not to build a particular idea. The description does not say that FeatureWish handles private customer conversations, product analytics or prioritisation beyond requests and votes. Those jobs remain outside its stated feature set.

Built for one product first, then more

FeatureWish runs on the web, so it is suited to teams that want a browser-based place for feedback rather than a desktop application. The developer positions it for growing SaaS companies, product teams and founders, especially once informal conversations have become difficult to track.

The free plan includes one workspace and unlimited members. There is also a paid upgrade for running feedback for multiple products from one account. The pricing model is described as flat-priced and does not meter tracked users, which matters for a SaaS product whose customer base is growing. A team with only one product may have less reason to upgrade, while an organisation managing several products is the clearer fit for the paid plan.

There is a practical limitation here: the product is web-only. It will not serve teams looking for a native desktop or mobile app, and the description does not promise an offline workflow. It also assumes that customers will use the board and vote. If a company cannot direct users away from scattered conversations, the board may become another inbox rather than a reliable demand signal.

An AI-facing route into the board

For teams building with AI, FeatureWish includes a built-in MCP server. The stated use is to connect the feedback board to Claude Code or Cursor and ask questions such as which open requests currently rank highest, without leaving the editor.

That makes the board more accessible during development. An agent can have access to the codebase through the editor, while FeatureWish supplies information about what customers are asking for. The result is not automatic product prioritisation. It is a way to bring customer demand into a development conversation that might otherwise focus only on the code in front of the team.

This part of FeatureWish is specifically relevant to teams already using Claude Code or Cursor. It is not a general claim that every AI tool can query the board, and teams that do not use those editors may get little value from the MCP server.

Who FeatureWish is for

FeatureWish makes sense for growing SaaS teams that have outgrown informal request tracking and want customers to vote, watch a public roadmap and receive updates when work ships. Founders and small product teams may value the simple structure, while teams with multiple products have a clearer reason to consider the paid upgrade.

It is not a replacement for customer interviews, product analytics or a full prioritisation process. It is also a poor fit if your users rarely submit or vote on requests, or if you need a native application rather than a web tool. If your main problem is scattered demand and weak follow-up, FeatureWish offers a focused place to collect that signal and show what happened to it.