> For the complete documentation index, see [llms.txt](https://docs.zigpoll.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zigpoll.com/guides/how-to-prioritize-your-product-roadmap.md). # How to Prioritize Your Product Roadmap Ask customers "what should we build next?" and they'll tell you: everything. Feature requests arrive as an undifferentiated list where every item is urgent and nothing can be cut. The fix is to force a trade-off. A well-built prioritization survey makes respondents *choose*, which converts a wishlist into a ranking you can actually build against. *** ## Building the survey ### Question 1 — Force the trade-off Add a **Ranked Choice** question: **"Rank these in order of how much they'd improve your experience."** List five to seven candidate features and set a minimum number of items to rank. Ranking is the whole trick — when everything can be "very important," everything is. When respondents have to put something last, you learn what they'll actually give up. {% hint style="warning" %} Don't use a set of rating scales here. If you ask people to rate ten features on a 1–5 scale, most will rate everything a 4 or 5 and you'll end up exactly where you started. {% endhint %} ### Question 2 — Rate the current state Add a **Matrix** question to rate the areas you already have — each row is an area (Search, Checkout, Support, Mobile), and the shared columns are a consistent scale (Poor / Okay / Great). This is the half of the picture that a feature ranking misses. The intersection of **"ranked highly"** and **"currently rated poorly"** is your roadmap. A feature customers care about that you already do well doesn't need more investment. Each matrix row reports as its own breakdown in the dashboard, so you get a per-area score without building five separate questions. ### Question 3 — The willingness-to-pay filter Add a **Binary Choice** or **Single Choice** question: **"Would you pay more for this?"** This question separates *nice-to-have* from *need-to-have* faster than any amount of internal debate. Features people want but won't pay for are still worth building sometimes — for retention, for positioning — but you should know which category you're in before you commit a quarter to it. ### Question 4 — The open request Add a **Long Answer** question: **"What's missing that we didn't list?"** Your list of candidate features reflects what you already thought of. This question is the only place a genuinely new idea can enter, and it's where the write-ins that appear over and over become next quarter's obvious priority. ### Question 5 — Who's asking Add a **Single Choice** question for segment (role, plan, company size, customer tenure — whatever distinguishes your customers). *** ## Where to run it * **On-site to active users** — Use [Targeting Settings](/polls/targeting-settings.md) to reach people with enough product experience to have a real opinion. * **Email to a specific segment** — Run it separately against power users and casual users. Their rankings usually diverge sharply, and knowing that is more valuable than the blended result. * **Triggered at a milestone** — Fire it after a customer's tenth session or third order with a [Custom Survey Trigger](/tutorials/custom-trigger.md). * [**Synthetic Research**](/synthetic-research.md) — Pre-test the wording of your feature descriptions before real customers see them. An ambiguous feature name produces a meaningless ranking. *** ## Reading the results **Segment before you decide.** A blended ranking is an average of groups that want different things, and it frequently points at a feature that nobody's top segment actually asked for. The question to answer is not "what did customers rank first?" but **"what did our best customers rank first?"** Cross-reference the ranking against: * **Revenue** — Zigpoll correlates order values with responses automatically, so you can weight the ranking by what respondents actually spend. * **Churn risk** — Compare against your [cancellation survey](/guides/how-to-reduce-churn-and-cancellations.md) answers. A feature that appears in both the "would build" list and the "why I left" list is unambiguous. * **Product-market fit segment** — If you've run the [PMF survey](/guides/how-to-measure-product-market-fit.md), prioritize what the "very disappointed" group ranks highly. Those are the customers you're building for. Ask Z-GPT Chat in the **Insights** tab to break the ranking down by segment, or export from the **Table** tab and pivot it yourself. *** ## Close the loop Publish what you decided and why. Customers who took the survey and then watch their top-ranked item ship become the people who answer your *next* survey. Use the collected emails and a [Klaviyo](/integrations/klaviyo.md) or [Mailchimp](/integrations/mailchimp.md) Question Logic action to build that list as you go. *** ## Related {% content-ref url="/pages/Cpctg3qiKtbrlvPfaYLD" %} [How to Measure Product-Market Fit](/guides/how-to-measure-product-market-fit.md) {% endcontent-ref %} {% content-ref url="/pages/enRwROsoKeKFUh7XMOOp" %} [How to Validate a New Product Idea](/guides/how-to-validate-a-new-product-idea.md) {% endcontent-ref %} {% content-ref url="/pages/YFzREtUZcgu9ROgx8E6b" %} [How to Reduce Churn and Cancellations](/guides/how-to-reduce-churn-and-cancellations.md) {% endcontent-ref %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.zigpoll.com/guides/how-to-prioritize-your-product-roadmap.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.