Product Practice #277: Four Problems with “Traditional” User Recruiting

Published:

Estimated Reading Time:  Minutes

Spoiler alert/disclaimer: At the end of this week’s newsletter, I mention Orbital, a startup addressing these problems with user recruitment. I recently joined them as an advisor!

There are few things the product management industry can agree on. But the importance of enabling product teams to access first-hand user feedback whenever they need it is probably one of them.

Traditionally, the path for product teams toward capturing qualitative insights from user interviews has looked somewhat the same. And it’s flawed in four major ways.

1: You have to go through a Centralized Authority

Having specialized, highly-skilled people in your org is great. But having them become the bottleneck for everyday practices isn’t. Yet, this is common in many companies: Recruiting users only happens through an in-house or outsourced team. 

This can get in the way of the self-determined learning of product teams instead of enabling it. A modern way of organizing user recruiting responsibilities might look like this: Centralized quality criteria and enabling education, informing decentralized selection, execution, documentation, and decision-making.

2: You lack the data necessary to qualify participants properly

As anybody who has ever recruited for user interviews will tell you, what people say and what they do are two vastly different things. Self-evaluation will only get you so far. And getting insights from the right users is critical for both evaluative testing of ideas and generative research.

A modern approach: product teams can access the same high-quality quantitative data they have in their product analytics to further screen potential participants.

3: You get lost in the averages of large-scale “panels” of recruiting platforms

Time pressure, policies, and a lack of data often lead to the use of anonymous and outsourced “panels” provided by recruiting platforms as a proxy for real user insights. While the sheer number of possible participants on large-scale platforms can be mouthwatering for a product team thirsting for any user insights, interview data from the wrong users is even more harmful than no data.

4: You fall into the trap of slow, ‘project-based’ research

When interviewing users is painfully slow and frustrating, it’s easy to use it sparingly and only for “important” projects. And this high-effort user recruiting can come with a longtail of logistical baggage: Planning out multiple cohorts of users and involving and aligning with stakeholders.

The less frequently teams speak to users, the less effective they are and the fewer chances they have to improve their research practices.


That doesn’t mean user recruiting shouldn’t be structured, organized, and follow agreed-upon quality criteria. But centralized queues requiring product teams to “ask for permission” to talk to users is not the answer. Thankfully, a new generation of tools is cropping up to address this gap.

One of those is Orbital, which enables product teams to regularly speak with the right users without the hassle. I’m beyond excited to join them on this journey as an advisor to help them break down the barriers of traditional user recruiting and enable more Product Teams to own their Product Discovery.

Speak soon,

Tim


Content worth your Time

4 levels of UX Research democratisation

Democratising ownership means everyone on the team can plan studies on their own. If a QA is unsure about the latest feature, they can schedule an ad-hoc usability session, or if a developer wants to understand better the problem they are solving, they can arrange a user interview. It elevates UX researchers closer to coaches and strategic research managers than the ones who plan specific research activities. Whether such a level of democratisation should even be desirable is another question. Let’s face it. It probably won’t work in the majority of cases. But for small teams of people with proper research skills, it could bring exciting outcomes. Or at least it’s a pretty interesting theory.

Maximize Impact in Your Org with a Monthly UXR Newsletter

I would choose and write the top three insights based on the theme. They didn’t all have to be from one project, and I preferred if they were from different ones. This is why I went with a theme instead of the most impactful project of the month. Within each insight, I would include: The teams that the insight would be most relevant for, Quotes or infographics, Links to audio/video clips and the overall report for people to dive deeper, Keywords in the form of hashtags to make the email more easily searchable.

Building a Passive Product Feedback System

Feedback systems consist of processes, functionalities, and tools that were put in place to facilitate the collection of customer insights, compiling them to one central place internally. All are happening without constant or proactive effort from product teams. Passive product feedback systems are something that companies rarely focus on intentionally and are usually not well documented, but organizations still build components of it over time.


{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}
>