User Research: When?
User research is powerful, well known, and misused. For this post I’m not going to explore how to user research, focusing instead on when to user research. The basic premise of user research is to talk to current or potential users, identify their problems, and use this as an input to build solutions.
If you haven’t already, consider subscribing to FoundIt for cool product building stuff!
At the onset, let’s make this one clear - if I could do user interviews, feedbacks, round tables, for everything I build, I would do them. Resources are limited though, and that means we must prioritise what goes into the user research pipeline.
Given resource constraints, here is my decision framework for when to user research:
The development effort needed to go live
The potential for disruption that the product offers
The scale of the organisation building the product
Development Effort
Different degrees of development effort needed to ship a product present with some insight into the need for user research.
Projects with high development times and high perceived user impact benefit most out of user research, as they bring more confidence to the problem being solved and allow for testing the solution before building. If I’m building something that has high perceived customer impact but low development effort, I consider ‘build->test->ship as an experiment’ instead of research. The cost incurred to put the feature out there is low, and I can see customer benefits through an A/B test.
Projects with low perceived impact and low development effort follow the same build->test->experiment approach. These projects would likely be my list of optimisation projects - small incremental product improvements with good but limited user impact. If I’m doing something with low user impact and high development effort, I would reconsider my prioritisation and ask myself why this project needs to be done.
Potential for disruption
Another way to evaluate the need for research is by looking at the disruption potential of the idea and the scale of the organisation.
Ideas that have high disruption potential are ripe for user research. This is because a radically new idea is often difficult to test and validate with existing data. Especially for smaller organisations, which don’t have years of historical data and information of things tried before, user research can give great initial signals on both the viability as well as the need for the idea.
Smaller organisations working on low disruption potential benefit from focusing their energy on other projects, because smaller organisations tend to have more low hanging fruit that can cause high impact.
Larger organisation looking to optimise their established product with small, incremental steps benefit from investing in continuous experimentation pipelines and maintaining data sanity - this allows to try multiple ideas rapidly and establish lines for success. Larger organisations working on disruptive ideas should research, but even before going to this step, try to find signals for success with existing data, past experiments, and signals picked up from centralised user research.
Organisational scale and user research
As organisations scale, it becomes impossible to research every idea that is to be implemented. Most large organisations centralise their user research into teams that work on large ideas, with satellite teams or projects spawning as and when necessary.
Every team doing their own little bit of research becomes unscalable for large organisations, first because it’s expensive, and second because it prevents transfer learning. Teams working in silos find it difficult to share their learnings across the organisation.
Often a solution is to build a central user research team that researches larger strategic horizons, hosts regular feedback sessions, focus groups, and interviews, and allows stakeholders to participate and add their questions. These learnings are then shared across the organisation and help teams ideate, iterate, and learn. Occasionally, small satellite user research teams form as task forces when there is a need for dedicated user research. In general, the degree of centralisation usually grows with the size of the organisation.
Large organisations or small, user research is the best way to stay connected with users, and view them as humans rather than data points. I make it a point to keep reading the findings of user research, keep learning from customer quotes, and watching user research live sessions. I feel it keeps me close to my users and makes me feel their needs!
How do you do user research in your organisation?
If you haven’t already, consider subscribing to FoundIt for cool product building stuff!
Or share this post with friends and colleagues!
