--- title: "How to Prioritize Feature Requests by Customer Segment" summary: "Tag feature requests with plan, company size or any segment you define, then filter your board by it. A step-by-step guide using FeatureOS custom fields." date: 2026-11-05 author: "Karthik Kamalakannan" canonical: https://featureos.com/blog/prioritize-feature-requests-by-customer-segment markdown: https://featureos.com/blog/prioritize-feature-requests-by-customer-segment.md lastUpdated: 2026-11-05 categories: ["guides","product-management","customer-feedback"] readingTime: 6 --- To prioritize feature requests by customer segment, record the segment on every request (plan, company size, region, whatever matters to you), then filter the board by that value and compare the top requests for each group side by side. In FeatureOS you do this with board custom fields and the custom field filter on the Dashboard. Vote counts tell you what is popular. They do not tell you who is asking. Fifty votes from free trial users and five votes from your largest accounts are different signals, and a single sorted list hides the difference. Segmenting the list is how you see it. > **TL;DR:** Add a custom field such as "Plan" or "Company size" to your board, hide it from customers if it is internal, fill it in on each post, then filter posts by that field on the FeatureOS Dashboard. You get one ranked list per segment instead of one blended list for everyone. ## Why does the same request rank differently by segment? Because each segment has a different job to get done. A small team on your entry plan may want a simpler setup flow. A larger account may want permissions and audit trails. Both groups vote honestly, and both lists are correct for that group. When you mix them, the larger group usually wins by volume. That is fine if volume is your goal. It is a problem if your goal this quarter is retention in one segment or expansion in another. Segmenting does not decide for you. It shows you the tradeoff so you can decide on purpose. It also helps you say no with a reason. "This is the top request from trial users, but our focus this quarter is accounts on the higher plans" is a clearer answer than "we have other priorities." More on that in [the art of saying no to feature requests](/blog/the-art-of-saying-no-to-feature-requests). ## What segment data should you capture on a feature request? Pick fields you will actually filter by. Two or three is plenty to start. Common choices: - **Plan or tier.** Which plan the requester is on. - **Company size.** A band such as 1-10, 11-50, 51-200. - **Revenue band.** If your team tracks it, a range rather than an exact figure. - **Use case or industry.** What they use your product for. - **Region.** Useful when requests depend on local rules or languages. These are fields you create and fill. FeatureOS does not pull them in from a CRM on its own, so decide up front who sets each value: the customer on the submission form, or your team after the post comes in. Keep the options fixed. A dropdown with five choices filters cleanly. A free text field where people type "Pro", "pro plan" and "PRO" does not. ## How do you set up segment fields in FeatureOS? Custom fields live on each board. The supported field types are Short Text, Email, Long Text, URL, Number, Switch, Date, Dropdown, Poll, Radio Buttons, Checkboxes, Slider, Star Rating, and NPS Rating. For segments, Dropdown and Radio Buttons are usually the right pick because they force a fixed set of values. 1. **Add a custom field to the board.** Create a field per segment, for example "Plan" as a Dropdown. Dropdown fields can be single choice or multiple choice. See the [custom fields help guide](https://help.featureos.app/en/articles/setting-up-custom-fields-for-the-new-post-form) for setup. 2. **Order the options.** Use the up and down arrows on dropdown options to put them in a sensible order, such as smallest plan to largest. 3. **Hide internal fields from customers.** If the field is for your team only (a revenue band, an account tier), hide it from customers so it never shows on the public post. 4. **Fill the value on each post.** Customers can fill visible fields when they submit. For hidden fields, your team edits the value from the post sidebar. You can also copy custom fields from the sidebar. 5. **Filter posts by the field.** Open your FeatureOS Dashboard and filter posts by custom field values. Pick "Plan: Business" and you see only what that segment asked for. 6. **Compare segments.** Run the same filter for each value and note the top few requests in each. Requests that rank high in more than one segment are your strongest candidates. Source: [Custom Field Filtering is Live](https://feedback.featureos.app/changelog/custom-field-filtering-is-live), shipped August 25, 2026. Field types from [More Field Types Now Available For Custom Fields](https://feedback.featureos.app/changelog/more-custom-field-types-now-available-for-custom-fields), shipped November 27, 2025. Hidden fields and sidebar editing from [Cap votes per post](https://feedback.featureos.app/changelog/cap-votes-per-post), shipped October 5, 2026. ## How do you turn segment lists into a priority order? Filtering gives you lists. You still need a method to rank across them. Three options that work well together with segment data: - **Score the shortlist.** Take the top requests from each segment and score them with a framework such as RICE or value vs effort. The [feature prioritization calculator](/tools/feature-prioritization-calculator) does the math for you. - **Weight by goal.** If this quarter is about one segment, give requests from it a higher weight in your scoring. Write the weight down so the team knows why. - **Look for overlap.** A request near the top in two or three segments usually beats one that is first in a single segment. For a deeper look at the frameworks, read [feature prioritization frameworks](/blog/feature-prioritization-frameworks). For grouping requests into themes before you score them, see [customer feedback analysis](/blog/customer-feedback-analysis). ## Example (hypothetical): one board, two very different top fives A team runs one public board for all customers. They add a "Plan" dropdown with three options and fill it on new posts as they come in. Sorted by votes, the board's top request is a new theme option. Filtered to the highest plan, that request is not in the top five at all. The top requests there are about roles and approvals. The team does not drop the theme request. They note it as the top pick for smaller plans and schedule it for a later cycle. This quarter's focus is the higher plan, so roles go first. The decision took one filter and a short conversation, not a week of digging through spreadsheets. ## Example (hypothetical): segment by use case, not by plan Another team sells to two kinds of customers: agencies and in-house teams. Plan does not separate them well, because both groups buy every plan. They add a "Use case" radio button field with two options and hide it from customers. Support fills it from the post sidebar during triage. Filtering by use case shows the agencies asking mostly for multi-client features and the in-house teams asking for integrations. Neither pattern showed up in the blended list. The team splits the roadmap discussion into two short sections, one per use case, and ranks each on its own. ## What are the limits of segment-based prioritization? Be honest about what this setup does and does not do. - **Values are only as good as your input.** If nobody fills the field, the filter shows nothing useful. Make filling it part of triage. - **No automatic enrichment.** FeatureOS does not fetch plan or revenue data for you. Your team or your customers set the value. - **No built-in revenue weighting.** Filtering shows you what each segment wants. Turning that into a weighted score is your call, in your framework or a spreadsheet. - **Old posts need backfill.** Fields you add today are empty on posts from last year. Start with the top open requests and fill those first. - **Too many fields slow triage.** Every field is something someone has to fill. Add one only when you know which decision it will change. ## How do you keep segment data useful over time? Review your fields once a quarter. Remove options nobody picks. Merge options that mean the same thing. If a segment stops mattering to your strategy, stop collecting it. Also keep the field names stable. If "Plan" becomes "Tier" halfway through the year, filters and team habits break. Rename once, early, or not at all. When a segment's top request ships, tell that segment. A changelog post that says "the most requested feature from teams on our larger plans is live" lands better than a generic note. ## Get started FeatureOS plans are seat bundles: Starter is $60/mo for 5 seats, Growth $120/mo for 10, Business $250/mo for 15, and $15 per extra seat. There is no free plan. [Start a 14-day FeatureOS trial](https://portal.featureos.app/auth/signup) (we can extend it to 30 days if you need more time), add one segment field to your busiest board, and filter by it next time you plan a cycle. --- ## Related Reading - [Feature Prioritization Frameworks](/blog/feature-prioritization-frameworks): RICE, Kano, MoSCoW and when to use each. - [Feature Prioritization Calculator](/tools/feature-prioritization-calculator): Score a shortlist in a few minutes. - [Customer Feedback Analysis](/blog/customer-feedback-analysis): Group requests into themes before you rank them. - [The Art of Saying No to Feature Requests](/blog/the-art-of-saying-no-to-feature-requests): How to decline clearly and keep trust.