Feedback uses status updates to communicate where a request is in the product development lifecycle. You don't have to use the default status names provided by Pendo Feedback. Each status has a specific function within Feedback, and so the lifecycle of a request will stay the same, but you can rename the statuses to suit your organization’s language.
This article provides instructions for renaming your statuses and offers some guidance based on an established process for triaging requests in Feedback. For more information, see The Feedback Workflow. For information on how to change the status of a request, see the Request status updates article.
Your Feedback Workflow – in particular, the review and triage phase – affects how you phrase statuses. Before you rename your statuses, you must decide what workflow makes the most sense for your teams and clearly document this process in your Product Feedback Policy. We highly recommend adding a link to your policy in your communication with submitters.
For consistent messaging across product lines, ensure internal alignment on what each status means and in what situations they're used once you create a clearly defined workflow.
Step 1. Establish a review and triage process
How you name your statuses depends on your Feedback Workflow, and especially your review and triage process. To establish a review and triage process, you must determine:
- Who's responsible for which Product Areas.
- Who will review the requests that correspond to your Product Areas.
- Whether you'll have a dedicated product owner or Feedback manager that owns and triages the account.
For more information on creating a Feedback Workflow, including setting up a review and triage process, see The Feedback Workflow. For more information on setting and using Product Areas, see Product Areas in Feedback.
Step 2. Define your statuses
This section offers best practice advice for renaming your statuses based on how they’re defined in your review and triage process.
The Not Reviewed status indicates to your users that a request hasn't yet been reviewed, and lets your teams know that it requires a response.
Common alternative names for this status include: Awaiting Review and New. However, these status names imply that you review all requests regularly and that action will be taken on your part.
If you get large volumes of feedback, you can do the following:
- Leave new requests in this initial status until they've received enough votes and rename the status to set different expectations with users. For example, you can rename the status to Open for Voting, rather than Not Reviewed.
- Bulk update request statuses to Awaiting Feedback, or your organization's language for this status, along with a saved custom message to set high-level expectations based on your Feedback Workflow.
The Awaiting Feedback status indicates to your users that you've received their request and that you're gathering more data before making a decision. It lets people know that you're gauging demand, and that the request is open for voting and comments.
You don't need to check in on these requests every day. You can treat all requests in Awaiting Feedback as a library of data, stories, and use cases that you can revisit when you're ready to work on a product. Feedback can remain in this status for long periods of time, and so it can make sense to rename it.
Common alternative names for this status include: Open for Voting, Acknowledged, and Gathering Data. To provide clarity, we recommend that you set a response for this status and include your Product Feedback Policy in this message.
We recommend a cautious approach to using the Planned status. Use it only when you know you will definitely build something, and you’re confident enough to represent it on a roadmap.
If you choose a less definitive meaning for this status, you can rename the status to clarify what it means. You might, for example, be interested in researching an idea and then deprioritize the idea based on your findings. In this case, it might make sense to rename this status to In Discovery. Alternatively, an idea might align with your vision, but not be a priority. In this case, you might want to rename the status to Aligns to our Vision.
Whichever purpose for this status you choose, ensure your teams use the status consistently and that its meaning is clear to your users. Common alternative names for this status include: Aligns to our Vision, Committed, and On the Roadmap.
We recommend you provide more information about this status with a status message, including a link to your Product Feedback Policy.
The Building status lets people know what you're currently working on. Only use this status when your developers have started work on something, and know that your users will eventually be able to use the resulting feature.
We recommend that you move all related requests to this status even when they don't correspond exactly to a feature you’re building but do solve the same pain or meet the same need. We also recommend that you provide this context in your status response.
As stop-gap between Planned and Released, common alternative names for this status include: In Development, In Progress, and Under Construction.
The Released status indicates that you've implemented a request into your product. Use this status when engineers have finished work on a feature and you want to let people know that the feature is available. You can also use this status when you get a request about a feature that already exists.
In either case, we recommend that you customize your status response to educate users and drive adoption. Explain what the feature is, where it can be found, and how to use it.
Common alternative names for this status include: Done, Delivered, and Available.
The Declined status indicates that you don't plan to implement a request. This might be because a request is not aligned with your product vision, because you can offer a work-around already, or because the request is a bug rather than an idea or suggestion.
Regardless of the reason, we recommend:
- Transparency with your users when you know you can't or won't build a feature.
- Adding as much detail as you can in your status response about why you don't see the value in a request.
- Not deleting requests that you've declined. If one user has enquired about a feature, it’s likely other users have the same experience and demand.
Being transparent with declined requests has several advantages:
- Setting you up for scale. Help all your customers understand what your product vision is and why you might not be investing in certain product areas or problem spaces. If it’s good for one user to know, it’s likely helpful for other users too.
- Reducing friction. Users prefer to know if something definitely isn’t being built. Get stakeholders on your side by explaining your decision-making, and drawing attention to areas you are investing in instead.
- Continued data collection. By allowing continued discussion, you leave yourself the option to reconsider a request if it suddenly resurfaces and gets a lot of traffic.
Common alternative names for this status include: Closed, Not being considered, and No Action.
Step 3. Rename request statuses
Warning: After following this process, statuses will be visible to anyone with access to Pendo Feedback, including your users if you've given them access.
To rename request statuses in your Feedback account:
- Navigate to Settings > Product Settings > Custom Request Statuses.
- In Custom Request Statuses, edit your status names according to your Feedback Workflow.
- Select Save Changes.
- In the confirmation window, select Confirm & Apply.
It can take a few seconds for your status name changes to take effect across the app.