Recruiting enterprise participants for pennies: a practical guide

Tips on being a researcher for an enterprise product

Imagine you find yourself in this situation: you’re a researcher for a large enterprise space and you’re told, “We need to talk to people who exclusively use Product X (an expensive, technical, enterprise product) and have 12 years of experience in the field who can talk to us on an ongoing basis for an hour every 2–3 weeks. Oh, and we can’t compensate them, so we have to convince them to talk to us for free.”

There are four key things present in this demand: someone

  • with specific technical enterprise product experience,
  • who is very knowledgeable,
  • who can talk on an ongoing basis,
  • on a restrictive (or nonexistent) budget.

I’ll break down those four aspects, and then discuss the requirements needed for this situation to be a success, give some practical advice on how to proceed, and then finish with the implications of an impossible task.

Definitions

Technical enterprise product

I’ll start by unpacking what I mean by technical enterprise products. These are products that large companies use to keep their (sometimes multinational) businesses running smoothly. These are likely not the types of products that just anyone can pick up and understand, so the participants you’re looking for operate with a significant knowledge of unique processes, and/or specific domain expertise.

Knowledgeable person

The people who use technical enterprise products have some combination of 10+ years of experience in the field, lots of domain knowledge, and are critical to their company running smoothly in some way.

Anyone with 10+ years of experience are typically fewer in number than those who are newer to the field. Lots of domain knowledge means they’re fluent in a vocabulary you likely don’t understand (yet). These people are influential to decision-makers. They are the ones evaluating products, passing on reports from their findings to their management chain.

Due to all these reasons, these people’s time is in demand.

Visualization for finding relevant users for an IBM product I worked on called PowerHA.

Ongoing basis

You may be wondering “Why would someone demand that a researcher talk to the same participants so often throughout the design process? Won’t that bias those users towards the design on which they’ve contributed?” I asked myself that very same question when I started doing enterprise research. What I learned was that the reality of having technical enterprise users, is that there is a limited supply of them. There may very likely be only 8–10 of them in the world in some cases. (I’ve worked alongside researchers who have been in that exact situation). The reason you can’t get fresh users for every round of design changes is that there simply aren’t enough who exist to even make that possible.

Although this is counterintuitive to all of your training (as it was to mine), you have to work around the reality of your situation.

Budget

It wouldn’t be a true challenge without throwing a budget wrench in the mix, right? I can’t speak for enterprise researchers in all companies, but the situation for IBM is that it has extremely high integrity standards that caution against any gestures that could potentially be perceived as bribery.

Let me get one thing clear: I am not ever in support of bribery. I highly value the fact that IBM’s standards and cautions against bribery are so high. However, the implications of those standards is that researchers are not allowed to compensate participants for their time. And that restraint, as you might imagine, presents quite a few challenges, especially when you consider the already tall order.

Requirements for success

If you’re following along with the beginning scenario, you may be starting to think that this type of task is impossible. I have also thought that many times when I’ve been in this situation. Hopefully you never find yourself in this situation, and you have easy access to users, with the ability to compensate them for their time.

The good news is, in some circumstances, this scenario is actually possible. The bad news is that there are also circumstances where this situation is impossible; I’ll get to those later.

Success Scenario

Should you find yourself in this situation, here’s a checklist to decide if your task is or isn’t impossible:

  • Is your project focused on a product? (The project should not be a marketing website, a poorly defined idea, or a new technological concept in its early stages, to name a few things)
  • Does your product have an existing user base?
  • Does this product have a roadmap of releases with new features for the next 2–3 years?

If you answered yes to all those questions, it’s more likely that you will succeed in this situation. If you answered no to any of those questions, you have some tough conversations ahead of you with your stakeholders. I’ll discuss those in the last section.

Most likely in your company, there are lots of people who have good relationships with exactly the type of participants you want. I strongly recommend making friends with some key people:

  • The salespeople who work closest with customers (In IBM, those people are called Technical Sales Representatives and they’re incredible. They know their customers very well, and can likely recommend some of them to talk to. They also know the product minutiae as well as the product architects and engineers because they’re there troubleshooting with customers when something goes wrong.)
  • People who are very similar to salespeople for IBM: Business Partners. These people are third party resellers who perform many of the same functions as the Technical Sales Representatives, not only selling the product, but also helping customers resolve technical issues.
  • The product owners (In IBM, they’re called Offering Managers). This may seem obvious, but these people are highly invested in the success of the product, and they likely know a few key customers who have given feedback through the time of the product.
  • Sales communication leaders. These people likely have access to the entire list of salespeople for your business unit. If you can prove the value of research to them, they can unlock a lot of opportunities for you, since they also likely know of any customer-focused events to which they could get you an invite.
  • People who organize any customer boards. These people can get you in front of customers who are already predisposed to be involved with your company, and are likely to want to give feedback.
  • The product support team who is called upon to help customers resolve any persistent issues they might have. In IBM, there’s a group called Lab Based Services (LBS) who know the products inside and out, and exactly where customers struggle to succeed. They’re a bit different from a traditional helpdesk support team because they sometimes will go in person to resolve issues, and have strong relationships with customers. This team can be a rich source of knowledge on what issues are the most debilitating, as well as potentially connecting you to the right salesperson to talk to customers directly.

