How it works
How ProductLift works: feedback to roadmap to changelog
One request. The whole lifecycle. See exactly how a customer request travels from capture to shipped, notified, documented.
The six stages of the product feedback workflow
Every ProductLift customer walks through the same loop. Click any stage to jump to the mechanics.
1. Capture
Requests land as posts
Board, widget, email, sync
2. Organize
Sections, tags, fields
Context stays with the post
3. Prioritize
Score what ships next
RICE, ICE, MoSCoW, AI
4. Sync
Two-way to engineering
Jira, Azure DevOps
5. Ship & notify
Voters hear about it
Email, in-app, changelog
6. Document
Help article, drafted
AI-drafted KB entry
Stage 1 · Capture
Every request becomes one post
A ProductLift portal is the single inbox for what customers ask for. Requests can arrive four ways: through a public feedback board on your own subdomain, through the embedded widget you drop into your app, by forwarding a support email to your portal address, or by webhook from Jira and Azure DevOps.
Whichever door they use, they become the same object: a post with a title, description, the requester attached, and a vote count that starts at one.
Boards can be public, private, or gated to a customer group. Voting can require login or be zero-friction. The portal lives on your subdomain by default and moves to your own domain when you want it to.
Bulk CSV export
Submitted via widget · Maya K.
▲ 1 vote
SSO for customer portals
Forwarded from support@ · Aurora Systems
Salesforce integration
Public board submission
Stage 2 · Organize
Context travels with the post
A raw request is not enough to make a call on. Sections group posts by product area. Tags mark cross-cutting themes like enterprise, security, or trial-blocker. Custom fields carry the account, MRR, plan, or CSM note that decides whether a request matters or is noise.
Because the metadata sits on the post itself, you can filter the backlog by "enterprise accounts on Growth plan" and see what those customers are actually asking for, without leaving the tool.
When two requests are the same idea in different words, merge them. Votes and requesters combine into one post, and both original submitters stay on the notification list.
Stage 3 · Prioritize
Decide what actually ships next
Every post has a score column you control. Pick RICE, ICE, or MoSCoW as the scoring model, or run all three side by side. Reach, impact, confidence, and effort become numbers you can sort the backlog against.
When manual scoring is too slow for a backlog of hundreds, the AI scorer reads each post against the product vision you set once, and returns a strong-fit, review, or weak-fit signal. It is a second opinion, not an autopilot. The final call and the drag-drop reorder are yours.
The product management workflow that actually happens here: sort by RICE, filter to enterprise accounts, sanity-check against the AI fit score, drag the top three into the next release. Repeat on cadence.
SSO for customer portals
Linked to PROJ-142
Stage 4 · Sync
One backlog, two systems, no double entry
Product picks a roadmap item and links it to Jira or Azure DevOps in one click. That creates the engineering issue, sets its priority, and drops the ProductLift link into the ticket description.
From that point on, the sync is two-way. Status changes on the Jira ticket update the ProductLift roadmap item. Priority changes on the ProductLift side update the ticket. Nobody has to maintain the roadmap in two places, and engineering keeps working where they already work.
The link stays in place through the whole build. When engineering marks the ticket done, ProductLift can move the roadmap item to Shipped automatically, which is what triggers stage five.
Stage 5 · Ship & notify
One status change, three things happen
When the roadmap item moves to Shipped, ProductLift fans out to the whole voter list. Every requester gets an email that says the feature they asked for is live. The in-app What's New updates for logged-in users. The public changelog on your own domain publishes a new entry with the release title, description, and any tags.
You did not have to write an announcement email, keep a separate changelog site, or match up "who wanted this" against "who to tell". That work is the status change itself.
Voters who no longer want updates can unfollow the post in one click. The rest see that you shipped what they asked for, which is the difference between "we heard you" and a black hole.
Status change
128 requesters notified: Bulk CSV export is live
Bulk CSV export
Export any board as CSV, with all custom fields and vote counts.
In-app What's New updated for signed-in users.
How to export your data as CSV
Bulk CSV export lets you download any board as a spreadsheet, including every custom field and the vote count on each post. This article covers where to find it, what gets included, and how to schedule recurring exports.
Sections drafted: Where to find it · What's included · Scheduling exports · Permissions
Stage 6 · Document
The help article writes itself
Shipping a feature and forgetting to document it is how support queues get long. When the changelog entry publishes, ProductLift drafts a knowledge base article from the release description, the original post, and the comment thread that produced it.
You edit and publish it. It goes live on your knowledge base, on your own domain, indexed and searchable. Existing KB articles can also be resynced when a feature changes, so the docs do not drift out of date the moment the next release ships.
That closes the loop. The request came in, got scored, got built, got announced, and now the answer to "how do I use it" is in the same product family as the request itself.
What connects the stages
One post, one history, one voter list
The six stages above are not six tools glued together with Zapier. Every stage acts on the same object: the post. The vote count on the board, the score on the prioritization view, the linked Jira ticket, the changelog entry, and the knowledge base article are all facets of one row in one database.
That is why the notification list at ship-time already knows who to email, why the changelog entry already knows the release description, and why the KB draft already knows what the feature does. The context was there from stage one.
AI and the MCP server sit on top of this single object model. They accelerate the human stages (scoring, drafting, answering "what did we ship last quarter") without adding a second source of truth.
Where you can start
You do not have to adopt every stage on day one. Pick the problem you have today.
Just need feedback?
Start with a public feedback board on your subdomain. Voters, comments, tags, custom fields, moderation.
Explore FeedbackJust need a roadmap?
Publish a public roadmap on your own domain, with two-way Jira or Azure DevOps sync so nobody maintains it twice.
Explore RoadmapFull loop?
Run all six stages in one system: capture, organize, prioritize, sync, ship, document. Voters hear back.
Explore the loopThis tool is literally a needle in a haystack. I was using Frill, and this doesn't even compare. The user interface, the way it lays out is amazing. Also amazing support team.
Timothy M.
Product Manager · switched from Frill
See the loop in your own product.
A free trial gives you a portal on your subdomain, unlimited voters, and every stage of the loop from day one.