Feature prioritization survey — turn user preference into roadmap signal

Who this template is for

Feature prioritization surveys are the form most product teams either run badly or don't run at all. The bad-run version asks users to rate every candidate feature on a 1-5 importance scale — and predictably gets back "4-5" on everything because users rarely call a proposed feature unimportant when asked directly. The didn't-run version relies on the loudest customer voices, the most-recent sales-call demands, and the product manager's intuition — which produces a roadmap shaped by sample bias rather than systematic preference data. The right version sits between: a structured survey against a curated list of features the team is actually evaluating, using methodologies that force trade-offs (MaxDiff, ranking, buy-a-feature) rather than allowing users to express vague enthusiasm. MaxDiff (Maximum Difference Scaling) presents users with subsets of 4-5 features and asks them to identify the most-preferred and least-preferred from each subset — repeated across multiple sets, this produces clean preference scores that statistically reveal the relative importance of each feature. Ranking asks users to order a list of 5-10 features from most-to-least important — simpler than MaxDiff but suffers from primacy and recency bias. Buy-a-feature gives users a fixed budget (e.g., $100 of imaginary product credit) and asks them to allocate it across the features they'd most want built — feels gamified and engages users more deeply. Likert importance ratings are the easiest to administer but produce the shallowest signal because most features rate "important." This template gives you all four methodologies as options, with the field structure to feed the results into Productboard, Canny, Linear, Aha, Notion, Productlift, Headway, Featurebase, or Sleekplan as structured input for the product team's prioritization decisions. The one rule most teams violate: don't survey users on features you won't actually build — users who vote for a feature and never see it built feel betrayed, and the betrayal makes the next survey response rate worse.

From candidate roadmap to prioritized list with statistical confidence

The product team starts with a curated list of 5-15 candidate features — features the team has scoped well enough to estimate effort and is actively evaluating for the next 6-12 months. The survey filters out features the team won't actually build (a violation of the implicit contract that surveying users creates). The survey selects a methodology based on the size of the candidate list and the audience's analytical tolerance: MaxDiff for 8-15 features with an analytically-tolerant audience (B2B power users, developers, enterprise admins) and product-team capacity to run the statistical analysis; ranking for 5-10 features with a general audience; buy-a-feature for 6-12 features when the team wants the engaging gamified experience; Likert importance for 15+ features when breadth matters more than depth. The survey runs against a targeted segment — typically engaged users (not new signups), and often segmented by ICP tier (the survey to enterprise users may surface different features than the survey to SMB users because their needs differ). On submission, the responses flow to the product-team's prioritization tool (Productboard, Canny, Aha, Linear, Notion, Productlift, Headway, Featurebase, Sleekplan; for Brazilian B2B SaaS, Pipefy can serve as the prioritization tracker), to product analytics for cohort-correlation analysis (do enterprise users prefer different features than SMB? do daily-active users prefer different features than weekly?), and to the CRM if the survey was targeted at sales-pipeline prospects (the responses inform sales positioning and prospect-specific roadmap conversations). The team aggregates the results, weighs them against engineering effort estimates and strategic priorities, and emerges with a prioritized roadmap that has user-signal data backing each decision.

What's included

Each methodology below has trade-offs. Choose the one that matches your team's analytical capacity and the user audience you're surveying. MaxDiff is the highest-signal but requires statistical analysis; ranking is the simplest but biased; buy-a-feature is the most engaging; Likert is the easiest to administer but lowest-signal.

Built for the product categories where roadmap prioritization is the highest-leverage decision

• B2B SaaS with active development roadmap

  The primary use case. B2B SaaS teams running quarterly or semi-annual roadmap-planning cycles use prioritization surveys to validate the team's internal hypothesis against user preference. Notion, Linear, Figma, Stripe, Vercel, Datadog, PostHog, Snowflake, MongoDB Atlas all run variants of this. The survey is typically targeted at engaged customers (active in the last 30 days) and segmented by tier — enterprise customers see one survey, SMB sees another, free-tier sees a third if at all. The methodology choice for B2B SaaS leans toward MaxDiff because the audience tolerates more analytical depth and the team has the statistical capacity to analyze the results. For Brazilian B2B SaaS (RD Station, Pipefy, Conta Azul, Bling, Omie, Movidesk, Octadesk), the same pattern applies with the addition of language-specific feature considerations (the Portuguese-language interface, Brazilian fiscal compliance features, integration with local platforms like Pix, Boleto, NFSe issuance) often appearing in the candidate set as locale-specific roadmap items.

• Developer tools collecting platform preferences

  Different vocabulary, similar methodology. Developer-tool prioritization surveys ask about integrations (which clouds, which IDEs, which CI systems, which databases), language and framework support (TypeScript / Python / Go / Rust / Java priorities), feature depth vs. breadth trade-offs (deeper integration with X vs. lighter integration with N), and pricing-model preferences (per-seat vs. usage-based). The audience is unusually analytically tolerant, which means MaxDiff and conjoint-adjacent methodologies work well — developers will engage with complex preference structures that other audiences won't. Vercel, Stripe, Twilio, Datadog, PostHog, Linear, Sentry, Bugsnag all run variants. For modern AI-developer tools (Cursor, Windsurf, Continue, Cline, Aider, Anthropic Claude Code, GitHub Copilot), the prioritization survey often covers model-quality vs. model-cost trade-offs, agent vs. completion modes, and integration depth with specific frameworks. For Brazilian and Spanish-speaking developer audiences, the language-of-comments and language-of-documentation preferences appear as additional features.