If you can prove the value of the customer-centered product research to more than one or two of these people, you will soon find you have a whole crew of advocates who can help you next time you need to find participants.

Practical advice

Recruiting technical enterprise participants

Let’s check progress. So far you’ve:

  • Determined your project has a chance at success.
  • Found some people who can help you find participants.

Now you have to go get these participants all signed up. That means mostly lots of emails to get started. As you get in front of all of these people who work directly with your type of participants, they’ll start thinking of people who might be interested.

Sometimes people are concerned about participants “being negative.” I typically encourage them to send on the person’s name anyway, until I have built up a substantial list of names to contact. If I need around 9–10 people to participate in a study, I try to get the contact information for about 20–30 (minimum) people who might be interested in participating.

Once I hit a critical mass, I email each person individually (because I want them to feel special, like they’ve been nominated to an elite program, not just BCCed on a group email), using a template email. It goes a bit like this:

*****************************************

Hi ________(insert name of person),

I am part of a product design team at IBM focused on advocating for and creating the best product user experiences based on feedback that we get from people like you, our users. We are looking for users whom we can interview on our current project topics in order to better understand exactly what you need, and drive our strategy for these products around the needs you describe.

You were referred to me by [insert name here] as a great resource to talk to about our [PROJECT NAME] project in particular. We are interested in learning from you about [PROJECT-SPECIFIC NEEDS, LIKE: your experiences, pain points, and/or perspectives on what is most essential]; you’re the expert!

Are you available for a 30-minute call at your convenience, during which I can give you more of a rundown on these projects and what kind of feedback we are looking for?

Of the dates/times below, let me know a few days/times that will work the best for you, and I’ll get something on our calendars.

23 Jan Monday

9a CST

11a CST

1p CST

3p CST

24 Jan Tuesday

8a CST

10a CST

1p CST

3p CST

25 Jan Wednesday

9a CST

11a CST

1p CST

3p CST

26 Jan Tuesday

8a CST

10a CST

1p CST

3p CST

27 Jan Friday

9a CST

11a CST

1p CST

3p CST

Thank you for your time, and I look forward to working together and hearing more from your perspective.

P.S. If you would prefer to share your perspective on other projects instead, other user research team members are also kicking off projects right now that may be of interest:

(and here I list out our other projects and a brief description of the type of person they’re looking for)

********************************************

Since we are likely to only get a few chances at connecting with this person, I want to make sure that if she can’t participate in my project, at least one of my colleagues might be able to have this person on as a participant.

I also CC the person who referred the participant to me in case the participant wants to discuss this opportunity with person she knows. As a rule, I always CC the salesperson on any communication with their customer. I never want to keep the salesperson in the dark. The salesperson did me a solid by connecting me to the customer, so I can certainly keep her in the loop with any communication in the future. It builds trust between you and the salesperson, which can lead to connections to other customers in the future.

I typically send that email 2–3 times at this interval (Pro tip: do not send email on a Friday or right before a 3 day weekend):

  1. Day 1 — send initial email. If no response, email again on
  2. Day 4 (4 workdays later)- send reminder email. At this point, I also email the salesperson separately to see if she knows what might be going on for that participant. If no response, email participant again on
  3. Day 10 (10 workdays later)- I note that this is the final time I’m contacting them, and thank them for being a customer. Do not contact this person again until about 6 months passes. This person may be swamped at the moment, but potentially interested in the future. I recommend checking in with the salesperson before emailing again, just in case.

Once I hear back from the participant with dates and times that work well, I send a calendar invite with the conference call information and web meeting details, and wait for the day we agreed on.

First session

When that day comes, I start out by asking the participant some intro questions about what she does, what her experience is and give her more background on the project. Then I walk the participant through a deck explaining the process, and what her involvement might look like.

We keep participants on for about 6 months during which they might see concepts, sketches, information architecture, or a working prototype with code. After the 6 months of involvement are over, we give them a 6 month reprieve where no one on our research team contacts her. I also explain that we’re looking to her to keep us on track with the product development, and to let us know if there are any things that seem strange or out of place as they watch the product evolve.

Lastly, I bring up that if she is interested in participating, we have to have a signed legal agreement that a) gives the product team ability to incorporate her feedback into the product, b) notes that we will be disclosing confidential information, and c) we don’t want any confidential information about her company.

At this point, if the prospective participant is still interested, I go ahead and schedule our first call, even before getting the legal document. Scheduling things over email is much more cumbersome than doing it right there with them on the phone. Rescheduling is easier than starting the scheduling conversation over email.

After the call finishes, I send an email thanking the participant for the time spent during the session and I attach the legal document for the participant to sign, and wait to see if I get it back.

Legal Agreement

If I get the legal agreement back within 24 hours of sending it, I send an email congratulating the participant on joining the program, and note that the team is looking forward to learning from her.

