When we’re speaking about user research, most of the time we imagine a dedicated researcher interviewing our customers and scrupulously analyzing the results. A more democratic view consists of product managers and designers doing the same under a research manager’s supervision.

It involves a lot of conversing with customers, which is great if you have a substantial customer base, a popular B2C product, or a stable champion community that’s committed to providing feedback.

However, in the first case, you’d need to spend a lot of money and resources hiring these people and ensuring their attendance, and in the second, the champions’ loyalty can cloud their judgment about the product’s flaws.

But when you’re researching for a B2B product, the average customer is a challenge to get this feedback from. They’re busy and they’re likely already communicating with one or more of your product’s representatives, like a sales rep, a customer success manager, or an onboarding manager. So why would they want to waste more time speaking to you as a UX researcher? Well, the majority of the time, they don’t.

But does that then mean we should stop our B2B user research altogether? No, not at all.

Limiting your research to the already small number of respondents that are on hand will leave you in the dark. My suggestion is that you stop fixating on mining from customers relentlessly to find scraps of new exploratory data and start utilising what you already have more effectively instead.

Because unless your team is doing something completely wrong, you already know a lot of things about your customers. The only thing that’s left to do is gather this knowledge and transform them into something valuable for informed decision-making.

Where to get the insights from

So, if not through the traditional methods, where do we get these insights from?

Most of the time we think of insights as something that’s been explicitly harvested from our customers’ minds using special research techniques. Fortunately, we’re not the only ones who do that on a regular basis:

1. BDRs analyze the initial conditions and processes already in place within an organization in order to qualify it for the sales reps
2. Sales reps identify the pain points and compile the most popular questions and doubts that prospects have in order to win more paying customers
3. Customer success managers study customers’ barriers and identify workarounds for them in order to make them more successful with the product

1. Support managers are formalizing solutions for the most widespread problems in order to spend less time doing basic stuff

And yes, we can use all this information to craft helpful product insights. All you need to do is establish processes and find a common language for all these diverse information sources to standardize them.

This information might even be more valuable than interviewing a dozen more customers, and it is certainly less intimidating and painful for them.

How to gather the insights

From my perspective, to make things work you need to fulfill several prerequisites: teams must be prepared to spend more time on this common goal, you must establish a common language so that everything may be easily processed later, and you yourself have to be ready to process insights into actionable recommendations.

Getting teams’ onboard might seem tricky at first, but you can appeal to their KPIs to encourage collaboration. Sales reps will sell more when the product has removed sales blockers. Customers that know their opinion is shaping the product roadmap are more likely to give higher scores and scale with you, which will be met with joy in the customer success team. Finally, the more bugs you kill, the easier life becomes for customer support teams. All teams can benefit from more collaborative insight processing, not just the usual product and design ones.

Once teams have agreed to bring insights about our customer’s behaviour into one melting pot, it’s time to think about the best way to do so.

At Juro, we initially tried to simply write down the requested feedback. However, we soon discovered that the reports were unactionable. Some of them were too broad, stating something as basic as ‘we want feature A’. Meanwhile, other reports were too focused on a very specific solution and lacked clear reasoning. But what they all lacked was situation context and motivation — two of the three basic components of a job story. That’s why we’ve decided to make reports more JTBD-style.

To resolve the problems described above, we’ve set up a very simple Slack form. It describes who the customer is, what they’re trying to do, what the problem is, and why it’s important to them. Our managers also assess the severity of all feedback on a scale from 1 to 5, with 1 referring to a more lightweight issue and 5 referring to something that will pose a major churn risk or sales blocker.

The form is fast, simple, and efficient. It usually takes just a couple of minutes to complete and our go-to-market managers heroically provide dozens of those a month. Essentially, everything they think is worthy or useful will go in there. It also helps that the feedback is kept in Slack, a system, that our teams use daily anyway.

All this feedback is then gathered and compiled into a single knowledge base. The greatest thing about this resource is that the researchers fill it with exploratory feedback from their research as well. It accounts for almost all of qualitative customer data in Juro, and it looks like a universal pile of facts in Atomic Research methodology. The information is then transformed into more capacious insights, which are linked to the relevant design investigations and thoroughly tagged.

Of course, this approach doesn’t replace all of the usual research work traditionally carried out by UX teams. But it certainly helps to stay in touch with our customers and notice their biggest pains as and when they surface.

Product managers at Juro use these insights to establish their teams’ priorities. Designers check if their new features cover all of the described use-cases for the relevant problem, and researchers plan their next deep dives based on what troubles the customer is experiencing that haven’t yet been fully investigated. Best of all, our customers only need to communicate with the relevant managers — unless we need them to elaborate, of course!

Author profile

Aleksander Fenin is Senior UX Researcher at Juro, the contract automation platform. He has previously held various senior UX and user research roles, and delivers university lectures on research methodology