Tina Nguyen
6 min read · Feb 19, 2024
Early-stage startup teams consisting of only founders and engineers without a researcher or designer make these basic mistakes in approaching user research.
The startups that I’ve worked with in the past have made common mistakes with user research. These mistakes were avoidable because they were known to designers, but these startups didn’t have in-house design expertise. I’ve also been at big companies with established design teams that made the same mistakes because Design was not a mature practice and was treated like a service org.
At early-stage startups, founders are often the only people to speak to potential users — most startups do not have the expertise or budget (it isn't a priority) to hire a researcher or a designer trained in research. Circumstances set precedents. What was regrettable becomes the norm. When startups do grow and gain the ability to do in-house research, the reluctance remains because the founders believe they already understand the target user. Their success (as evidenced by investments in their startup) buoys their confidence despite the lack of rigorous research.
While the early team could share the responsibility for user research, talking to people is hard. Early-stage startup teams are often comprised of engineers. As an engineer, I never spoke to any users. It took a lot of practice before I could approach people to ask questions. Talking to users can be a struggle for anyone not trained in the process, even executives whose job is communication. User research is a learned skill. The team might be tempted to skip research out of discomfort or in the spirit of moving fast, but that may contribute to the startup's failure.
On the surface, a team may believe in the importance of understanding the target user and their needs but then err in thinking that more user research is unnecessary because they are the target users and can speak on their behalf. However, by working on the product, they already know too much to be representative. This can be tough to change if no one at the startup has enough experience or credibility to disagree with the people thinking about this problem the longest (especially the founders).
Well-intentioned teams that believe in listening to users can make the mistake of creating a list of features and then sending users a survey asking which ones they want. I have seen this multiple times. In most cases, the surveys are biased and can lead the company to draw faulty assumptions. Crafting unbiased questions is difficult if the team has not been trained. Surveys can be helpful if the team has performed qualitative research and uses them to falsify hypotheses. Otherwise, creating roadmaps based on survey results can potentially waste time and money.
Startup teams are naturally excited about their ideas, so when they speak to users, they tend to sell instead. Their questions are variations of: “Would you use this?” In the face of such enthusiasm, people may say something positive to not disappoint. However, this derails the conversation and turns an opportunity to discover unmet needs into another data point for confirmation bias.
Startups should be wary of talking to too few users and mistakenly applying best practices for usability testing to user research. Most common usability issues can be discovered by talking to 5 users. But that only applies to usability testing of a feature or prototype, not to exploratory user research. Usability testing determines if a user can complete a task, whereas exploratory user research is for discovering unmet needs. If the team is still looking for product-market fit and trying to understand potential users, talking to 15-20 people would be more helpful in uncovering motivations and patterns in their behavior.
When teams invest in exploratory research, there can be pressure to get it right, especially if research is done infrequently. This mindset leads to disagreements. The research is unlikely to answer all questions, leading some team members to doubt its usefulness and validity. The purpose is to learn about user motivations and behaviors — complete agreement on the findings isn't the end goal. Research is often not comprehensive, as that would take a long time, so some gaps in understanding are to be expected. Ongoing user research reduces the pressure, ensures that the team has a shared understanding of the user, and helps them to iterate and test hypotheses, increasing the chances of creating something valuable.
Teams can make the mistake of assuming that a product is suitable for everyone. Anyone could use it, but not everyone will. The hope might be that the product will have a large user base. But, at the beginning, the team needs to be specific. Explicitly focusing on a user segment helps the team have a shared understanding of why they build and for whom. When the team allows the target user to remain loosely defined, team members may make assumptions, leading to disagreements about product direction and potentially building a mediocre product that no one wants.
Teams that make changes based on what users say without understanding their reasons run the risk of undesirable outcomes. Building without understanding the underlying needs and motivations may miss the mark and create something users do not value. Users typically cannot articulate what they need (they may not know), so relying on their words for product direction can lead to disappointing results.
Some teams understand that users cannot articulate what they need but mistakenly use that rationale to avoid seeking user feedback (citing Steve Jobs as inspiration for their approach). They build without validating their hypothesis and do not iterate because there is no user feedback. Months to years can pass before the product is available to end users. If the team is wrong about their initial hypothesis, they will have wasted significant time and money. Frequent evaluative user research helps teams to course-correct early and often. Users may not be able to articulate what they want, but they can give feedback on whether or not a prototype fulfills a need.
The founders are the first to talk to potential users, but if they are the only ones, they become the gatekeepers for all decisions. This may work in the early days when the team is small but hard to scale as the team grows. Some are convinced they have the answers, led by their intuition. I believe in intuition and also in the need to validate it with user research to keep confidence from becoming hubris.
The lack of continued user research and reliance on the founders results in slow decision-making. No one person, not even the user researcher, should hold the key to understanding users. Even backend engineering decisions that may not seem like they require any knowledge about the end user can have undesirable ramifications down the road, limiting the experience that the team can build. At that point, it might be too time-consuming and expensive to change. Having a shared understanding allows everyone on the team to independently make decisions that contribute to a better user experience.
User research may feel daunting, but shouldn't be avoided despite the lack of a user researcher or designer. Given the typical startup configuration of engineers and founders, there are ways for interested team members to perform user research.