If I don’t get the legal agreement back, I send out reminder emails at the same email interval as mentioned earlier.

Incentives

Believe it or not, there actually are some very effective incentives for this type of participant, even without being able to give a monetary incentive.

This type of participant likely doesn’t have a choice about using this software. She works for a large company who purchased this software before she joined, and has found ways to work with it and work around it. This type of participant has a history with the software — learning it and any quirks it has, working around product deficiencies and inconveniences and may have a ‘love / hate relationship with it’ (people who have been using a tool for a long time may be very resistant to change even if they have problems with the product).

Some benefits of participating include:

  • having her requirements directly heard,
  • talking with the technical members of the team,
  • ensuring the product is easy for her to use (and make sense in her world)
  • ensuring that the product fits in with other tools and ecosystem of her company
  • she gets more insight and has influence over our product roadmap
  • feels special that she was chosen to represent her companies interest
  • creates a stronger relationship with the product team which will be helpful in the future.

The ability to take an active role in improving the product for herself or her team is significant. It could mean improved team productivity, efficiency, or team knowledge of the product before the product is released.

We also have another incentive for our IBM Power customers; our legal team recently agreed to let the product team publish the names of the participants who helped us along the way through a release form. Note: this is just the participant’s name, not the company she works for. We tell our participants about the opportunity at the end of their engagement with us, and then send them the release form. Participants, if they’re interested, sign it and send it back to us, which allows us to publish it in the About section and the readme for the product.

Participation wrap-up

The key to keeping customers interested in giving feedback in the future is to finish well. There are a few things we do as part of that process:

  1. We email the release form to the participants who have been significantly involved in the process.
  2. We send handwritten thank you notes to each participant at their business address. We get this address from the salesperson we worked with, or from the participant herself. This has consistently left a good impression (see below), not just about the product team, but about the company as a whole.

Impossible task scenario

Up until now we’ve been discussing the success scenario. So, what happens if the success criteria are not present? Let’s discuss the scenario for if you answered NO to any of these questions:

  1. Is your project focused on a product? (The project should not be a marketing website, a poorly defined idea, or a new technological concept in its early stages, to name a few things)
  2. Does your product have an existing user base?
  3. Does this product have a roadmap of releases with new features for the next 2–3 years?

I’ll walk through the consequences of having a No for each question.

Focused on a product

If the project you’re being asked to take on is not focused on a product, it’s very difficult to have participants sign up for ongoing feedback sessions if they don’t a) have a good handle on what they’re signing up to discuss, or b) think it will directly benefit them or their team in some way. It also signals to participants that the company is unorganized and/or uninformed on a topic.

In general, we can assume that people want their technology to be faster, lighter, more accurate, etc. A new technological concept in its early stages is often not something about which participants have strongly held opinions. When discussed early, it’s often too abstract for participants to understand how this innovation can impact their workflow. Once the concept becomes more closely associated with part of a product is when it becomes more compelling, and will likely garner more opinions.

In this situation, rather than trying to recruit for an on-going relationship, you could set up ‘one-time’ discovery interviews. At the end of the interview you could ask if they would mind being contacted after our product plans are more solidified. The discovery interviews will be invaluable in helping the product team decide where to focus.

Existing user base

When you have an existing user base (or a user base that is closely related to the one your project is targeting), you know there are people who use the product, who likely have ideas on how to improve it. If you don’t have a user base, you’re starting from nothing. To get around this, you have to work very very closely with your best friends in sales to get in contact with real potential participants. And while salespeople can be extremely helpful, if they’re in the middle of a sales negotiation, which is always delicate, you will likely not be allowed since you’ll likely be seen as a threat to the success of the sale.

Secondly, if you’re supposed to be talking to people who don’t use the product, they likely have zero incentive to participate on an ongoing basis to improve a product they don’t use. It is very unlikely that their management would allow them to participate more than once. There’s little benefit to their employer paying for their time to improve products they don’t use.

Let me reiterate the use of discovery interviews. They’re great to get a foundational understanding of your user base. Also, often (not always) customers are doing *something* that relates to your product — it may be done by hand, through multiple products or in some other way — it is useful to find out how they handle the situation today.

Roadmap of releases

You want to be sure you’re doing research on a product that’s going to stick around for a while, if you’re going to ask your customers to invest their own time into it. If a product is on its way out, don’t give your customers the sense that your company is still heavily investing in it. That has the potential to backfire and result in broken trust, which leads to customer dissatisfaction, which ultimately can lead to loss in revenue.

Conclusion

Conducting research on technical enterprise products is simultaneously some of the most challenging and rewarding work there is for a user experience researcher. The technical enterprise product users are often overlooked and forgotten by the software providers. They consistently put up with frustrating, inefficient, and outdated interfaces. Being able to make a product that is delightful, efficient, and modern makes your product stand out even more. However, knowing what you’re getting into research-wise before you begin is key. Don’t get on a train without knowing where it’s going and where it’s taking you.

Author: cary-anne olsen-landis

Collect by: uxfree.com

Comment

Top