How changing the product registration workflow resulted in +30k new products for Olist in six months?
*The content in this article isn’t confidential and can be shared
Problem/Goal
Being the product manager responsible for Olist’s catalog, I knew GMV was one of the leading financial metrics we had as a company.
The equation was simple: More products registered by sellers, following the publishing rate, would translate into more offers in the marketplaces, and chances to new sales would grow.
At that time, for any offer sellers were willing to sell, Olist required the barcode (GTIN). Because there were sellers in the user base that didn’t have this product identification, I knew some of them couldn’t register the total of their portfolio to sell at Olist.
Some sellers bought GTINs online from not trustful companies and others from places like GS1, but this one was a complex and expensive process.
So, we needed to allow these merchants to register their total portfolio without using third solutions. This means they wouldn’t leave Olist’s web app or hire other services, because the company’s vision was to be the backbone for sales liquidity, and we should provide a better solution to solve this challenge.
Solution
I started creating an Epic on Jira and wrote about the context and the problem we had. The idea was to help in future discussions with the designer and development team.
Once I finished it, instead of having a preliminary meeting with the designer, I thought it would be a better idea to gather the whole team together.
The reason was that I knew our technical architecture was developed to use barcode as one of the many product identifications. Afraid of researching solutions that could be useless because of this barrier, I scheduled a refinement to dig deeper into how our architecture was built to make the right decisions.
Even the Catalog team having three squads focusing on different initiatives, I invited the whole team to discuss the complexity and specific rules of Olist’s architecture.
I began sharing the challenges we were aiming to solve and how sellers were struggling. I also brought customer feedback that was collected from many sources like NPS surveys, support tickets, among others, to empathize the challenges with the team.
While we were talking, it got clear that changing the infrastructure to allow the product registration without the barcode would take many sprints, would involve other squads, and would be a complex implementation that could impact other system rules. Take out GTIN was an option, but not a fast and easy one.
I tried to facilitate the process to develop a simpler and faster way to tackle the problem, having something like an MVP that could be iterated and built with a minimum effort.
After some discussions, we understood how we should solve the problem. It would be from a design perspective.
We understood that the product registration flow should perform as a search engine. Instead of sellers starting to fill the product’s barcode, we would allow them to search what product they were willing to sell to make the process faster and easier.
We had the assumption that part of the sellers who didn’t have the barcode was because they didn’t know it, but the product had an identification. What about us allowing them to search the product if Olist had thousands of products in the catalog?
We had other refinements with the designer sharing how the workflow should work, and then the developers started to discuss how the system could fit into this solution.
From a technical perspective, Elasticsearch was the answer. From a design perspective, it was a remodeled user experience. From a product perspective, it was to build a minimal solution to validate our assumptions and evaluate the results as fast as we could.
Results/metrics
Before:
The unitary product registration and the mass product registration flows required GTIN to register a product.
By the query I did, six months before, there were +289k products registered at Olist’s catalog.
After:
Sellers could start the product registration flow by searching for any product at Olist’s catalog, writing the title, characteristics, or any other relevant information.
Six months later, after the full rollout, +30k new products were registered by just this feature.
Lessons Learned
- Sometimes, some problems we would like to solve, won’t have technical viability according to many reasons that can be time or scope. It’s essential to keep in mind that many problems can be solved from a design perspective. Airbnb and Uber are just two examples of companies solving problems and necessities by providing a better user experience.
- More developers thinking together about a specific topic can lead to better conclusions. Different experiences and backgrounds bring richer discussions and clarify new possibilities.