How to Start with User Research Without Dedicated Researchers on the Team

Doing user research regularly is becoming a must-have instead of the cool trendy way of some early adopter software companies. In the highly competitive world of software development, new products and features are rolled out continuously version by version, and companies cannot afford to spend resources on features they only guess will work for customers. They must know that what is being developed is going to blow customers away.

Dedicated user research teams are usually hired at the scaling stage of a startup or even later. This makes sense with the limited resources early-stage startups have. The starting team of a handful of people usually divides all the work and everyone is a jack of all trades at the beginning. The lack of a dedicated researcher means user research activities become the responsibility of the Head of Product most of the time.

This is tricky because the product head is already overwhelmed with juggling multiple responsibilities right at the time when getting user research right is the most crucial. Early-stage startups have a lack of data points on user preferences. Deriving conclusions from low volume traffic with patchy data quality is a rabbit hole that leads to failed products. Think about how important it is to release the best MVP or Beta version you can. A lucky startup has two or three shots, then they run out of resources. Most of them have a single shot.

When Research Is Key But You Can’t Finance It

Let’s work with these assumptions a bit.

1. Early-stage budgets cannot be spent on research personnel
2. User research must be done, and done well
3. It is done by the product head or someone on the product team, who has to pay attention to other areas of the business, and can only sacrifice a fraction of his/her time

This setup makes running end-to-end formalized research projects prohibitive. When you have to go through the steps of initiation, planning, recruiting, data collection, synthesis & analysis, reporting, and follow-up for each research, it becomes a slow, cumbersome, resource-heavy activity. So, it is not for companies with constrained budgets.

In our article on the value of continuous research, we argued that implementing a lightweight research practice with small but frequent touchpoints provides benefits to any company (early or late stage, big or small) and that this approach to research should form the basis of any organization’s customer-facing research activities. In this article, we will show how research that is both continuous and collaborative is agile enough to manage in a small company with limited resources and tight delivery timelines.

Running Lean Research

The point of a continuous research practice is to have lightweight and frequent touchpoints with customers. This way you get compounding returns as you learn something new regularly about the customer and build a deeper knowledge using these touchpoints. It’s cheaper because no setup or recruiting is required, the practice runs perpetually. Your focus on the customer is constant, not on and off based on your research campaigns.

Imagine our hypothetical early-stage startup’s product head. His calendar is blocked every Tuesday for an hour and a half, where he/she talks to three key clients to gather feedback on the newest beta feature. That’s 12 clients in a month. The interviews are short and snappy, and clients lead by sharing their experiences, comments, and issues using the feature. In four weeks, the most important challenges and bugs of the feature are covered, and it is pushed into production in week five. The product head can move on to the next release and rotate to another set of clients from the testing panel.

The point of a collaborative research practice is that you involve the whole product team (user research, product management, engineering, UI design) in your research interactions with the customer. This breaks down departmental silos because everyone hears what customers say and no one works based on their own assumptions. The workload of doing research is split between people when everyone contributes. Eventually, it leads to better customer understanding and happier customers. It also increases motivation internally when people see the meaningful effect their output has on the customer.

Now let’s add to our previous example that our product head involves engineering and design colleagues in about half of his discussions. When everyone from the core team talks to clients and derives insights together, there will be no need to relay research results to the others. Everyone is on the same page and overhead is reduced because there is much less need to share info and coordinate inside the team. Viewpoints of others come into the equation. Developers can offer their views from a technical perspective, UI designers can share their best practices, all in one go.

When you combine both continuous and collaborative approaches, you can make your research as lean as possible. You remove the parts of initiation and planning. You create your user panel on the fly and maintain it afterwards, so the cost of the panel reduces dramatically. You save on internal communications and the sharing of insights as everyone is already involved. Your team gets the biggest bang for its buck.

How to Set Up Your Lean Research In a Small Team

There are a few practical steps you can start with. The point is to automate as much as possible and streamline the rest.

1. Automate your recruitment: one of the most time-consuming parts of conducting research is recruitment. Build a list of power users (or even prospects) right from the start. These are customers who are interested in developing your product together. It’s a win-win because they can have a voice right at the beginning and affect how the product they are (or will be) using turns out. You can also have an open call for customers to join your panel, like Ableton, a leading electronic music-producing software provider.

1. Automate touchpoints with your customers: define triggers where you can engage with customers. These can be events like onboarding, use of a certain feature, cancellations, etc. When the trigger fires, you can send automated emails to ask for feedback, the filling of a survey, a call appointment, a rating, or anything else that suits the situation.
2. Standardize your topics: there are a handful of topics that you will want to explore, irrespective of what your company does. Why does a client convert? Why do clients leave? Usability tests. Validating wireframes/functionalities. NPS. Customer satisfaction. These are areas everyone needs to know about and you should build the structure of your research around these.
3. Templatize for your topics: With a set of standard topics, you can create standard templates for customer interactions. One exit interview is pretty similar to another. Finding out what clicked with the customer when they converted from a trial is also a well-defined conversation. Create templates for your discussions, surveys, emails, and any other interaction so you don’t have to reinvent the wheel every time. Then you can customize little details and update your templates over time as needed.
4. Use a scheduling tool: the time it takes to manage your calendar for interviews adds zero value. Use a scheduling tool to cut it to the minimum. For example — shameless product placement coming up — sign up to become an Airtime beta tester and try our scheduling and collaboration tool specially created for user research.
5. Take notes and debrief together: if you’re embracing the collaboration aspect during interviews, note taking is a good way of keeping observers engaged during the session, and a joint debriefing can establish a consensus on what was said during the session so everyone walks away with the same conclusions. You can even split roles with someone taking notes on what the user says, the other person on the user’s tone, gestures, and body language to capture all kinds of clues. You can also challenge participants’ assumptions by asking them to write down three assumptions on what the user will do or say during the session, then compare it with what actually happened. This uncovers false assumptions easily and takes the team back to thinking from first principles.

As you see, we are big on the concept of continuous collaborative research practice — we built our company on this premise. But cultural shifts aren’t easy. That’s why we created a Collaborative UX Research Playbook that summarizes the key steps to set up such a practice and lists tools that make your life easier. Feel free to give it a read!

Conclusion

The approach to research we outlined here seems quick and dirty compared to running formal research projects. It is not a way to replace long, deep research, but a way to get 80% of the information with 20% of the cost and effort — a truly Pareto-efficient alternative.

When you have a constrained budget, time, and attention, it is the easiest approach to get most of what you can invest. We at Airtime would argue that continuous collaborative research should be the basis of research for any company with big formal research projects thrown in as required by the business. It is quick and dirty but it gets things done.