Feature Waitlist Form Template
A waitlist for one upcoming feature. It captures current workarounds, use cases, and who will tolerate rough edges to get it early.
This feature is coming, and it will roll out account by account. Tell us how you'd use it and how you cope today, and we'll know exactly where you belong in the rollout.
The feature flips on per account, so this is how we find yours.
Inside an existing product, a feature waitlist is prioritization evidence with names attached. "Lots of people want this" moves no roadmap; two hundred named accounts with their workarounds and use cases on file moves budgets. This template is built for that second kind of signal, and it doubles as the staged-rollout list you'll need the week the feature ships. SaaS teams reach for it with a public roadmap and a "coming soon" badge, plugin and API developers sequencing a breaking addition, platform teams sizing an integration before committing a quarter to it, and product managers who would rather bring receipts than adjectives to planning.
Evidence with names attached. The account email is the join key, and the description says why out loud: features flip on per account rather than per inbox, so the label asks specifically for the address on the account, the single wording change that saves you a matching headache at rollout time. The workaround question is a severity meter in disguise. "A spreadsheet or script I built myself" and "a second tool on the side" are churn risk wearing a costume, those users are already paying a competitor or their own time for what you haven't shipped, while "I don't" marks pure unserved demand. Sorted by that column, your waitlist becomes a priority argument no opinion can beat. The use-case paragraph is design input: where the feature sits in someone's week determines defaults, entry points, and what the empty state should say. The rough-edges question quietly recruits your flag-flip cohort, a self-selected group who asked for the unpolished version, which is a better early-access pool than any hand-picked list.
Skipped by design. Vote counts and one-to-ten priority scores (self-scored urgency measures enthusiasm for scoring; the workaround answer measures cost being paid), delivery-date promises in the copy (the ending promises to tell you when it ships, without naming a date), and multi-feature checklists. One form per feature keeps every signal attributable.
Placing and routing it. Link the form from the roadmap item and the changelog post, or open it as a popup embed inside the app right where the feature will eventually live. The hidden origin_page field takes a value per placement (?origin_page=changelog versus ?origin_page=settings), so you learn which surface recruits the most desperate users. A webhook can push each signup into your tracker with the workaround answer attached for automatic severity tagging, and the CSV export joins cleanly against your account list by email. When the feature ships, invite the rough-edges volunteers first, watch a week, then release the rest of the list.
Receipts beat roadmap debates. The next time prioritization gets contentious, export this list and sort by workaround. It is very hard to argue with two hundred accounts running spreadsheets against you.
Frequently asked questions
Where should this form live so users actually find it?
Behind the "coming soon" badge on your roadmap, in the changelog post, and as a popup embed inside the app near where the feature will appear. All three share one response list.
Can signups flow straight into our issue tracker?
Add a webhook and each signup POSTs in real time, signed and retried if your endpoint blips. The workaround answer rides along for automatic severity labels.
How do we match waitlist entries to real accounts?
The form asks specifically for the email on the account, and the CSV export joins against your user list on that column, so the label wording is doing the data hygiene for you.
Who should get the feature first when it ships?
Filter for the rough-edges volunteers and flip their accounts first, since they opted into imperfection. The responses view keeps them one filter away from the cautious majority.