Too often, product engineering teams either struggle to align with audiences or find themselves burdened by a growing list of supposed top-priority needs assigned by different stakeholders. Ultimately, the best SaaS offerings are those which anticipate customer desires and changing prerequisites, and respond in kind.
However, this is easier said than done. User and internal feedback can come at inconvenient times and in inconvenient ways, precipitating disarray unless a formalized system is put in place. What’s more, not all customer requests are of equal importance, and determining which product needs to act upon first can be tricky.
The following article draws upon my learnings as a Senior Product Manager and 17 years of related experience to help product engineers systematically collect and prioritize customer feedback for a clean, purposeful product development roadmap. In turn, you will be able to focus your attention toward projects that will yield the greatest impact for end users and your own company’s bottom line.
Receiving Insights Into Customer Needs
The worst thing a product engineer can be is disconnected from the end users. While your team may have their own ideas for improvements, it’s essential that they keep a finger on the pulse of existing customers’ experiences and industry priorities on the whole.
Collaborate to Gain Meaningful Insights
Due to the nature of their roles, it’s often Customer Success Managers (CSMs) who receive valuable, candid feedback about possible improvements and enhancements. Additionally, they analyze their client’s software usage to provide personalized guidance, but can also use the opportunity to gather observations to share with Product Engineering.
A recommendation from my product engineering colleagues and me is to create a designated email address for CSMs to message with feedback, which is then distributed to our whole team. From our experience, we found that creating a firm yet convenient process for CSMs helps prevent customer feedback from being forgotten or tabled.
A good rule of thumb to follow: there must be open, regular communication between Product Engineering and CSMs.
The wider distribution of the email is beneficial, as it means a quicker response time from us. After all, there are scenarios in which our intimate knowledge of the software can help CSMs better serve customers. For instance, if users seek a solution that already exists, we can mention it to their point of contact, providing a swift resolution.
Collect Feedback Prior to Implementing a New Change
There is a long journey from ideation to implementation. Your goal as a developer is to gather input from users and other teams as often and as early as possible to limit wasted resources. Helpful materials that you should keep on hand include:
- Design documents or interactive design. These blueprint the particulars of the tool update without a heavy investment in the execution. The product team can show the material to customers or stakeholders to hear their impressions and gather feedback. Product engineers strive for feedback on the design, usability, whether it adequately and efficiently solves the problem, as well as additional areas where they can improve.
- Beta programs to conduct usability and A/B testing. In this exercise, product engineers turn on a feature early for users who are willing to be a part of the beta program. The earlier beta groups are often those who expressed interest in the particular enhancement, before widening to encompass other existing customers, all the while tracking usage and collecting feedback.
While CSMs are essential for collecting qualitative input, product engineers also want to accumulate quantitative feedback through a survey distributed to all beta users. By using both forms of data collection, you can gain a more comprehensive perspective of all the feedback.
The Value of Consistent Documentation
Consistent documentation also helps with traceability throughout the many stages of the product update, so multiple team members can circle back to the same reference point (such as a JIRA tickets, Google sheets, etc.). Centralizing internal communications within the same forum makes it easier for everyone to stay informed, minimizing confusion between project participants.
Without a formalized system for accumulating and organizing feedback, important observations will undoubtedly become lost or forgotten. This is because of the sheer volume of ways customer and internal input can be communicated (email, chatbots, Slack, surveys, offsite review sites like G2, etc.).
Additionally, it may be unclear which member of your product team is responsible for documenting and assessing such observations. Therefore, you should outline a step-by-step approach for cataloging feedback that is uniformly applied across the team.
It would be impossible to act upon every piece of feedback right away. However, if your product engineering team decides to defer or skip potential projects, don’t delete any relevant documentation (such as customer complaints, product audits, etc.). Instead, save these notes annotated with the reasoning behind your decision not to make related software updates. This way, if your team ever changes their mind, you can pull upon such materials in the future.
Strategically Prioritizing Projects
Collecting customer feedback is only half the story. Product Engineering leadership needs to sort and prioritize suggestions to create a logic-driven roadmap that aligns with the overall company strategy and provides the most value to the customer.
One such method is to assess each prospective project through the lens of R-I-C-E (reach, impact, confidence, and effort).
- Reach. Determine whether the new feature or upgrade is applicable to most current or prospective audiences. After all, SaaS Product Engineering doesn’t want to be in the business of creating custom solutions for individual users.
- Impact. How much will the modification affect the product and business? On one end of the spectrum, you will have initiatives that will be overlooked by most and yield minimal measurable results. On the other end, some software updates may entirely transform elements of the business, from our ability to sell to new audiences to improved tool functionality.
- Confidence. How confident is the team that they both understand the request and can execute it? There are many reasons for low confidence, such as a request that falls well outside the intended use of the product or tech debt that may need to be addressed before further analysis can be conducted.
- Effort. Some initiatives can take hours, others may take years. For this exercise, you don’t need to nail down specific timelines, instead use generic t-shirt sizing like “extra small, small, medium, large, or extra-large” to gauge relative effort. Keep in mind that this applies to upfront engineering and ongoing maintenance.
When you consider all the elements of R-I-C-E, you’re able to compare the perceived ROI of one project versus another and prioritize accordingly. Other factors that will influence project prioritization may include assessing urgency and subsequent “tech debt” as well as other stakeholders' interpretations of R-I-C-E.
In regard to assessing urgency, product engineering professionals often face the decision of whether to find the quick solution or the right solution. In scenarios where teams swiftly launch a metaphorical “band-aid,” it is only a temporary fix that buys them time to find a more permanent answer and may create more accumulative work over time (tech debt).
With the help of other internal stakeholders, reflect upon both the level of urgency for the update and the added effort of creating both short-term and long-term solutions to determine the right course of action.
As for other stakeholders' interpretations of R-I-C-E, share your initial order of execution with Customer Success and other teams for their sign-off. They may have different insights into the reach and impact of potential projects, further influencing priority levels.
These project elements can guide the team’s annual or quarterly roadmap, as well as determine if such product fixes are small enough and/or urgent enough to justify immediate action.
Measuring the Results of Updates
Product engineering isn’t done once you successfully launch an update. Use specialized analytics tools to track interactions (both at the beta and post-launch stages), looking for patterns in both users and their behaviors. Directly compare engagement levels pre-update to post-update to form (or verify) hypotheses as to why.
If the product update delivered the anticipated results, great! If not, you should once more start the cycle of collecting feedback and data to create new hypotheses that will inform additional updates.
By systemizing customer feedback, prioritization, and impact measurement, your team will improve operational efficiency and the underlining strategy behind your decisions. The result? A SaaS product that tactically evolves to better serve the needs of customers and the marketplace.
