To make effective decisions when developing products, engagement with customers is critical. Building this into your way of working should be the priority of any product leadership. Along the way, data should be captured and analysed.

There are two broad categories of customer engagement data that should be integrated into your product development process: qualitative data, which is narrative in nature, and quantitative data, which is numerical in nature. Each of these categories have their strengths and weaknesses and should be invoked in different circumstances.

Building a great framework for qualitative data

Examples of qualitative product development data in a B2B SaaS context include:

  • User interviews and documentation, often regarding pain points, requirements and business operating procedures.
  • Case studies.
  • Focus groups.
  • User testing of prototypes and interfaces.

Qualitative data should rarely dictate (though it may inform) decisions about what features you should build. Rather, qualitative data is more useful for informing how features should work. The reason for this is simple: qualitative data is by nature narrow in scope and sample size. Relying on qualitative data for high-level strategic decision making often results in source bias, which leads to companies building for the customers they talk to (i.e., the most accessible or the loudest customers) rather than the broader market.

Generally, a good rule of thumb is to lean on qualitative feedback (e.g., user interviews, case studies and user testing) after you've decided you want to tackle a problem and during the solutioning process. When anecdotal feedback is nudging you in a specific strategic direction, try to find some quantitative data to validate your ideas.

A major challenge faced by many B2B SaaS product teams is that the majority of the data they receive is qualitative in nature (e.g., feedback on lost/won sales, support cases and churned customers). This can make it very difficult to determine what to build next and often results in features being built that only satisfy a small subset of the overall user base. The best solution to this is to try to adjust your business operations to convert what is traditionally anecdotal feedback into quantitative data.

Building a great framework for quantitative data

Most product teams have a torrent of anecdotal feedback, related to the needs of specific customers or trends that coworkers or partners have noticed, coming at them every day. Finding a signal amongst the noise can be very challenging. The best way to do this is to work towards building business operations that make it easy to record feedback from individual customers in a way that can later be analysed as quantitative data.

For example, product managers who are receiving a lot of feedback from their support team should empower their team to record this feedback in a structured, analysable way. The same can be done for other customer touch points.

Turning anecdotes into real data

Below are the key touch points during the customer journey that product companies should build business processes around for insight collection:

  • Sales opportunity closure → Product teams tend to hear from sales colleagues that if we only had this feature, we'd close way more deals. Often, after building these purported silver-bullet features, the uptick in victorious deals doesn't come. When declaring a sales opportunity as won or lost, key reasons for the outcome should be recorded. Your team should be able to tag areas of the product that the customer liked and disliked (so that you can later report on this) and record notes on what the ultimate deal winner, or breaker, was. This will allow you to quantify exactly how many deals were actually lost to the lack of the feature your sales team is requesting.
  • Support case closure → When requesting support, customers will often give feedback on new features they want and existing features they found difficult to discover or use. By empowering your team to record this feedback in a quantifiable way, product teams can better keep their fingers on the pulse of what existing customers are struggling with. Sharing insights from this data with your support team can really help to keep them aligned with your product strategy as individuals may have very different ideas about what customers are asking for. This is especially useful in support teams where support agents are aligned to specific areas of specialisation, as everyone will end up hearing feedback pertaining to their area of specialisation and nobody else's.
  • Success interactions → Your customer success team is a critical source of customer insights. They are proactively calling customers every day and valuable information is inevitably shared with them. To get the most value out of your customer success team, it's important to give them the tools to record any feedback they receive, in a way that will be easy for you to report on later.
  • Churned customers → The cancellation process should always include the collection of any feedback customers may have on your products and services. Understanding why customers are leaving for a competitor can inform good product decisions.

Try to aggregate all of the data above into a single database in your CRM, alongside other feedback like CSAT and NPS (further reading on requesting feedback).

Additional quantitative data

Beyond the above, there's a lot more quantitative data you should be tracking. Fortunately, these data points are, by nature, much easier to quantify:

  • Product/feature utilisation (i.e., how many people are using each feature).
  • NPS.
  • CSAT, which should be surveyed after each support interaction and the completion of key in-app operations (including wizards).
  • Funnel analytics (i.e., how many people are completing certain in-app operations? When do people typically drop off?).
  • Surveys to the customer base.

In conclusion:

  • It's important for product teams to establish a strategy for the collection and analysis of data.
  • Quantitative data is best for guiding product strategy, while qualitative feedback should be consulted during execution/development.
  • Feedback should be recorded in a quantitative way that can later be reported on and analysed for the purposes of strategic decision making.