Mistakes to avoid during research
Here are some common mistakes PMs and product teams tend to make during the process of conducting research and a few ways one could avoid most of them.
Ideas, the Foundation of the PLC
We’ve heard this so often and it is largely true of the world as well, when it comes to ideas they are the foundation of the Product Life Cycle (PLC). You can be absolutely sure that most of the successful products today have had some seminal thoughts behind them, backing those notions as they turned ideas into a reality working tirelessly to evolve them and not only make them a fit to the current market space & time we’re living in, but also factor in the future times so as to be able to adapt if anything goes haywire or totally against a set plan.
Some outlandish thoughts often form the base of every pathbreaking discovery.
Talking of big flashy ideas, here’s one:
But ideas, tend to just be what they are “IDEAS”, unless some hardcore silos of work don’t go over planning and executing them encompassing numerous toils & hardships towards clearing hurdles & roadblocks so as to make it a reality. This part has pretty well been documented and written about across the product community.
Here’s an article that I have written over how ideas ought to be taken ahead stepwise, researching and helping one clear the clout entirely:
That article dives into the details of how ideas ought to be validated and it also has a reference to the business model canvas by Alex Osterwalder.
Truth be told:
“Products could still fail and not meet the threshold in spite of conducting research & discovery diligently”
Types of research
Undertaking research over methods like surveys, roundtables, focus groups are pretty common. The sole purpose of research is to find facts and draw conclusions which seems pretty evident as well.
On a very broad scale one could think of these types of research that products teams undertake.
Primary research
One of the most common types of research when teams go onto the field to collect the data that’s needed and they may choose from hitting the right touchpoints directly which may be pretty straightforward or to go over the market talking to random people and identifying / picking the ones that matter to them via a few basic introductory questions.
Secondary research
Another common type of research when teams would resort largely to online channels, websites, searches to gain access to the data they need to proceed with their fact-finding exercises.
Quantitative research
Research that’s conducted with a fixation / favoritism towards the numbers / Quant data which could be over anything as trivial as prices, sales, demographics to something more nuanced and complicated like data accumulated over stages or a lifecycle, usually known as funnels.
Qualitative research
Research that pins on identifying the quality aspects, measured over customer satisfaction (C-SAT), Net Promoter Score (NPS), Quality of Service (QOS) could be one of them that the service industry tracks.
Descriptive research
Research activity that’s undertaken with a target in mind, so as to satiate an already set prior goal, this could be deeply subjective to a specific feature in a large product.
Exploratory research
Research activity that goes leaps and bounds beyond any product, the sole aim of this kind of research would be to scope a given market over a number of quantified and unquantified variables, a few knowns and a lot of unknowns.
So, getting into what contributes to a healthy research, one could picture them as zones intersecting over a VENN, viz.:
Market
target market – a clear demarcation of who is the target market is & also who isn’t
competitors – a comprehensive list of competitors operating alongside their competitive edge
price points – a detailed study of the prices the market is paying for the current products & its capabilities
Product
product offering – what the product does, the competitive edge
problems solved – the problems each of those products are aiming to solve
value proposition – the value proposition of each of those products
User
pain points / needs – the pain areas as relevant to the users right now
motivations – the reasoning behind those pain points defining their wants
behavior – the behavioral understanding anchoring their motivations
At times we hear how product people feel like they are drowning into a pool of uncertainty when they ought to take some crucial decisions over each phase of the product. Most of those decisions could have some parity to it if the research got into covering a few of those aspects into much greater detail.
Usually the yields of research is measured over the ability to have thorough unbiased answers to these:
features –that make sense to build so as to satiate the users’ current needs and the choice of products that exist in the market today
fitment – the product to build so as to fit (read it as “retrofit”) that over a given market
But with major difficulty it branches into also covering for:
expectations – the user’s pain points and the motivations behind them inclusive of their behavioral understanding so as to tune it to standout against the options offered in the market
Question: Finding which one of these above three could be perceived as the best?
Answer: obviously – NONE.
Yes, you read that right.
Why?
Because there’s a big portion of understanding that totally goes amiss on finding just one of these 3 individual traits and neither is a combination of 2 of them going to work well.
If anything, research ought to cover all those 3 points above so as to build a total understanding of the markets, users & the products (white area at the heart of the VENN in the figure) sans which no further work ought to be undertaken.
CASE 1:
Some teams get into a silo of research, document those findings and then get onto the next phase over excavating something more to add to the list of findings.
Is that a good approach?
Well, YES! No doubt it is, provided someone out there is keeping a close tab on the research covered for, aggregating it all over some sort of an “idea backlog”.
CASE 2:
Also, some teams believe in getting over each phase / silo covering one area / dimension of research and factoring that understanding in to facilitate decision making and then believe in doing the rest of it on to go.
Is that a good approach?
Absolutely not, because the tendency is to make big ticket decisions also over silos which may not altogether be a great practice.
Re-emphasizing it all, good research when carried out meticulously ought to lead to a total comprehensive understanding over the existing market, the product and the users.
With that, we have a clearer path towards listing out the mistakes PMs and product teams make.
Common mistakes during research
There could be many mistakes that teams make while carrying out research activities. Some of the most common ones are:
Let’s dive-in now and see how one could combat each of them.
1) Finders keepers
This is like the kids looking for a lost object and the one who finds it gets to keep it and also brings the search to an end. Bringing research to a grinding halt on the first fact found that’s supporting a given hypothesis could be one of the worst things one can do. Why? Because that may just be the tip of the iceberg and maybe delving deeper could have landed one into much larger findings that could have helped the org. disrupt the market.
How to deal with it:
Have a few dedicated team members on research and discovery mode always. I could quote Continuous discovery here but that could be totally rhetorical. It’s a dynamically changing market & the users’ needs are no different. It’s important to have an eye always open and pointed towards studying the markets / users and aggregating those findings so as to help teams factor them in and ensure they work on the latest installment of the market’s needs.
2) Deep product / feature obsession
Sometimes some people of the product team tend to bow down to an internal voice that’s often deemed overbearing and the most powerful one in the room. So, product decisions / features driven totally by such HIPPOs aren’t subjected to any research as none of the team members want to push research ahead as they dread finding something that’d go against that BIG internal decision.
How to deal with it:
I know some feel it’s all easier said than done. But, believe me when I say product people aren’t paid to blindly nod and say “YES” to everything thrown at them. If anything, the exact opposite. We’re often paid to question the rationale behind everything and at times painstakingly oppose some decisions so as to make the right ones for the team / product / organization putting those goals & high-level business objectives at the helm.
3) Switching contexts
Many times, it could happen that research very well starts off as Descriptive with a specific thing in mind but then product teams tend to lose track of it all and happen to land into Exploratory mode of research without really making a conscious effort to move towards it that way. A major reason that could affect such a change is a few facts found could be misleading needing some more subjective research but teams may not be given the luxury of time and would be expected to furnish findings quick owing to the deadlines set.
How to deal with it:
When its all important to work with deadlines, it could be seminal to work with the right set of data that’s found over the research. If teams have spent some time over the research and it is still pointing to some ambiguity. It could mean that the quantum of effort hasn’t been well directed and immersed so as to cover those vulnerable aspects of the market which they should have. But, one needs to bite the bullet as a leader and push his team into some more fact finding and quick so as to get to a stage of obtaining data that could be considered insightful and actionable.
4) Heavy quantitative fixation
This happens when someone from the team believes so strongly in a certain idea or carrying a feature & feels totally justified in doing so owing to emotional attachment to it. Such people usually are known to use the research / survey questionnaire to bend questions inducing it with the necessary amount of bias just to drive a point home and see the numbers stacked in favor.
How to deal with it:
Never count on just one person’s research. Always get multiple people from your product teams to undertake research activities in various relevant pockets. Also, get some kind of checkpoints in over establishing a verifiable channel so as to plant enough evidences with the data stacked in favor so as to fallback upon it as and when deemed necessary.
5) Omitting the Users / VOM
One of the worst things any product team can do is to not talk to / interview the users enough so as to validate assumptions, understand their emotions, motivations & behaviors behind why they demand some set of features over a product or demand a new product altogether as opposed to the choices they already have in the market.
How to deal with it:
Get more product teams, in fact even the solutioning teams when the time is nigh to talk to the users and interface with them, spend time with them studying their workflow closely sans which you’re always under the threat of assuming something that may not be true and in the worst case, could even turn out to be the exact opposite as well.
6) Vague descriptions
Most times the descriptions of the target market, customer segments the & problem statement are so vague and indiscreet that the whole idea of research tends more towards the generic EXPLORATORY kind than the DESCRIPTIVE kind.
How to deal with it:
This often happens in large organizations where the research unit works separately surveying their way into the markets over a quest to find some specific and useful information that’d be useful. This could be avoided by holding up research activities until such point that it starts to mean something over the definition of say a proper idea / hypothesis.
Please remember:
It could all be very easy to lose track or make assumptions about the parameters that strongly contribute towards providing the necessary clarity when conducting research and what’s more and contrarian to common belief, the best of people and teams have been guilty of committing these errors.
All that sunk costs fallacy and tech debt could largely be avoided more so given that these problems aren’t that difficult to identify and resolve.