- Now let's talk about
defining customer research techniques.
If the key to building the right product
is to understand customer needs,
we need to rely on customer research.
However, in many instances, our understanding
of what the customers need, or even who the customers are
is not accurate.
No matter how well we know those customers,
our understanding of what they need is just an assumption
unless we create the right data.
This is a hypothesis and we need data to have it validated.
As Henry Ford is said to have stated once,
"If I had asked people what they wanted,
they'd have said a faster horse."
This way a car would never be invented.
A true product visionary frequently comes
with the ideas that others have not yet suggested or tested.
And yet there is a need to validate those ideas
before implementing them commercially.
User research focusing on understanding user behaviors,
needs, and observations through a number of techniques
is really important.
Those techniques range from the observation
of users in their natural surroundings
to interviewing them about the experience
with a specific working product and everything in between.
It's an iterative and cyclical process.
In lesson two, we discussed the lean startup framework
that provides ways to validate customer hypothesis.
And we spoke
about design thinking models that are used to design
and prototype products.
However, this is not sufficient to define the right product.
In order to achieve validated learning from customers,
four steps as regards to user research are most important.
The first one is to identify the right customers
that represent the target personas for your product.
The second one is to define the way
of collecting this feedback.
Could be customer interviews,
observation of customer interaction with prototypes
or existing products, surveys, web analytics, and so forth.
Third one is to actually conduct this research
and use measurable results to validate your hypothesis.
And finally, you have to aggregate
and interpret all the data from the research and compare it
against the hypothesis in a non ambiguous, data-driven way
and do your validation and the final decision.
So once the problem is identified
it is very important to define how to measure it
and how many respondents are required for your research.
For example, if the user research method
involves comprehensive interviews, then the number
of customers who participates in the research is fairly low.
And if you do web analytics research,
then the number is in hundreds.
Finally, it is helpful to identify success criteria.
Whether your hypothesis will be validated
by a simple majority of respondents
or you need a specific percentage of users
that will confirm your assumption.
And the most important rule
and the mistake that frequently is being done
is to never ask a question that starts with, would you,
would you buy it?
Would you use it?
Those responses do not validate customer behavior.
And actually most customers would confirm
that they're interested in using
the tool or software or product
because there is no obligation on their part yet.
In addition, these types of questions cause respondents
to guess about behavior
rather than share facts about their actual behavior.
You can show your customers a prototype of your product
followed by a set of questions,
or simply observe the interaction with the prototype.
That's much more impactful.
And finally, you can always conduct interviews.
A simple and yet very powerful interviewing approach
is called a three point interview.
It consists of three questions.
Question number one, have you ever had
like this specific problem?
If they say no at this point,
assumption is invalidated and you have to pivot.
Start with something totally different.
Second question.
Tell me more
about the last time you had this specific problem.
What did you do?
Here you look for them to actually do something about it.
And third question for you.
What is the ideal solution in that situation?
So third question is not perfect,
and yet it gives you the direction
for your solution that you can at least start with.
So now let's talk a little bit
about conducting the research itself.
Customers have to be available first
and in agreement with the research.
Sometimes they have to sign an agreement.
No matter whether they're internal or external
they need to be recruited.
And there are multiple ways of reaching out to customers
and giving them different sorts of incentives
so that they participate in your research.
For example, in case of external customers
you can offer them participation in a better product
or discount on your product for a specific period of time.
I give them a gift card.
In case of internal customers,
you can incentivize them by supporting them
and solving the actual problem that they're facing.
Also, researchers have to have an interview script.
They have to allocate sufficient time for interviews.
Never rush an interview.
If you are absolutely time boxed, just cut it short,
don't try to rush through answers.
You have to make your participants comfortable
and very clear about the expectations.
And if there are any legal aspects and other constraints,
you have to take care of them in advance.
For example, if you may want
to have your external participants
to sign a nondisclosure agreement or NDA
before showing them any prototypes of your future product.
And all the results are accurately documented by interviews
in a predefined format.
Tips for conducting user interviews are as follows.
The most effective interviews are with one person at a time
because groupthink, when one answer influences others,
is misleading and happens frequently.
Also when there are multiple researchers
the respondents may feel uncomfortable
so try to do it one on one.
It is important to know the goals
and questions ahead of time.
So give this courtesy to your interviewees
if it is possible.
A prioritized list of assumptions
is used to generate a list of questions.
You don't share this list
but it's helpful to have those with among interviewers.
It's also advisable to clarify
and adjust the questions based on the respondents.
But again, there always has to be a clear script
to start with.
Now you have to define what interview type it is.
Try to separate behavior interviews
from feedback interviews.
If the goal
for the research is to understand customer needs,
then ask about the gaps
between their needs and the available functionality.
If the goal is to get the feedback on features
of a specific product, use your prototype
and ask about usability aspects.
Also you have to stay open minded and get excited
about hearing hard truth.
Don't try to hide or to avoid any negative feedback.
If you're really invested in your product, project,
or service, it's very easy to overlook negative feedback
and start selling your product to respondents
or cause them to be unnecessary polite with you.
So encourage and embrace negative feedback
because it'll save you effort going forward.
Remember we said in lean startup, fail early and often.
We want to prevent the mistake
so negative feedback is the most helpful.
Active listening is also the key.
It is important to help customers
to provide their unbiased feedback to you.
Open ended questions are most effective
and definitely significantly more effective
than yes-no questions.
Try to avoid binary answers by opening your questions.
So if a customer pauses, do not try to fill the gap.
Give them time to think.
The goal is for you to learn, not to market your product.
And finally, we need to aggregate and interpret the data.
This step is extremely important
because of the way the data is aggregated and presented.
This way will influence your final decision.
This is one of the reasons why the metrics
and success criteria are defined in advance.
Based on the result,
the decision is made whether to pivot
or change the business model
or one of the most fundamental assumptions,
or persevere and proceed as originally intended.
It's important to base decisions on data
rather than speculations and your interpretation of answers.
Even if this is coming from the customers.
As both Henry Ford and Steve Jobs have shown,
the features that customers ask for
are never as interesting as why they really want them.