• Consumer products with feature variant decisions

  Different dynamics than B2B because consumer audiences have less analytical tolerance and need simpler methodologies. Ranking and buy-a-feature work better than MaxDiff for consumer audiences. Common consumer prioritization survey contexts: which new content to license (streaming), which new workout type to add (fitness apps), which new investment instrument to support (consumer fintech), which new template to add (creative tools). The candidate list is typically smaller for consumer (5-8 features) than B2B (8-15) because consumer audiences fatigue faster. For Brazilian consumer apps (Nubank, iFood, Mercado Pago, Magalu, Picpay, Globoplay), the same pattern applies with the cultural overlay that Brazilian users tend to engage more enthusiastically with gamified survey formats — buy-a-feature with virtual currency often gets higher response rates than equivalent MaxDiff or ranking surveys.

• Vertical SaaS choosing between industry-specific features

  Prioritization for vertical SaaS centers on industry-specific feature trade-offs. A restaurant SaaS team might survey whether to build deeper POS integration with Toast vs. Square vs. Lightspeed; a clinic SaaS team whether to deepen EHR integration with Epic vs. Cerner vs. athena vs. eClinicalWorks; a construction SaaS team whether to support Procore vs. PlanGrid vs. Buildertrend. The MaxDiff methodology works well here because the audience knows their industry deeply and can make meaningful trade-offs. For Brazilian vertical SaaS, the locale-specific platform integrations are typically the dominant candidates: PDV anchors (Stone POS, Linx, Sischef, Saipos) for restaurant SaaS; EHR anchors (Tasy, MV, Memed, iClinic, Doctoralia) for clinic SaaS; construction anchors (Sienge, Builders 360, Construmanager). For Spanish vertical SaaS, similar local-platform integration priorities dominate (Hiopos, ICG for restaurant; Doctoralia, Clinic Cloud for clinic; PlanRadar for construction).

• AI products with capability vs. usability trade-offs

  The category where prioritization surveys are most-recently essential because the product space is moving fast and the trade-off space is multi-dimensional. AI products face prioritization across model quality (smarter model that's slower vs. faster model with similar quality), feature depth (more capabilities vs. better existing capabilities), integration breadth (more platforms vs. deeper integration with existing platforms), and pricing model (per-token vs. per-seat vs. flat). The audience for AI product surveys skews developer-and-power-user, which tolerates MaxDiff and conjoint-adjacent methodologies. Anthropic, OpenAI, Google, Meta, the major AI labs all run prioritization research with their power users; Cursor, Windsurf, Continue, Cline, Aider similarly run prioritization across their roadmap of capabilities. For Brazilian and Spanish-speaking AI product audiences specifically, language-specific performance and locale-specific use cases (Brazilian Portuguese model performance, Spanish-language reasoning quality, locale-specific cultural context) often appear as differentiated candidate features.

• Marketplace features (buyer vs. seller priorities)

  Two-sided marketplaces need two separate prioritization surveys — one for buyers, one for sellers — because their priorities differ entirely. Etsy's sellers prioritize listing tools and analytics; Etsy's buyers prioritize discovery and trust signals. Airbnb's hosts prioritize calendar management and pricing tools; Airbnb's guests prioritize search refinement and booking flexibility. The MaxDiff methodology works well here because the surveys are well-targeted (sellers are sent the seller survey, buyers the buyer survey) and the audiences understand their side's needs deeply. For Brazilian marketplaces (MercadoLivre, Magalu Marketplace, Americanas Marketplace, Shopee Brasil), the same dual-survey pattern applies; Brazilian seller surveys often surface Pix integration, NFSe automation, Reclame Aqui management tools as candidates; Brazilian buyer surveys often surface price comparison, delivery tracking, and review-aggregation features. For Spanish marketplaces (Wallapop, Vinted, Joom, the regional Iberian marketplaces), similar locale-specific feature priorities dominate.

Choose the methodology, curate the candidate list, target the audience

Start by choosing the methodology. MaxDiff (Maximum Difference Scaling) — best/worst out of subsets of 4-5 features, repeated across 8-12 sets, statistically analyzed to produce preference scores. Best for analytically-tolerant audiences (B2B power users, developers, enterprise admins) and product teams with statistical capacity. Ranking — order a list of 5-10 features from most-to-least important. Simpler to administer and analyze but biased by primacy and recency (users tend to rank the first option higher and the last option lower than they would in random order). Buy-a-feature — give users a budget (e.g., 100 imaginary product credits) and ask them to allocate across features. Engaging and forces trade-offs but can produce "hedging" behavior where users spread small amounts across many features. Likert importance — rate each feature on a 1-5 scale. Easiest to administer but produces shallow signal because most features rate 4-5. Curate the candidate list carefully — only include features the team would actually build if users prioritized them, because users who vote for features that never ship feel betrayed and respond at lower rates to future surveys. Target the survey to engaged users (active in the last 30 days) not new signups (their preferences are unstable). Segment by ICP tier where relevant — enterprise users may prefer different features than SMB users, and aggregating their preferences without segmentation loses signal. Send the results back to respondents transparently — "based on the survey, we're prioritizing X and Y; we're not building Z right now because survey results showed lower demand" — this builds trust and increases future response rates. Integrate the results with your prioritization tool (Productboard, Canny, Aha, Linear, Notion, Productlift, Headway, Featurebase, Sleekplan; for Brazilian B2B SaaS, the Pipefy product-tracker can serve this role) so the survey data feeds the team's decision process directly. Translate the survey into the languages of your user base — Brazilian and Spanish-speaking users respond at higher rates to native-language prioritization surveys.

Feature prioritization survey FAQ

Related templates