4 Questions To Avoid When Validating Your Startup Idea
A major evolution in the product development process has been the emphasis on validating ideas before executing them. The startup and business community has generally made a lot of progress in understanding the need for user- and -customer-centric processes. Every podcast or blog post these days recommends talking to your end users 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 questions we ask — and ultimately, the mistakes we make — when we interview our users.
1. "How much would you pay for this?"
On the surface, this question 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 of 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 successful indie makers 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.
Let’s 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.
2. "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 scenario 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 situation 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’s 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 or pain points. Biasing ourselves or the users with our solution beforehand not only curbs our creativity for the rest of the process but also fails to get any real validation for the product we're thinking of building.
3. “Can you tell us what the solution should be?”
Henry Ford's “faster horse” quote is recited to me at least a few times a year as an argument against the user-centric design process. If you’re 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’s important to take note, not as a requirement spec but as interview data. What’s the difference? Interview data has to go through synthesis before anything can come out as a 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 quickly.
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 — getting from point A to point B faster. Proposing a solution to that need can ultimately become a validated requirement (like an engine-driven carriage).
4. “Should we bring more people to the user interview?”
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, and think of where to take the conversation next, all at once. The resulting notes aren’t comprehensive enough to get concrete, actionable insights.
Having a designated notetaker when talking to a client helps free you up to carry the conversation.
When gathering feedback, it's always a good idea to have a second person with you in a secondary role. The secondary's main focus is taking notes while the primary leads the questions and conversation.
Having a partner while talking to potential clients has the added benefit of them taking over when you're looking for what to talk about next.
However, more than two people are too many. To get honest answers, it’s important that the client feels comfortable in these conversations — which is simply not the case when 10 strangers are listening to their every word.
In conclusion, it’s undoubtedly vital to validate our ideas before we commit to spending time and resources on execution. However, starting with an incorrect validation process can be just as fruitless as starting without any, sometimes even worse.
I hope that these tips are useful to you as you go make products and features that make all our lives better, one solution at a time!
