How to Migrate Productboard Requests to Feedbackly
Export selected Productboard features, map titles and descriptions, and pilot a Feedbackly board. Preserve research and planning records outside the public import.
By Feedbackly · Updated
Product walkthrough
Watch how requests, votes, discussion, and status updates work on a Feedbackly board.
Watch the product walkthroughExplore the public feedback workflow
Practical context for How to Migrate Productboard Requests to Feedbackly
Migrate selected Productboard request text to Feedbackly by exporting the relevant features, mapping their names and descriptions to a two-column CSV, and reviewing a small import. Decide separately where customer research, planning hierarchy, and delivery records will remain. A public request board does not recreate the whole product management workspace.
Start with the process you want to move: collecting public suggestions, discussing the underlying need, voting, and communicating status. Feedbackly has one board owner and public customer participation. Check shared administration, private research, and required planning capabilities before committing to the destination.
Export the selected features with descriptions
Productboard's export documentation requires maker or admin access. For a subset, open a grid board, set the relevant filters and columns, and choose Export as CSV from More actions. Include item descriptions when needed, then follow the export email to download the file. Open it and verify the intended records.
Keep a source export and a note of the filters used. Choose items that represent customer-facing problems rather than copying every component or subfeature into a flat board. A parent initiative and its delivery tasks may need different destinations; preserve the source hierarchy in an internal planning record where it remains useful.
- +Use authorized export access for the selected workspace.
- +Verify descriptions are present, not just feature names.
- +Retain the original identifiers and hierarchy outside the public import.
Rewrite internal planning labels as customer problems
Create an import copy with explicit title and description headers. Map the source feature name to title and its suitable public summary to description. Do not paste private research, customer contacts, revenue details, or internal notes into a public description. Keep those records in the appropriate internal system.
For example, the fictional planning item 'Reporting workstream phase two' does not tell a customer what problem is being considered. 'Share a scheduled weekly report' is more useful when its description explains the recurring task and current manual workaround. Preserve the original planning label in your internal mapping rather than presenting the rewrite as a complete transfer of context.
title,description "Share a scheduled weekly report","Workspace administrators repeatedly prepare and send the same report to colleagues." "Explain failed imports","Users need an actionable reason when a valid-looking file cannot be imported."
- +Keep one public problem per request.
- +Separate customer evidence from implementation tasks.
- +Review the rewritten summary with the person who owns the original decision.
Pilot the public workflow and retain the planning archive
In Feedbackly board creation, choose CSV, paste the prepared text, and preview up to 100 requests. Titles must be at most 120 characters and descriptions at most 5,000. Inspect and edit each pilot record, deselect unsuitable content, and confirm only the requests intended for publication.
Imported requests start under review with zero votes. Prior statuses, customer identities, comments, attachments, research relationships, and product hierarchy are not recreated automatically. Test customer submission and status communication, and document where the retained evidence and delivery planning live. Change public links after those checks pass; do not assume a successful import justifies retiring the wider planning system.
- +Compare selected source records with the published pilot requests.
- +Assign ownership for the public board and the retained research archive.
- +Explain the new feedback path and how to ask about historical requests.
Keep exploring this topic
These next reads help you move from the concept on this page to a framework, tool, template, or deeper comparison you can apply right away.
Questions teams usually ask
Can Feedbackly import the entire Productboard workspace?
No. This workflow imports selected request titles and descriptions from a prepared CSV. It does not recreate product hierarchy, private insights, customer relationships, or delivery planning.
Why should I rename exported columns?
Explicit title and description headers make the intended mapping clear. Do not assume a source-specific feature-name column or extra planning fields will be interpreted correctly by the destination.
Will our existing roadmap statuses survive?
They are not migrated automatically. Imported requests begin under review. Retain the source state and decide which public statuses should be set after the pilot.
Try the public feedback part of your workflow
Preview selected requests in a Feedbackly trial and evaluate customer participation and visible status updates alongside the planning systems you still need.