My Product Journey
Six months ago, I started my journey as a Product Manager at Mercadona Tech in the capacity vertical. Product management is so much more of an art than science that I believe everyone’s journey in the field would be unique. While I had done my prep through the basic PM survival kit (Marty Cagan and a high dose of Twitter), I don’t think any resource (especially this blog) could help you learn the things that hit you the hardest without actually going through them. I hope my journey gives you a perspective on what the crash landing in a PM role at Mercadona Tech feels like. But before we get into that, let’s get the first question that you may have out of the way, what the hell is this Indian dude doing in Valencia (Spain) working at Mercadona?
A little about me
I took the plunge to move to Valencia at the beginning of 2020 (wait, what else does that coincide with?). My girlfriend, who I met on an exchange program in Stockholm back in 2014, lived in Valencia. And after a lot of years of very worthy doubt, I decided to move cold turkey. The idea was to learn Spanish while I sorted my visa and looked for jobs…and then a global pandemic happened.
Luckily, the startup I worked for in India, a health-tech e-commerce company, went fully remote and offered me the job I had just quit before moving here. So, that’s how I spent the next 1.5 years balancing the job remotely with Spanish language classes.
Having worked previously in strategy consulting and strategic operations in a health-tech firm, I was itching to move closer and closer to “tech.” Now, Valencia isn’t a particularly large city. Wherever you are in the town, I can reach you in a 20 min bicycle ride. So I do think it’s absolutely nuts that I ended where I finally did — at arguably one of the best product and technology teams that Valencia (or even Spain) has to offer. Serendipity!
The first few days
Mercadona has a strong culture of training and investing in the employees early on. For the first few weeks, I shadowed Miguel Calatrava (my manager) as he went around his PM duties. The experience I gained during this time was invaluable. Everything that I do here — the way I approach problems, conduct meetings, resolve conflict — Miguel played a significant role as a mentor.
It was also a period of a lingering feeling of what can be best described as imposter syndrome. I had crash-landed in a challenging role where I was using a bunch of new tools that I had no idea about and was running in and out of meetings with engineers speaking technical concepts I didn’t understand. Moreover, there was the additional complexity of comprehending and presenting complex topics in a new language that I had just picked up a few months back — it felt like they had made a terrible mistake of hiring me.
The team
There are two groups of colleagues that will dominate the interactions you have in the first few weeks — the vertical layer of your cross-functional team and the horizontal layer of other PMs. It is hard to overstate how much impact these people can have on your experience.
I was lucky to have an excellent designer in Estela Ibañez who had just started her design career with me, although she had been in the Mercadona system for a long while. There was no question too stupid to ask her, which for me was a liberating option to have. It was great to have someone on the team who was, at times, as clueless about things as I was but at the same time, someone who understood the company and how to navigate it really well.
On the other hand, I have always been in awe of how strong a product team we have managed to build here. Apart from being top-notch at what they do, there’s a sense of congeniality — an altruistic support system to share your failures and a genuine celebration of each other’s successes.
The Oferta/ Capacity Vertical
Mercadona tech works in cross-functional vertical teams that focus on a particular problem. The team defines its objectives each quarter aligned with the company’s vision and has complete autonomy on how it wants to go about reaching them.
Our vertical, at its essence, works on an optimization problem to ensure that the “jefes” or clients have a delivery slot availability that they desire, and ensure that we can meet this availability promise with a high degree of service quality. In other words, we want to let you buy in your most desirable time slot and ensure that we actually meet that promise with our delivery team.
We have divided this problem into two parts —
i) The data science models that help us forecast demand and plan for resources,
ii) And the engineering infrastructure that is responsible for communicating the slot availability to each client
The seduction of control
As a product manager, you are sort of involved in everything, but at the same time, you’re not really “doing” anything. The line where the PM’s job starts or ends is very faintly defined and can vary not just from team to team but rather from context to context within the same team. This underlying paradox, I believe, is a constant source of conflict that is crucial to managing in the early days.
In our first quarter, we were working on the engineering infrastructure to help manage the process of oferta creation. This process was managed through a series of complicated excel files until then. We had to transfer the years of knowledge that these excel files had accumulated into a tool while preserving the flexibility they offered to the user. Estela and I repeatedly worked with our users to build prototypes that we thought could replace those excel files, only to be shot down by our engineers. They said we were trying too hard to jump to the solution without being clear of the problem we were trying to solve. In other words, we were trying to answer the “how” before being sure of “what.”
When I reflect on what happened during this period, it was a typical case that has repeated itself in various reincarnations. I, as a PM, was trying to do jobs that were simply not mine to do. I was trying too hard to control the solution, not trusting that the engineers were best placed to do that.
We changed our approach radically and focused on two things — defining accurately the hard constraints of the problem — what was a strict no from a user’s standpoint — and ensuring an efficient transfer of knowledge of existing excel files from the users to the engineers. I believe that the flexibility we were able to provide the engineering team within our defined constraints while having clear context was the main reason we built a successful product: entirely replacing the excel files within the first three months of our vertical’s existence.
¿Y eso?
And here, the random scribblings of this six-month roller-coaster ride come to an end. It has been a profound journey of self-discovery, given how much product management is related to psychology — a crash course on humility and empathy.
To all those PMs just starting — hang in there. It just gets better! I would love to know the challenges you faced on your PM journey.
