Avoid these questions when validating your startup idea
A major evolution in product development process can be attributed to the emphasis on validating your ideas before executing on them. The startup and business community in general has made a lot of progress in understanding the need for user/customer centric processes. Every podcast, every blog post these days recommends talking to your endusers and potential customers to understand their needs and validate assumptions. In this post, I hope to take this recommendation a step further and talk about some of the mistakes we make when we go interview our users.
"How much would you pay for this?"
On the surface this seems like such an obvious way to validate whether you have a winner at your hands. I mean, that's what we set out to find isn't it? Would potential customers be willing to pay for my product?
In reality, the uselessness of this question is matched well by the misery of how pervasive it is. The answer is often less about whether a person would buy something and more a reflection of how much they want you to like them.
If you've ever gone through this exercise and struggled to understand why the same people who were so ready to pay for your solution in the beginning, failed to commit when faced with a payment form, you're not alone. Even maker stars like Nathan Barry who created ConvertKit, learned this lesson the hard way — there's a big difference between people answering a hypothetical question and when they actually have to make a purchase decision with their credit card in their hand.
So how can we get the answer we're looking for? We still want to find out if our solution is worth anything before we implement them. Lets look at what a UX researcher would ask instead:
What applications do you currently pay for in this space? When was the last time you paid for one? What makes them worth it?
Why are these questions much better? Instead of the hypothetical, they focus on concrete facts. Instead of what your clients think, these questions focus on what they do. If I'm a person who has never paid for a mobile app, probability of me paying for yours is really low regardless of what I say. In addition, researching the products our client currently pays for, allows us to reasonably deduce the functionality to cost ratio.
"Look at this screenshot! Wouldn't this solve all your problems?"
Ever go to a potential client for idea validation and put a screenshot/prototype in-front of them right away? This is my personal favorite just because of the number of times I've been asked to do this.
Can you make a quick mockup of the solution so we have something to talk about in our first meeting with the client?
To clarify, this isn't a workflow validation meeting. I'm specifically talking about the very first time you meet a client to understand their needs and to validate your idea. The problem here is that as soon as we put something in-front of the client, the conversation becomes about identifying what is wrong with the half-baked prototype rather than the client's problem that we're trying to solve.
Initial meetings should be all about understanding the user's mental model and current workflow/pain points. Biasing ourselves or the users with our solution before hand, not only results in curbing our creativity for the rest of the process, but also fails to get any real validation for the product we're thinking of building.
Asking customers for solutions
Henry Ford's faster horse quote is recited to me at least a few times a year as an argument against user centric design process. If you are not aware of what I'm talking about, the quote is:
If I had asked people what they wanted, they would have said faster horses — Henry Ford, Founder of Ford Motor Company
Ok, so first of all, there's no evidence that he actually said it and second, one should never go to these interviews with the expectation to come out with a requirement spec for their project.
If the customer does propose a solution, it is important to take note, not as a requirement spec but as interview data. What is the difference? Interview data has to go through synthesis before anything can come out as requirement.
In the case of the quote above, here's an overly simplistic example of a user story:
"I want a faster horse" ⟶ synthesis ⟶ user X wants a faster horse so that she can get from point A to point B quicker.
We write user stories in the format above so that it's easy to bring out the real need from the user's point of view — get from point A to point B faster. Proposing a solution to that need can ultimately become a validated requirement (engine driven carriage?)
Going to the interview alone or with too many people
If you're a solo founder or the only UX person in your team, you know how difficult it is to carry a conversation, take notes, think of where to take the conversation next, all at the same time. The resultant notes are not comprehensive enough to get concrete actionable insights.
Having a designated note taker when talking to a client helps free you up to carry the conversation
When trying to gather feedback it's always a good idea to have a second person with you as a secondary. Secondary's main focus is taking notes while the primary drives the questions and conversation.
Having a partner while talking to the potential clients has the added benefit of them taking over when you're looking for what to talk about next. However, any more than 2 people is too many. To get honest answers, it is important that the client feels comfortable in these conversations which is simply not the case when she has 10 strangers listening to her every word.
In conclusion, there is no doubt that it is vital to validate our ideas before we commit to spending time and resource on execution. However, starting with incorrect validation process can be just as fruitless as starting without any, sometimes even worse. I hope that these tips are useful to you when you go make products and features that make all our lives better, one solution at a time!
