Before initiating the conversation around user research, let me start by addressing the elephant (or should I say horse :-)) in the room. Any time a conversation on this topic starts, it is very difficult to not come across the legendary quote from Henry Ford on this topic:
If I had asked people what they wanted, they would have said faster horses.Usually, the person using this quote would say this with a smug self-assured smile almost authoritatively ending the debate. However, there are at least four problems with this one:
Henry Ford never said this! There is literally zero evidence of Henry Ford ever saying this. Most likely, somebody said this in the third person "If Henry Ford had asked people...", and with time the quote changed to a first-person quote.
You are assuming on the behalf of the users without any evidence about their intent. Putting yourself in the shoes of the customers is a good start to customer-first thinking, but guessing on behalf of them is not user research and it will often lead you to a misleading conclusion.
You are asking the users for a solution. The focus should be on uncovering problems that the users face and sometimes validating solutions you have in mind to solve those, but never on trying to get the solution from them. As Steve Jobs used to say, "It’s not the consumers’ job to figure out what they want."
If somebody did try to talk to the users, they would have uncovered problems other than speed. There is substantial evidence of problems other than speed: Stinky dung-covered roads and safety hazards. More details here. With user research or not, cars solved these seemingly unsolvable problems, not just the problem of speed.
Now, let us come to the main point of this post: Where are you or your company when it comes to acceptance of user research and what you can do about this? I call this framework "Seven stages of user-research denial".
Each subsequent stage is at least a bit of an upgrade over the previous one. But stage 1 and stage 2 are probably equally bad in impact and the impacts of stages 4 and 5 can range from very bad results to reasonably acceptable ones and depending on the context, one stage may be worse than the other. So in the block diagram, stages 1 & 2 are at the same level and so are 4 & 5.
Stage 1: User research is a useless bureaucratic formality for large companies. This statement is usually uttered by founders of early-stage companies with relatively less real-world professional experience before their startup. What most of these do not get is that some of these companies have become large and successful primarily because of their relentless focus on the customer from their very early days. They may not have called it "user research" at that time, but there are records of Facebook, Amazon, Google and Apple engaging in deep conversations with their customers in their formative years. (If seeing Apple here surprises you, see the article link in stage 2)
Stage 2: Our users love our product and we define what they want. This is only a slight upgrade from stage 1. Companies in stage 2 are not completely dismissive of user research, but they just do not see this as a fit for their companies. They usually have seen some early success in product adoption and/or raising funds and that makes them overconfident in their ability to understand customers' needs.
It is not uncommon for these founders to quote examples of Apple/Steve Jobs to defend their lack of user research. But two things: First, most founders are not Steve Jobs and most companies do not have an Apple-like loyal fanbase. Second, while in my stint at Apple, I did not observe user research first-hand, there is ample evidence that the company has been engaged in this for decades. While I labelled this stage as somewhat of an upgrade over stage 1, the end result is still the same: a complete lack of user research. So stage 2 still stays in the red zone.
Stage 3: User research may be useful but it will slow us down. All right! This is progress! We have started to move towards acceptance! Sometimes, user research will slow you down a bit for sure and therefore, for incremental changes, it is indeed better to try out quick experimentation and let that dictate your decisions instead of primary research.
However, for most medium to large-size products, it is better to invest in at least basic problem validation (and sometimes solution validation) before spending precious dev bandwidth. Keep in mind that even companies with good user research culture and huge dev-bandwidth dedicated to experimental big bets end up killing a good number of their products. (See Google Graveyard for example). With some upfront investment in research, you substantially reduce the chances of your product ending in a graveyard.
Stage 4: I have sufficient secondary research. I can make my decisions based on that. Secondary research is not exactly you talking to the customers, but relying on somebody else who has done the job for you. This is sometimes fantastic and can help you fast-track your decisions. I have personally used this heavily at Microsoft and to a limited extent at Dineout. This is especially helpful in new market entry decisions where you may not have existing customers to talk to and it may require a significant investment to undertake primary research. However, the important thing to keep in mind is that these are not necessarily your customers. Also, you would want to check the neutrality of these studies by looking at the conductor/sponsor of the studies. (There were multiple studies in the 1950s and 1960s on how good smoking is for you. No prizes for guessing who the sponsor companies were for these studies!)
Finally, even for decisions like new market entry, while you may use secondary research to drop the markets you are less interested in, you may want to undertake primary research in the shortlisted markets to be more confident of your decisions before kicking off the dev-efforts.
Stage 5: We don't need external user research. We are all heavy users of the product ourselves: This one is the most frequently-countered resistance when you ask for user-research budgets and as it often happens, there is a Dilbert strip exposing the problems with this approach.
I always tell my mentees never to assume that they are the user especially when they actually are. As an example, PMs at Uber on the driver side of the platform will not assume that they are the users, but the ones on the passenger side may end up assuming that they are. This is because they may be using Uber heavily to commute to work, go grocery shopping, travel inter-city, etc. However, are they really using the product the way end-users are? (No Uber credits, Checking Ola/Lyft fares in parallel, Using medium-range Android phones, etc.). More importantly, the end-users will not have the patience to go through the complete funnel if any step appears off. They will simply drop off the funnel.
However, things are not totally bad with this approach. Talking to internal users, especially the ones who are closer to the customers than you are (sales, customer service agents, etc.), can actually tell you a lot about customers' problems. Some of my early user-behaviour learnings at OYO and Dineout respectively have been through tag-teaming with the sales teams on their customer visits just silently taking notes and listening to call recordings of customer-service agents talking with irate customers. Still, nothing beats the experience of learning directly from the customers and that's why let us move to stage 6.
Stage 6: I am being forced to conduct user research. Okay! I will do some user research. Congrats! If someone (a founder, a recently hired product leader or a UX researcher) is "forcing" you to conduct user research, you have graduated to stage 6. Whether you like it or not, you are finally engaging in talking to your users (and very soon, you will start liking it if you do it right). But be careful, user research for the sake of it can be more harmful than helpful. You may end up using the wrong method leading to poor results. (I have made this mistake myself and ended up making some wrong recommendations.) Knowingly or unknowingly, you may be asking leading questions nudging the users in the direction you want. (Example: "Here is a completely revamped prototype of our improved app. What do you like the most about this?") Hopefully, you can avoid these wrong choices and biases and the "forcer" will be there to guide you or catch you when you go off. At Dineout, this worked wonderfully well for us. Every product manager and every product designer (some of these had zero experience in user research) ranging from Associate PM/designer to the Chief Product Officer (me) had the target number of customer interactions in their OKRs as part of the goal-setting process. In a way, I was forcing my team to talk to more and more customers, but I was also closely involved in a good number of these studies before folks were ready to fly solo. All of us over-achieved the target goals and this resulted in significant improvements in our understanding of our customers and their problems and this reflected in better products that we shipped.
Stage 7: I don't need more user research. I know my users really well. You may notice that this stage is marked in green. That's why I say that stage 7 is more of an acceptance stage than that of denial. The operative phrase here is "more user research". That means the decision-maker (usually a PM, but can also be a business leader) has already conducted a decent amount of research and further research may probably lead to an analysis-paralysis kind of situation.
Primarily, one thing to be watchful of here is that the market realities change frequently and you want to be sure that you have a good handle on the latest status. As an example, your understanding may be based on users in Tier 1 cities of India, but now that you have expanded to Tier 2-3 cities, is your grasp on their needs still accurate? A new competitor is slowly taking the share of the market from you. To understand what the customers like about them, are you ready to wait till it's already too late?
That is why while it is okay not to undertake user research before every project, it is important not to lose the connection with your users.
What are the implications of knowing what stage the company/group is in? Depends on who you are.
If you are an early career PM applying for product roles, try to get into a company with an existing culture of user research and definitely stay away from companies in the red and orange zones (stages 1-3) if you can. The problem here is not just the lack of user research culture. These companies also tend to have a very heavy overlap with the ones, where product management is purely an execution function, not a strategic one. From stage 4 onwards, there is at least some acceptance of the utility of user research and if you are the one who can take the lead in this, it may fast-track your career in the company. But I repeat it's better to try and ingrain customer-first thinking based on talking to them relatively early in your career. So do try to find companies/managers who are supportive of this approach.
If you are a product leader with good user-research experience applying for a product leadership role, I would still suggest staying away from companies in the red zone (Stages 1-2). In the last five years since I moved back to India, I have had exploratory calls with decent-size startups, where the founders have uttered variants of stage 1 and stage 2 statements and the hubris told me that I would not enjoy working with them. But from stage 3 onwards, you may want to consider it. Discuss your success stories with user research and also your failures when the product bombed because of a lack of or poorly done user research. See if their eyes sparkle with an aha moment when they hear these. Check if they are open to giving you the autonomy to conduct user research and showcase the results. Maybe you are exactly the change they need to usher in a culture of customer-first thinking! Believe me when I say that transforming cultures is much more fulfilling as a leader than joining a company with the kind of culture you like.
If you are a founder/business leader for a company in stages 1-2, a blog like this will likely not convince you to change your mind. :-) However, whichever stage you are at, I can tell you the investment will be worth it if you are willing to give this an honest try. If you are an early-stage startup, you may need to don the researcher hat yourself, but usually, it is a good idea to get somebody who has experience doing this, preferably a product manager or a UX Researcher. (A traditional market researcher may do the job too, but they may not have the requisite expertise on the product/UX side of things.) If you need to go solo on this, I highly recommend one of my favourite books: The Mom's Test.
If you are already a product person (product manager/designer) at a company at one of the early stages, do not just give up on the company if you like your work otherwise. Try to see if there is a possibility to start with small low-cost investments. It may be as simple as calling your existing/ potential customers or shadowing them when they use your product or a substitute, but just talking to the customers is not sufficient. Go beyond the obvious and look for the aha moments. Are they using the product as intended? The feature that the sales team is pushing you for: is a spreadsheet or good old pen & paper a good enough alternative they are using in its absence? Show the company leadership some early wins and non-obvious insights and then gradually move higher up the ladder of customer-first thinking. One of the ways I have found effective in uncovering these aha moments is to do retrospective research on your existing products/features that failed and uncover what made them fail. What if your company is not willing to give you any autonomy to talk to the customers? This excerpt from another of my favourite books Escaping the build trap explains it better than I can:
How to conduct user research more effectively? Who should be primarily responsible for this? Which methods (Generative vs Evaluative, Behavioral vs Attitudinal, Quantitative vs Qualitative, etc.) are right for which situations? All of these are topics for a different blog spanning multiple posts. Stay tuned!
What are the impediments you have seen in adopting a culture of user research in your organization? What has worked for you and what has not? Let me know in the comments section.
If you liked the blog post and would like to be notified of future posts, you can subscribe to the future posts by creating a user account using the sign-up link on the top of this page.