Following on from the deep-dive into Product Ideas/ Feature Requests Forms & Workflows, and the nuances of how this simple function can support changing behaviours and embedding new ways of thinking in colleagues, this article was born.
Alongside this, I have seen with increasing regularity recently, requests for recommendations and reviews of product ideas facilities and management tools.
With my Product Ops Hat of Efficiency (kinda like a poor-mans Sorting Hat from Harry Potter fame!) on, I wanted to provide a place for both incumbents and up-and-coming platforms in this space to get some screentime, with some warts-and-all reviews. These reviews, however, are provided by real users and professionals who have implemented the platforms successfully - so no sales pitches, no marketing BS. Crowd-sourced reviews, asking the following questions:
The unique challenges to solve
The approach & what was delivered
How the product added value to those submitting requests, and to those receiving the requests
Pros
Cons
Here is what is reviewed in this article:
aHa! Ideas - by Justin Woods
Jira Product Discovery - by Suryansh Dhingra
SalesForce Custom Objects - by Damien Harr
UserVoice - by Jana Debusk
LaunchNotes - by Chelsea Grint
VersionLens - by Feras Wilson
ProdCamp - by Mike Walters
ProductBoard - by Christopher Fox
ClickUp - by Graham Reed
Enjoy!
aHa! Ideas
Reviewed by: Justin Woods - Consultant and Roadmapping Expert at Roadmap Heroes
The unique challenges to solve
The client had a specific need to:
Capture external requests from customers as well as internal ideas from employees
Centralise idea management and consolidate tools / processes
Improve transparency of product development process and provide timely communications
The approach & what was delivered
The client was already using Aha! Roadmaps which includes Aha! Ideas Essentials.
Our approach:
Understand the problem, the existing systems, and define the future state
Establish processes for handling new ideas, enhancements, defects, and support requests.
Determine which teams will handle specific types of requests and in which system
Configure Aha! to meet the defined process and migrate records to new system
Conduct training sessions for employees to ensure a smooth adoption of the new system
What we delivered
Implemented a public ideas portal to capture customer requests with mandatory fields to ensure key information is collected:
What is the problem? – trying to get out of solution mode
When (ideally) is it required? – rough indication of urgency (week, month, quarter, year)
How many users would benefit? – rough indication of reach
Enabled employees to submit ideas directly into Aha!, capture additional company-specific information such as business case,
impactopportunity size, and return on investment
Enhanced integration between ideas management and product management
Introduce guideline timings and SLAs for idea management including how updates and communications should be handled
Retired the standalone website-driven portal and imported existing records into Aha! Ideas
How the product added value to those submitting requests, and to those receiving the requests
Value to those submitting:
Provided a simple, branded portal experience for ideas and request submission
Clarified user journeys on how to get help for different types of requests (support, defects, new requests, enhancements)
Set expectations for idea management process and timings
Automated communications for important updates such as idea votes, comments and status changes
Value to those receiving:
Centralised system for all ideas (customer and employee), integrated with Aha! Roadmaps), retiring the old system
Mandatory fields ensure all necessary information for idea evaluation is complete
Consistent prioritisation of ideas based on scoring, value, and alignment to goals
Idea statuses set expectations without committing to delivery timescales
Dynamic reporting for improved idea management and stakeholder updates
Pros
Unlimited idea portals and portal users
Reasonable pricing model (you pay for idea management users not the number of idea portal users)
Highly configurable portal / in-app experience with branding options
Cons
Can’t send ideas directly to a development tool (JIRA, ADO etc.) unless you also use Aha! Roadmaps
Can’t integrate with some popular CRM / support tools e.g. Hubspot, Intercom
Jira Product Discovery
Reviewed by: Suryansh Dhingra - Product Operations Lead at Nord Security
Unique challenges to solve
In my role as a Product Operations Lead for a Product Organization that develops a single product across multiple platforms (Windows, MacOS, iOS, Android, etc.), we face unique challenges that we aim to address using Jira Product Discovery (JPD). Our organization also has shared Data, Design, and Product Operations functions across all these teams. We operate under yearly OKRs, which are executed through quarterly roadmaps. Here are the specific challenges we aim to solve with JPD:
Consolidate Requirements from All Stakeholders: Previously, requirements lived in silos, making it difficult to get a comprehensive view. JPD provides a cross-platform layer that consolidates these requirements, ensuring that all stakeholder inputs are gathered in one place.
Consolidate Ideation: Ideation used to happen in various siloed tools such as Google Sheets and different Jira instances across platforms. JPD helps in consolidating all this ideation into a single tool, streamlining the process and making it more efficient.
Unified Ideation and Prioritization: JPD allows us to bring ideation and prioritization together in the same tool, facilitating a smoother workflow from idea generation to prioritization.
Macro and Micro Roadmaps: Creating both Macro (Product Organization level) and Micro (Platform level) roadmaps to share with stakeholders is essential. JPD enables the development of these roadmaps, ensuring that all stakeholders have visibility into the product's progress and future plans.
End-to-End Linkage: Ensuring end-to-end linkage is crucial. JPD allows us to link Objectives -> Key Results (Jira OKR Board) -> Initiatives (JPD) -> Delivery (Jira) -> Impact (Jira & OKR Board), providing a seamless connection across all stages of product development.
The approach & what was delivered
To address these challenges, we implemented the following approach using JPD:
Training and Support: We conducted training sessions for all stakeholders to ensure they understand how to use JPD effectively. Ongoing support is provided to address any issues and ensure the tool is used to its full potential.
Centralized Repository for Requirements and Ideas: We set up JPD as the central repository for all requirements and ideas. It worked very well from a requirement gathering perspective and will also allow us to create a transparent & passive tool to create a consolidated backlog. Also, we’re not missing out on any ideas and have the ability to say no to ad-hoc requirements with much more confidence.
Streamlined Ideation Process: By utilizing JPD's features, we established a standardized ideation process that includes idea submission, discussion, and prioritization for all platforms, leading to unified direction of the product org rather than siloed platform development.
Development of Roadmaps: Using JPD, we created detailed roadmaps at both the Macro and Micro levels. These roadmaps are auto-updated as they are linked with Jira delivery epics / tasks.
Transparent Development: Now, the delivery of the roadmap for the whole product org can be tracked in one place for any stakeholder to view, providing transparency and aligning everyone on the progress. Reduced the “what’s happening in X initiative?” questions a lot.
How the product added value to those submitting requests, and to those receiving the requests
For those submitting requests, JPD provided a centralized platform where they could easily submit and track their ideas and requirements.
For those receiving requests, JPD offered a streamlined process for managing and prioritizing these inputs. The consolidated view and linkage to delivery tasks made it easier to picture everything on the same level.
Pros
Integration with Jira: JPD is an excellent tool if Jira is your primary workhorse, as it integrates seamlessly with other Jira products. This integration allows for smooth transitions between different stages of product development.
Customization: JPD is highly customizable in terms of fields and options. This flexibility allows us to tailor the tool to our specific needs and workflows.
Filtering, Sorting, and Views: JPD offers a fine assortment of filtering, sorting, and views. This makes it easier to project the exact view you want depending on the audience you are sharing it with.
Cons
All fields or nothing when creating an idea: JPD currently has the inability to allow you to choose specific fields to be mandatory and others as optional, when a stakeholder creates an idea. It’s either all are ‘required’ or everything is ‘optional’.
Merging Similar Requirements: Merging similar requirements is not an option in JPD. The two options we have are:
To actually create a new one and then cross-linking them (crowds all views).
Changing one while deleting the others, with a large scope of human error.
Splitting Multi-Team Requirements: JPD lacks nested views, which can make it difficult to manage multi-team requirements. This limitation can be a hurdle when trying to split and manage tasks across different teams, where we have to end up duplicating them and then linking them across the board. Very messy, especially in the Roadmap view where we have duplicated requirements floating around across teams with different timelines.
Not being able to restrict changes to a view: While we want most updates / changes to be tracked across all views within JPD, there are some that we would like to restrict to a specific view. Can’t be done yet, the only way out is to create isolated fields for different views.
Permissions: Permissions in JPD can be tricky and not being able to edit your own idea as a “Contributor” is a pet peeve of mine. While we want all stakeholders to be able to create and edit their own ideas and requirements without, this requires a paid license. This can be a significant cost factor, especially to include teams like support/marketing / legal who do not have a larger use for JPD outside of our product org.
SalesForce Custom Objects
Reviewed by: Damien Harr - Technical Program Manager at Twilio
The unique challenges to solve
Our Product team was lacking a single lens of solution gaps, product feature requests, or enhancement requests gathered from Pre-Sales, Post-Sales, and Support. This led to disparate guidance for Product Managers on where to find valuable information when producing their quarterly and annual roadmaps. And perhaps more importantly, cross-functional teams had reduced, or in some instances stopped, using the tools due to lack of visibility or action taken against them, completely cutting off a critical source of Voice of the Customer data.
The approach & what was delivered
To combat this, I set out by establishing goals for a new program, highlighting the challenges in front of us as an organization. The goals were:
Identify, publish, and qualify customer product request data for Product Managers across all product pillars
Product Managers can trust the data to be complete and accurate
Product Managers can make informed decisions to support their Quarterly and Annual Product Roadmapping
The Go-To-Market team and their Customers remain informed through notification feedback loops creating a clear and unambiguous communication channel
The tool we landed on was a custom object built into our Salesforce instance for Feature Request intake. The combination of flexibility and cost to implement made it the most attractive solution for our company, having already invested a lot in establishing a Salesforce ecosystem.
How the product added value to those submitting requests, and to those receiving the requests
The primary advantage to using a Salesforce custom object was to remove any complexity and barriers for our friends in Go-To-Market to submit and prioritize feature requests based on direct customer feedback. Account Reps, Solutions Architects, and Customer Service Managers spend much of their time in Salesforce tracking their customers’ health, opportunities, and contracts. “Meet them where they are” was a phrase I used early and often when mapping out the program.
The largest advantage to using Salesforce is the easy access and integration of the wealth of customer data already captured in Salesforce. The ability to seamlessly tie in Account ARR, upcoming contract renewal dates, churn risk, etc. help form a complete picture to the feature request that’s invaluable when considering what Product needs to focus on next.
This approach can also lead to an influx of new requests, so it’s just as important that the follow up by Product is seen as swift and comprehensive. Customer feature requests that are never reviewed and never prioritized do nobody any good, so developing a cadence for review and response, along with a comprehensive scoring and prioritization framework, was critical to the success of our product feature request program.
Pros
Custom designed interface means you can tailor the intake data to capture exactly what you need for your organization.
The ability to directly tie the request to important customer data, such as ARR, Customer Health Score/NPS, contract renewal dates, etc. provides powerful metrics with very little effort.
Easy access in a familiar tool for the people working with customers and capturing requirements every day (meet them where they are). CSMs, AEs, Sales Engineers are all working in Salesforce already.
Native reports and dashboards are relatively straightforward to create. And it’s relatively simple to bring the data into Tableau/Looker/Power BI/etc. to run more robust analytics.
With a wide variety of Salesforce plug-ins, you can extend the functionality in a number of ways (e.g. we published automated biweekly emails digests to the Product org with the latest submissions for PMs to easily review using a plug-in). There’s a Jira plug-in to allow users to look up existing feature request tickets.
Salesforce workflows allow for dynamic intake based on product area/team as well as prioritization.
Cons
Requires a company-wide adoption of Salesforce.
Additional licensing costs for Product users.
Custom objects require internal support to build/maintain/revise functionality.
Longer lead-time to implement, depending on level of in-house Salesforce developer knowledge.
Upgrades to Salesforce may break custom objects/integrations.
UserVoice
Reviewed by: Jana Debusk - Senior Manager Product Operations at Playvox
Note from Jana: Although I wasn't involved in the initial implementation of UserVoice, I worked extensively with it when I joined the Product Operations team and now own the tool.
The unique challenges to solve:
Working in a start-up environment, we needed a solution that was simple and straightforward for both our customers and our team. We didn’t have unlimited resources and needed a way for our customers to quickly and easily submit their feedback and ideas directly to the product team (without hopping on a million discovery calls). UserVoice was centralized and efficient. It allowed us to simply get the job done which is exactly what we needed at the time.
The approach & what was delivered:
Though it would be most widely used by our Product and CS team, we decided to roll out UserVoice more broadly to our entire team. We provided enablement internally, and a Help Centre article detailed the what, why, and how for our customers. Due to customer preference, we made the Idea Portal accessible by invitation only which allowed a centralized way for POCs to submit and vote on the most crucial ideas for their business cases. Our team can also contribute ideas on behalf of our customers using the Contributor Portal. Once an idea is submitted, other customers can vote on it, and our product team reviews it. They then label it with one of the following status tabs:
Acknowledged - A Product Manager has read the idea and is waiting for more votes from other customers.
Under Review - A Product Manager is investigating the idea in detail and determining if we should move forward with development.
Prioritized - The Product Manager has determined that the idea should be developed. The idea is now in line for development.
Planned - The idea has been slated for development.
Started - The product team is actively working on the development.
Completed - Development is complete and the item is released in production.
Deferred - A Product Manager has determined that we will not develop the idea at this time.
There will be comments from the Product Manager explaining the decision. Most recently, we’ve connected the UserVoice idea portal to their roadmapping tool which not only allows customer ideas to be directly linked in feature cards, but it also builds trust with our broader team.
How the product added value to those submitting requests, and to those receiving the requests:
Because of its simplicity, it was adopted quickly by our customers and team members which means more engagement all around; more ideas got submitted, every idea got looked at, and our product team was able to gather feedback, analyse, and prioritize more effectively. It also enabled our Product managers to streamline customer communication by sharing personalized updates to everyone who voted on an idea.
Furthermore, this tool became a great talking point in customer meetings. We like to celebrate how many ideas they’ve submitted as well as how many we’ve been able to build. We can quickly glance at our customers’ most critical needs by prioritization they chose: Not at all important, Important, or Critical. I’d say customer engagement and transparency have been the biggest wins with this tool.
Pros
Intuitive process for gathering and utilizing feedback
Economical
Easy to add branding (logo, colours, subdomains)
Constant enhancements in the product
Idea portal connects to roadmap and integrates with Jira so there’s a great holistic view of the idea from start to finish.
Cons
Reporting is lacking depth and not easy to use (at least in the basic package)
Lack of integrations
Lag issues
While the idea portal seems to fit our needs for the most part, the connected roadmap has a lot of feature gaps. It’s hard to optimize the
LaunchNotes
Reviewed by: Chelsea Grint - Product Communications Specialist at BuilderTrend
The unique challenges to solve
A customizable Kanban style board, for easy digestion of what releases are in progress, in early adoption or recently released.
Roadmap cards that could include different font sizes, images or videos and links.
Separate roadmaps for our internal and external stakeholders, and ways to communicate what’s new.
The ability to gather feedback on specific roadmap cards, especially for releases in early stages of development. In 2022 we moved from Waterfall to Agile – feedback on current projects is instrumental for quick iterations as we release small slices.
The approach & what was delivered (Also includes value to different audiences)
Our internal product roadmap is for an all-company audience. Each roadmap card provides a summary of what’s changing in the program, the customer value, the company value (including what quarterly initiatives and yearly goals the release is tied to), and links to additional internal resources if people want to dive deeper.
As the Product Operations Communications Specialist I work directly with Product Managers to ensure I have the release information I need to publish the roadmap cards. I use LaunchNotes’ Announcements for a weekly Wednesday recap of roadmap card movement, and we have an all-company Product monthly newsletter where I provide links to the roadmap or specific roadmap cards.
This has been valuable for our Customer Success, Sales and Marketing teams along with Corporate Communications and leaders in departments outside Product. Everyone can stay up to date, vising one main source of truth for what’s coming in the next quarter.
---
Our public product roadmap is for our customers, written for that specific audience, in our brand voice. We simply provide what’s changing in the program, how it will be valuable to them, and ways they can provide feedback or learn more.
After I have the internal roadmap card approved by the Product Manager I write a customer-facing roadmap card and submit it to Marketing for copy edit and approval. I use LaunchNotes’ Announcements for a weekly Friday recap of roadmap card movement. Marketing uses public roadmap card links in their monthly customer newsletter or on in-program Intercom messaging.
We have a little over 5,100 subscribers. We see an average of 100 new subscribers each month and we have an average ~55-60% open rate of weekly roadmap recap emails. This has been valuable for our clients who want to provide feedback and want to know every single change that may affect their workflows.
Our Customer Success team directs traffic to the roadmap. Be it email, e-chat or phone, if a customer has feedback or a suggestion they are encouraged to leave it on our roadmap.
---
We found that a weekly update works best for our communication style, because stakeholders know it’s coming on a certain day and time, and they aren’t inundated with multiple messages when we have multiple changes in the same week. LaunchNotes recently provided the option for people to opt into real-time movement alerts, but we aren’t using that right now.
I’ll be candid, communicating releases while working in Agile has been a challenge. We’re often delivering small updates that are foundational to a larger experience / initiative, and it’s difficult to communicate to external stakeholders that you have a grander plan in place but the “how” of the experience isn’t fully flushed out. We use a combination of having a “parent” roadmap card with multiple associated releases and we have a roadmap card dedicated to small QOL monthly updates.
Pros
LaunchNotes has great out of the box features and design so you can set up branded roadmaps without the need of a Developer or any code knowledge. With that, they also allow you to customize with HTML and CSS if you want. We did have one of our Devs change a few things on our roadmap layout, for some specific branding and page design desires. It was very easy for them to do, no more than 2 hours of work.
I love Announcements in LaunchNotes. I have templates created so my header images and sections are consistent, and I love how easy it is to connect release cards and categories. I also like the preview and that I can schedule for a later send.
LaunchNotes gives us the ability to get feedback on specific releases, and it captures the customer’s name and email so our Product crews can reach out to those customers, if they want. At a basic level, this is great.
Cons
Would love an easier way for our internal Customer Success teams to get feedback from customers into LaunchNotes. A lot of competitors have Chrome connections where our associates can highlight an email or feedback from Intercom, click the Chrome extension and it will populate the customer’s information from Salesforce.
In this same vein, we would love to have “forms” so all feedback, coming directly from our customers or our associates, has the same vetting information. We often get feedback or suggestions on what people want, but not the WHY behind it. People also put multiple ideas into one message, making it difficult for us to splice and assign to the right Product areas or respond to those people when we’ve solved their issue.
We get roughly 800 pieces of feedback a month. LaunchNotes isn’t the right repository for organizing and categorizing each piece into idea areas – even with their “Ideas” section, they can’t manage feedback at large scale.
The current way to close the outer feedback loop is using Announcements and tagging an associated roadmap card or category, so subscribers will be notified. You can send emails to individuals who provided feedback, but I’m not a fan of the user experience and some of the limitations.
Other competitors will integrate with Salesforce to show us a dashboard or reports for high volume feedback, including ARR and segmentation breakdowns. LaunchNotes has only a basic Salesforce integration.
Version Lens
Reviewed by: Feras Wilson - CTO at Pedal Mates
The unique challenges to solve
Before Version Lens we would end up spending a lot of time on refinement and coordination across our teams. Having the whole team aligned on our roadmap and product decisions is always a challenge.
And when it comes to receiving feature requests from our stakeholders, it's not certain that everyone knows what a good ticket should include, sometimes not even ourselves. As an example, instead of focusing on specific feature requests, my priority lies in understanding the underlying pain points.
The approach & what was delivered
Version Lens is a product intelligence platform. A co-pilot for product managers focused around automations and intelligent workflows for stakeholder communication, documenting product decisions and managing internal stakeholder requests and feedback.
In practice what this means is that Version Lens connects Slack with our task management system to make sure stakeholders are proactively kept in the loop with all their feedback collected and triaged automatically. Helping make sure our backlog is up-to-date and closing the feedback loop with stakeholders.
How the product added value to those submitting requests, and to those receiving the requests
Version Lens has made this process seamless, gathering context for us, and ensuring that all tickets we get are actionable as soon as they enter Jira.
This efficiency has significantly reduced the need for time-consuming weekly follow-ups and ad-hoc meetings, saving both myself and the team countless hours.
Pros
Built natively in Slack to make communication easier
Asks investigative questions autonomously for requests and bug reports
Built to be easily implemented for teams using their backlog as source of truth today for planning
Due to focus on SMB, pricing is significantly cheaper
Cons
Most focus is on Slack + Meetings so fewer integrations to e.g. CRM system
Newer to the market, only allows certain customers to use full platform
Early-stage company, so not everything is there yet and you have to be open to growing with the platform
ProdCamp
Reviewed by: Mike Walters - Co-founder of Action1
The unique challenges to solve
After a successful exit with our previous venture, we were looking to get product management right from the start. Our complex technical products generated an vast amount of feedback from knowledgeable users and clients. Tracking this feedback in Excel and discerning trends to inform our product roadmap became increasingly difficult and a waste of time.
The approach & what was delivered
I started looking for ways to automate this process, realizing that refining my spreadsheet wasn't the right approach. That's when I found ProdCamp. I was immediately able to understand and implement its core basics, which allowed us to centralize feedback quickly using a public roadmap and email forwarding features.
ProdCamp revolutionized our approach, giving us the ability to track which users requested specific features and attach potential dollar values to each request based on the interested accounts' revenue.
This insight proved invaluable for prioritizing our development efforts.
How the product added value to those submitting requests, and to those receiving the requests
The impact on both our users and our business has been remarkable. We reignited so many deals that we lost before. Our customers are still surprised when they actually get an email saying, 'Oh yeah, you asked about something, you placed your upvote on that. And here you go. We released it yesterday.' They just get blown away by that.
For Action 1, ProdCamp has transformed our decision-making process. Now we know exactly what features we need to build in order to influence entire chunks of revenue. When we have a prioritization meeting, it's clear why we're working on this set of features instead of any other, and we're spending more energy exploring the 'how' instead of the 'what'.
The results speak for themselves. ProdCamp has helped us reignite dozens of deals, including one worth $40,000 in annual recurring revenue.
Pros
When looking for solutions, I found that some tools were overkill or relied on homegrown solutions. What set ProdCamp apart was that it was out-of-the-box and just works. This simplicity, combined with its effectiveness, is a major pro.
Another pros of using ProdCamp is its responsive and thoughtful team that drinks their own champagne. I appreciate that I can use ProdCamp's public roadmap to upvote features or submit requests, getting notified when requested features become available.
And for us, the ability to easily associate user emails with specific features and assign dollar weights to features are two critical aspects that differentiate ProdCamp from other solutions I've tried.
Cons
As for cons, while ProdCamp has many valuable features, the user interface could be more intuitive. I'd recommend scheduling a quick demo with the ProdCamp team to ensure you get the most out of the platform.
And while the ability to attach revenue potential to features is powerful, it's important to note that this requires accurate input and data hygiene from the user's side to be truly effective. Companies need to be diligent in keeping this information up-to-date for the best results.
ProductBoard
Reviewed by: Christopher Fox - Director of Product Operations at Dashline
Unique challenges to solve
When we set out to adopt Productboard, we wanted to solve for:
Disparate sources of truth across many tools
Disorganized and neglected feedback channels
Consistent approaches to prioritization
The approach & what was delivered
At Dashlane, we onboarded Productboard similarly to how Productboard recommends:
Setup
Migration
Maker Enablement & Training
Contributor Enablement & Training
During Setup, we configured our integrations to Zendesk, Salesforce, Gong, Satismeter, and other solutions we had already set up to work with our existing solution at Dashlane. This process involved collaboration with the owners of those tools across the organization and gave us the opportunity to start fresh with new requirements.
During Migration, I used bulk import and export options to help the process along. It wasn’t as easy as clicking a button, but it was relatively straightforward to export from the existing solution and use some spreadsheet magic to get it into a format that Productboard accepted. I used this bulk export and import option for both feedback notes and the backlog and in-flight “features” from our existing teams. It was important to rebuild a basic hierarchy that our teams could approach based on the existing solution they were used to.
On the enablement and training side, we identified champions first and worked closely with them to figure out what the biggest pain points of the transition would be. Using their insights, we were able to curate training for our organization that included predicted FAQs based on our specific context. Productboard was a massive help in training documentation and running sessions for us. Prior to the transition, we made sure to implement a rough prioritization framework for teams to follow (modified RICE in our case, with custom drivers) that fit with the old solution and Productboard to make things a bit easier.
When it came to the rest of the organization, the formula was relatively the same: identify champions from each department, go deep with them on how Productboard can help them, then scale out relevant training for those departments. For example, we met closely with customer success managers to teach them about the Customers board, the Portal, and how they can submit and follow up on feedback.
Having now been at the forefront of 3 Productboard onboardings, I have a few lessons learned that from our approach:
It’s important to identify champions across departments to help adoption along. This helps you push back against the “oh, great, another tool” narrative and identify the key value propositions for the new tool.
Keeping things simple by not trying to revamp everything in one go minimizes disruption to teams. A basic “mirroring of the status quo” approach to migration can help get things up and running faster.
The key subversive goal for a Product Operations professional in this area is to make sure the platform is as valuable as possible, as early as possible. This means getting feedback funnelled in quickly so that teams can action on that. A blank slate can be quite daunting to a team, so any pre-population is highly recommended.
Don’t be afraid of opening up a feedback channel directly to your customers! Many times, teams or leaders are wary of doing this (especially in the B2B space) because of volume or exposing strategy to competitors. While these are certainly risks, they can be easily mitigated by employing good management and auditing of the feedback intake process and auditing the portal on a regular basis.
How the product added value to those submitting requests, and to those receiving the requests
Especially for larger customers who want deeper visibility into what we’re working on, the Productboard Portal has proved quite useful. We have noticed a pretty consistent flow of feedback coming from our B2C and B2B customers, which we can attribute to our broad dissemination of the portal link: we posted on Reddit, included the link in our help centre, included it in our customer-facing folks’ email signatures, and operationalized through our support team and chat bot to let folks know they can submit feedback any time. We also added a generalized feedback email to receive any email (oh, and we set up some spam and malicious email filtering).
This success did translate into a few considerations for the product teams receiving the request: we started to get some noise. Product Operations then build automations to identify that noise, then tagged it accordingly to measure it over time. We even identified new trends around feedback for our support process itself, which was helpful and interesting!
But we didn’t stop with active feedback - we also included those “passive” channels as well. Importing closed Salesforce opportunities really helped us quantify deal loss and attribute to “features” in our backlog. Without this visibility and automation, we’d be stuck in the classic loop of spreadsheet prioritization that’s inspired by “anecdata” or an exhausting Salesforce report.
As for the feedback itself, because of the volume, our automations, the nice AI summarization features in Productboard, and some operational curation from our Product Ops team, we’ve increased the confidence in our prioritization by quite a lot. We can now pinpoint the highest trending features based on a few areas: current customer ARR, overall volume, weighted importance, and lost ARR.
Pros
Relatively easy to get started with integrations, import features, and SSO/SCIM
It’s (usually) quite snappy, even with lots of data
Once you get the hang of the UX, you can really fly around the platform (three cheers for keyboard shortcuts!)
Email notifications are actually useful!
The flexibility to create as many views and roadmaps as you want is quite a blessing (as long as you consistently audit for those “Untitled” views that get created!)
Reporting, reporting, reporting. Ahhh, so much great data in this platform! There are more advanced features I wish were present, but understanding general throughput, age of features, and efficiency is critical running a great Product organization
Cons
Filtering and swimlane options are sometimes limited, depending on if you’re in a roadmap, a feature board, or an insights board
Some UX takes a while to get used to. For example, you won’t find a save button in any text fields, but you better not forget to save the board filters!
Permissions were sometimes a little wonky to get set up when we were starting out. By default, views were private, so folks would create something, send a link, and others couldn’t access this. Productboard has since set the default for most views to be open, but we haven’t stopped considering permissions every time we create something
It’s a hard sell to executives. This is true of any tool, but when they saw their first Productboard roadmap, they immediately wanted some slides. My advice to folks is to ease into it - don’t create the perfect roadmap on day one. Start with enabling folks through training and Q&A, even your executives!
The API can sometimes be limited if you’re trying to do some advanced things. It’s relatively new, and still useful for most cases, but doesn’t cover all the bases. For example, you won’t be able to query any feature attributed to a particular customer easily.
ClickUp
Reviewed by: Graham Reed (i.e. Me!) - THAT Product Operations Guy
The unique challenges to solve (at a now former business)
The business had two major issues: A lack of communication and transparency within the business on product strategy and development, and no decent analysis and prioritisation process for new features and initiatives. The teams used different Jira projects in different ways simply as a task tracking facility, and updating the business on what was being developed and why was non-existent. Roadmaps were difficult to find and interpret. Decision making was not transparent (often by the HIPPO) and took little notice of internal or external feedback. Feedback that was provided by the business came in all sorts of methods (Teams, Email, Jira, carrier pigeon) and with varying degrees of detail and usefulness.
The approach & what was delivered
It is no secret that I have been a fan of ClickUp for many years (I wrote an article a few years ago that ClickUp CEO Seb Evans framed and had a picture taken with!), because of its excellent flexibility to allow me to add the fields I wanted to add, including formula fields, to have multiple view for different stakeholders, and to easily create forms that anyone can fill in without needing lots of expensive licences.
With this in mind, I was able to provide a form asking the exact questions I wanted to ask, which then provided tickets in ClickUp with that information - which then can begin its flow through idea to review to prioritisation to roadmap* to development to delivery - all from the same ticket.
The questions asked teased out the information I needed from the correct source of truth - the end users or internal staff by-proxy. My teams had all the information, quantitative and qualitative, to help them make decisions.
The views allowed me to tell the right story with the right level of information for the right audience, with minimal additional effort each time.
How the product added value to those submitting requests, and to those receiving the requests
ClickUp gave me the flexibility to ask the right questions and constrain the possible answers where needed, on a simple form branded up and available to anyone without worrying about licences and additional cost. This allowed the rollout to be very easy and smooth, and quick. I had exactly what I needed to get the data in.
From there, the information followed the initiative right through to development, via reviews, internal assessment and prioritisation. The same tickets were also made part of the weekly project reports for senior leadership, available in the ‘report’ by virtue of clever tagging, filtering and custom fields.
These same items also appeared, where appropriate, as assets on the roadmap, and said roadmap was multi-layered again by virtue of tagging, filtering and different Views, each of which could be independently shared (again without additional licences) with the wider business.
Overall, the right mix of transparency and expectation setting with information coming in and out, as well as customised, bespoke logistics of the information itself for the product teams.
Pros
Keeping this to my personal favourites:
The ability to share lists, boards, forms (costs extra) with external audiences without extra licences (view only), with a GUID, has been game-changing for years now. Forms mean you can accept new ideas and feature requests from ANYONE.
Automations are very cool, easy to implement, and work on just about every field, hardcoded and custom (Jira is a bugger for their limited use of such automations). Automations are metered though so big orgs be careful
Tonnes of customisations, fields, views. Having a different view, which is a custom filter, fields showing, sort, etc for different audiences makes multi-layered roadmaps a doddle.
Multi-homed tasks - a task can live and be viewed in different lists projects and spaces - a massive time-saver and great for collaborative working (again, looking at you Jira!)
Although I don’t use these much, it does have Whiteboards (who doesn’t these days, sorry Miro!), collaborative document area like Notion and Confluence (I don’t think this is as good as these two right now).
Cons
A common complaint, and I kinda agree for those not deeply into experimenting and finding innovative solutions, is that ClickUp is a bit too flexible - you really can do whatever you want with it, but if you want ‘Product Out of a Box’ you will find it a little difficult to get started.
Watch the pricing tiers, some of the clever things you want to do come at a cost.
The UI is over-stacked with tools now, menu bar after menu bar.
Do you have feedback on any of the mentioned platforms, good or bad? Mention in the comments below.
Have another platform you would like to see on this list? Get in touch for a possible part 2!
Thank you to all authors for your contributions.
Graham