Product Research Should Not Be An Afterthought  -  Here's why

By Hendy Yudhistira

In any organisation that operates in a rapidly growing industry, creating new products, features, and services is an everyday phenomenon. In an early stage startup, if the stakes are low and resources are scarce, “Launch now, think later” can be the most efficient way to go about things. However, as a company matures, resources become (relatively) abundant, you won’t have the luxury of low stakes. Messing up a product means it’ll either cost the company millions of dollars, or damage the brand perception in the consumer’s point of view.

This is where product research comes into picture — To minimise the risk.

As researchers, we are often understood by the rest of the organisation as the voice of the consumers. While there’s nothing wrong with it, this often becomes a trap that leads us to only being involved in the middle of the project, when stakeholders feel that it is time to talk to the consumers. As a result, the research function becomes the validator of their idea and we start getting requests like:

“We have this idea, let’s talk to the users to shape it, WHILE we take care of the business side of things”.

Or even worse, we might hear something like:

“We have this idea, but we don’t know what consumer problems can be solved. So, let’s find what problem we can solve using this product”.

These are common misconceptions even we, as researchers, may not really think about by default. We happily accept the job and excitedly start talking to the consumers about new, innovative product ideas.

What could go wrong

If we do things in parallel, we can come into a conclusion quicker. But then, we could realise that the business calculation doesn’t show if a product has potential or if it’s not technically feasible as of now. The whole project gets cancelled and the research study made specific for that project is simply scrapped.

If we launch a product, but there’s no real consumer problems tied to it in the beginning, we could find out in the end that the product is poorly received as it doesn’t solve any real problem.

If the idea comes from a benchmarking from other markets, it probably solves a consumer problem in another market, but not in ours.

In those scenarios, the time and money invested on the research project could have been spent somewhere else, if we knew from the beginning that the project shouldn’t have been executed in the first place.

So, what do we do then?

Before deciding to move forward with the project, we will want to trace back the thinking process of the stakeholders by asking them one simple question:

Why do you think this has potential?

If the answer is still quite vague, or you sense that their justification might be biased, you might want to recommend them to start a collaboration and start from square one to discuss Business, Users, and Solution — and the correlation between the three.

When we are creating a solution for the users (usually in the form of product / feature), there should be a justification which indicates it solves a real problem and ultimately, it has to serve our business metrics.

The core of a solution is always the business. Yes, I said it.

We usually ask questions like:

What is the business objective or what are the metrics you want to improve? Conversion Rates? Retention? Increasing revenue?

However, after business objective is defined, the common mistake is jumping right into the solutions. This may result in the consumer problem being merely an afterthought, kind of like:

“This is the right solution, so please do your research to identify what problems we can solve through this product, while we start the dev. Your insights will be considered for Milestone 2”.

We believe that a solution should be defined by the consumer problem.

So, it is not recommended to jump into a solution, just because a competitor does it, or it works for consumers on the other side of the globe.

Define your consumers first

• Gather information on the previously identified consumer behaviour or problems that could be relevant for the business objective
• If previous research is not sufficient, start doing primary research to define the problem. For example, in my team, we have found in the past that people running errands are still underserved by our existing services at the time and there are problems in this segment that we can tackle.
• After the consumer problem is defined, we can start to figure out how big the market size is or how many people are facing a certain pain point. Is it sizable enough for us to achieve the aforementioned business objective? Using errands as an example, we can calculate the frequency of errands trips within a certain period and / or how “painful” it is when they use their current solution to do errands trips
• Then, lastly, we can define our solutions in the form of concept, and test it to the consumers, qualitatively, quantitatively, or both. Then, we can start discussing with the product / strategy team how big is the market that we can confidently capture.
• Ultimately, can it achieve the aforementioned business objective?

While many organisations want to always be customer centric, we shouldn’t forget that new products should eventually be financially sustainable. Customers liking the idea is not enough justification to launch a new product. This is also why we have OKRs and north star metrics. Every single effort is done to achieve them.

This whole process could lead to a conclusion that we shouldn’t move forward with a solution we have tested because the impact is not big enough. This is a bold route which most teams hesitate taking.

“What if my stakeholders review me poorly”
“What if this blocks the progress of the organisation?’

If you feel this way, it’s normal. However, such setbacks are sometimes the best option to saves everyone’s precious time and money.

“But in my organisation, market sizing is the Product Owner’s Responsibility”

Then it’s great! It’s an opportunity between two functions to collaborate. In fact, it is important for researchers to provide a perspective on those market sizing data. If we turn a blind eye thinking it’s not our responsibility, we might realise too late it was a project that shouldn’t have happened in the first place.

As researchers, we can provide a second opinion and give a different angle. Here are some things to look out for:

• For a product to be launched in multiple cities, looking at one area to justify the whole market might not be enough. For example, we identify there is a need for a cheaper transport option in Surabaya, but that data alone won’t be enough to move the project forward since we might need to look at other cities as well.
• Time frame of data collection is also a common thing we challenge, especially when data collected for less than a month is presented. There are time periods where user behaviour may change (for example, during holidays and festivals). This could give a false positive signal.
• The market is too broad, which, as a result, can lead to false estimation of market size.

The partnership between research and product / marketing / strategy teams should be deeper than passing on responsibilities like “you do your homework and I’ll do mine”. It should be a two-way and constant interaction. After all, the success of the product is owned by everyone.

Summing it all up

👉 First off, your interaction with the product and strategy team should be deeper than just validating: You can help the Product Teams to define the problem statement and size the market potential. Researchers should be involved since the very beginning.

This is probably the hardest of all.

However, organisations should change in a way that allows Product Researchers to step in a product development since the very beginning.

Once Product Researchers are involved in the product development, the whole process should be started with ample time e.g. at least 3–6 months before a single line of code is written. Take that time to complete all the homework required, as previously mentioned. Also, by having longer time, we’d be able to avoid the need to do everything all at once.

👉 Even when you don’t do the market/impact sizing, ask to take a look and provide a fresh set of eyes to the project. After all, this is your product too.

👉 Take it one step at a time. You wouldn’t want to waste resources to do everything all at once. But then, you realise the product shouldn’t have been executed in the first place.

👉 Ensure you’re on the same page with your business teams. This helps you provide a coherent input during conversations regarding the potential business impact.

We hope that this is useful to strengthen your collaboration with your stakeholders. Always remember that a researcher’s job does not start only when asked to validate things. Be the thinking partner for your stakeholders from defining the problem until a solution is launched and developed.

Read more stories from our vault, here.
To view open job positions, click here: