
Loading summary
A
For me, speed was more important than perfection at the beginning. As a cpo, you need to realize fast why you were hired, what's the biggest gap and why companies are looking to hire you as a cpo. And so for me, there was a gap around product strategy. And the suggestion there would be not wait for perfection, but try to put whatever it's in your mind, write it down, share it with as many people as you possibly can, get feedback and iterate on that. Because I think at that point, when you start on a new role, execution is more important than crafting the best strategy. I think product management is about managing opposites. You have to think big, but you have to go deep in the details. You have to work with complexity, but you need to simplify. You have to be customer obsessed, but you need to move fast and be pragmatic. You want to think long term, but we have a quarter closing. We have to deliver. You need to develop conviction, but you need to be changed and be flexible all the time. So there's a lot of opposing forces that you need to manage. And that's for me, product management is more of an art than a science.
B
Creating great products isn't just about product managers and their day to day interactions with developers. It's about how an organization supports products as a whole. The systems, the processes and cultures in place that help companies deliver value to their customers. With the help of some boundary pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you think like a great product leader. This is the Product Thinking Podcast. Here's your host, Melissa Perry. Hello and welcome to another episode of the Product Thinking Podcast. Joining us today is Fabio Broca, the Chief Product Officer at Zanetta, a platform transforming the ocean and air freight industry. With over a decade of experience in product management, Fabio has launched products in multiple countries and built software to manage some of the largest supply chains in the world. At Zonetta, Fabio is leading efforts to bring transparency and innovation to a traditionally complex and opaque industry. His career also includes key roles at Amazon, where he oversaw the product team working on global transportation technology, and at msc, the world's largest container shipping company. Today, Fabio will share his insights on leading product teams, transitioning from big tech to a scale up and his rapid rise to cpo. But before we talk to Fabio, it's time for Dear Melissa. This is a segment of the show where you can ask me any of your burning product management questions and I answer them every single week. Go to Dearmelissa Dot com and let me know what's on your mind. Today's episode is brought to you by liveblocks, the platform that turns your product into a place that users want to be. With ready made collaborative features, you can supercharge your product with experiences that only top tier companies have been able to perfect until now. Think AI copilots like Notion, multiplayer like Figma, Comments and notifications like Linear, and even collaborative editing like Google Docs and all of that with minimal configuration or maintenance required. Companies from all kinds of industries and stages count on live blocks to drive engagement and growth in their products. Join them today and give your users an experience that turns them into daily active users. Sign up for a free account today at liveblocks IO. Let's look at this week's question. Dear Melissa, I work at a company where we currently have product managers and engineers in the US and Canada, but due to corporate strategy change there is a shift to hire engineers in India instead. Meanwhile, the product managers and engineering manager will remain in the us I have worked in prior companies with similar global distribution and it was always a challenge given the time zone difference and cultural difference. Do you have any recommendations on how to do this? Well, what are your honest views on this type of hiring strategy? So I've worked with a lot of teams that are remote. I've worked with engineers in Europe. I've also worked with a lot of teams in India as well. When I was at athenahealth, we did have a huge presence in India with our engineering teams and and there are some ways to set this up super successfully. The easier part with Europe when you have engineers there especially, is that we have some overlap with the US time zones. If you're in California, not as much, but if you're in your East Coast, Europe usually works out pretty well. India though, many hours difference here, so we've got 12 hours sometimes longer differences between these two time zones. That's where we start to get into an issue where we'll have barely any overlap during the day whatsoever. Now I've worked with some teams in India that do purposely skew their hours so that they have some overlap with the us so I've worked with some development teams that actually come in later, stay a little bit later so we get some of that overlapping time and I do think that's good practice so that you can have a little bit of FaceTime there. So you don't want to make it where you have absolutely no overlap whatsoever. So you do want to have some kind of overlap, whether it's A couple hours or even an hour during the day where you can work together. And if you can't do that every single day, you're going to have to do it periodically. The biggest issue when you're not overlapping one to one with all of your hours is that if somebody has questions or there's any confusion, you can't get answers, you can't actually clarify. So that's usually what people's biggest fear is when they're working with developers. So you want to figure out ways to actually prevent that. And I don't think that's bad product management. You want to try to build context with these engineers that are in India about what you're building so that they can make decisions in your absence. That's what you're trying to do. So the ways that you do that is by having kickoff meetings, deep dives where you are working together and you're in a singular meeting where you share with them the context about what we're building, why we're building it, information about the customers, information about the goals, really spell out what you're hoping to achieve with the product. All of that different stuff. You want to make sure that all that context is really well understood so that if they come up with an A or B scenario where they go do I do this or that? They can have that type of knowledge and make those decisions themselves and then they can check it with you later. But it's not going to stop them from continuing. Now of course there are some showstopper questions that will come up that may stop them or they may have to transition to something else to be able to get an answer in the morning. That's always going to come up, but if you can limit that, it'll make it a little bit more seamless. So that's why you really have to focus on building the context there. The other thing that you're going to need is documentation. And we've worked really successfully with teams where we make sure that we document decisions that have been made, questions that have been answered, where we left off on the day before, and have all of that information in a place where they can easily find it when they come into work the next day. There's no way around this. I know everybody talks about Agile being less about documentation, but you will need more documentation if you can't have as many face to face conversations. Now if you want to go ideal here and say, how should teams be designed remotely? What we found is that having the entire team co located in one area is the Best way to do it. So when we set up teams at athenahealth, we did have product managers and engineering managers in India and we had usually VPs of product were located in the US and we made sure that we were overlapping with those product managers and those engineering managers to make sure that we were sharing strategy context, they were invited to the meetings. We skewed some of our meetings a little bit later for them or earlier and we made sure there was some overlapping time during the week. We also sent people to India all the time to build that camaraderie, to get that FaceTime, to have that kind of travel meeting face to face so that you know who you're working with. So that's something that you'll have to think about as well. Now if you can't do that, which it sounds like you won't, with the engineering manager and the PM being in the US and Canada, that's okay, you're going to have to do that documentation. You're going to have to find time to actually do those kickoff meetings, find some FaceTime, find some overlapping time during the week, help set them up so that they can run smoothly and make sure that you're minimizing the types of questions that will pop up. But inevitably you're going to have questions. So that's my best recommendations for how to do this. Ideally though, if you can co locate more people in the same areas, it's always going to be smoother. Another way to think about it is do you have an engineering lead in India that you can tap to work with you and the engineering manager to help centralize some of this information too, so that they can be a point person where you might be able to overlap more with them rather than with the whole team all the time. Still going to have to overlap with the whole team sometimes, but that person should should be identified and you should have a strong person there to work with you and brainstorm with you and be that counterpart in that face in India as well. So those are some tips that I've seen to actually make this work. It's not impossible. Teams do this every single day. You may not be able to follow extreme best practices as we would think about it in an agile manner. But I don't know anybody who's doing agile by the book in best practices anyway. So you're gonna have to think about what are the problems that are coming up and what is our way of working and how do we do this successfully and start to create processes and governance and documents and communication tactics that work for you rather than just reading something out of a book. So I hope that helps. Good luck. Like I said, this is doable. It's just a little bit different of the ways of working. That's it for dear Melissa this time. If you have any more questions for me, go to dear melissa.com and let me know what they are. Now let's go talk to Fabio. Hi Fabio, welcome to the show.
A
Hi Melissa. Big fan here. Thanks for having me.
B
So you've had a very impressive career that spans over a decade, leading product teams in some of the most complex and large scale industries. Can you share with us what initially drew you to the field of product management?
A
Yeah, I came into product by mistake and I started working as an intern for a company called msc, which is the largest container shipping line in the world. And I started to grow on the business side, first managing teams and then managing office. And at a certain point, MSC was looking for people that were good with computers and software to fill this role. That was Business Transformation manager. And the job was to roll out an IT system across different countries. So I was going to different countries, spending time with customers, figuring out gaps in our current solution, working with engineers to build it, launch it, test that everything was working fine, and then move into the next country. So it was effectively a product job. But I didn't know that and I didn't even know what product was. And I only learned about that when in 2020 I decided to move on and I started to apply for Amazon and I look for everything that had to deal with transportation technology. And there were a lot of those product managers role available. And so I look at requirements, I think I'm doing that job. And I applied to all of them and I got into Amazon as a product manager for Vehicle Telemat. And that's the first time that I really understood that I was doing product work. I understood what product management was, but I also understood that sometimes the career path are not planned and sometimes they are discovered through following your passion and an industry that you find fascinating. So I stumbled upon product management rather than jumping into it.
B
I think that's similar to a lot of us. I didn't know what it was either when I got started. So when what keeps you passionate now that you're in it about working in all these very complex industries?
A
Yeah. So let me tell you a story. My first day when I joined as an intern, my manager took me on the side and he said I had to show you this secret. And for the first time in my Life. He shows me how to operate a fax machine. And so I was completely shocked. It was like we were back in the 50s. But I was impressed. And I saw the opportunity from the very first time to improve processes using data and technology. And I saw a lot of opportunities to continuously learn something new. I also love the fact that shipping and transportation is a very physical industry. You are touching things. You are moving containers or airplanes. And there's a beautiful book called 90% of everything that shows that 90% of everything around us, from the books in my shelves to your microphone, everything at a certain point in their life travels on a container. And so it's extremely fascinating as a product manager to make decisions. And you can see the impact of your decision on the real world. The other thing that I truly love about it is that is one of the biggest scale that I can imagine. When you manage supply chain optimization for Amazon or what we do now, which is Benchmarking for over 170,000, port to port combination, the scale of the problems that we solve with such a huge. And that's very fascinating for me. So I fell in love with the opportunities and the impact that I could have in the industry.
B
When you look back on your career so far, what do you consider to be your most significant accomplishments and how has that shaped your approach to product management?
A
Yeah, I thought about this question a lot, and it's an interview question, but my definition of significant accomplishment changed a lot throughout my journey. So the beginning, really, I wanted to become a manager, and then I wanted to be a bigger manager and then jump into product. But if you ask me this question every time, I'm probably going to look at my biggest accomplishment as the one that has to come next. And so most recently, I'm very proud of the work that we did to launch, to complete the Zaneta Summit, which is our biggest event that we did last year in Amsterdam, and I had to deliver a keynote in front of thousands of people. And it was such an incredible experience for me. So I'm very proud of that. But the way that it shaped my approach to leadership is that over time, because I kept seeing bigger and bigger things coming, I became really optimistic. And I think as a product leader, being optimistic is a really important part of our job. The second thing that I realize, if I think about this question is that what gives me a lot of pride and satisfaction is growing people that are working with me. So the ability to impact people's life in the same way that people impacted mine. So throughout my journey, there are Many people that took bet on me, whether it was me running an office when I was 25, 26 years old, or getting a product role without knowing product management, or getting your first CPO role, I think there are many people that help me, and I feel the responsibility to give back and do the same for others. So I think an important part of leadership for me is coaching, and it's really how can I help people to see their potential even when they don't see it, and how can I help them flourish? So I think coaching is a very important part of product leadership, and I've learned that throughout my journey.
B
So you recently stepped into the Chief Product Officer role at Zenetta for the first time. When you look back on those first couple months, what were some of your biggest challenges and what did you do to tackle them?
A
Yeah, there were many. The first one is I was very ambitious. And so you want to get to the CPO role as fast as possible. You do months of interviews and then you get there and you don't really know what the job is. There's no school, there's no guideline. And so the first challenge was I didn't really know what the job was, and the way I tackled it was to take classes and certification. And so that's where I attended the CPO accelerator and. But reading, getting in contact with other CPOs, trying to figure out what the job really is, that was like, first challenge. The second one is, as a cpo, you're not necessarily leading your product team, but you're broadly leading your company. And so there's a lot of things that I had to learn that were outside of product. For me, it was, you know, finance, sales, strategy, product marketing. And I had to learn fast. So I tried to build the right relationship within the company to connect with the people who could teach me these things that I. That I didn't know. The third challenge, I think as a cpo, you need to realize fast why you were hired, what's the biggest gap, and why companies are looking to hire you as a cpo. And so for me, there was a gap around product strategy. And the suggestion there would be not wait for perfection, but try to put whatever it's in your mind, write it down, share it with as many people as you possibly can, get feedback and iterate on that, because I think at that point, when you start on a new role, execution is more important than crafting the best strategy. And if you execute really, really well, you can get so many feedback that you can change and tweak and improve your strategy until you get it right. So for me, speed was more important than perfection at the beginning. And then maybe the last couple of challenges is as a cpo, many things change for you compared to when you are ahead of product or leading a team. And one is it's super hard to get feedback. People are somewhat afraid to tell you when you do things wrong. And so you have to make sure that you build a culture where people feel safe and that you push people to give you feedback when you're not doing things right. So that was important. And finally one of the biggest challenge was at Amazon I was still jumping in many different things and if a product manager was leaving and we had a gap, I could jump in, do the work myself and try to push the product forward. I tried to do that at Zaneta, but you just don't have enough time because you have so many competing requirements. You're working up with the board, you're working with the C team, so you cannot dedicate the same amount of time to tactical product management work. So the things that you learn fast is if you're managing a roadmap or creating JIRA ticket as a cpo, that's probably too low for you. And so one of the challenges was for me, how do I uplevel myself to a more strategic role?
B
When you think on that last one, I think that's a big challenge that a lot of CPOs do. And I see them going down, taking over what the team is doing, trying to jump in there. What did you do to make sure that you weren't getting pulled into the weeds too much?
A
Yeah, I think it's about delegation and I think it's about acknowledging that in a scale up or in a smaller company you will never have enough resources. And so for me it's how we think about prioritization, it's how we think about what can you delegate. For example, we had an extremely strong engineering team and engineering manager and so I was able to provide just a little bit of context and guidance and then let them run with it and accept that some of the things are not going to be perfect or product perfect, but it's still better than me getting involved in super tactical detail and then I would not be able to do the strategy work or to work cross functional with other C team members.
B
You were also talking a little bit about trying to establish that product vision, the strategy early on, put it out there, what were some of the techniques that you did to establish that early on and also to make it Apparent that you were the leader here. Right. Like, I stepped in the role. I'm the CPO now. I've got this under control. What kind of things did you do?
A
Yeah, I think a lot about relationship building. And one. One thing that was important for me is Zenetta is a Norwegian company and I'm based in the U.S. so there was a lot of travel at the BE, and you want to spend as much time as you can with the key people to build those relationships, which I think are easier to build in person than remote. So be there. I think BE human was also very important. And be vulnerable around the things that I don't know yet, both with my team and with the executives, so that you can learn them or you can figure out what's the best way to make a decision together. So that was very important as far as strategy development, what we did. So at the beginning, even before I joined, I tried to think about what would I do as a cpo. And I had kind of a business case as part of my interview process where you had to come up with a strategy. And so I started from that, and then I tried to spend a lot of time workshopping with the C team, where we really tried to articulate where do we want to be three years from now, five years from now? And we got very clear on where do we want to be. And then we figure out what are the biggest challenges we need to solve next to be able to get there in the long term. And so we really focused on actions and things that we could practically do and tackle. And we figure out what are the three biggest challenges that we want to. That we want to address. And that became somewhat the product strategy. So we articulate what's the work that we want to do around those three pillars, and then how does that work translate into product objectives and problems to solve? And then I assign that to product managers as part of the yearly plan. The other thing that I think helped establish my leadership was to look at what the teams were doing and try to organize it a bit and see where there are things that you can do right away. And so for me, one was to. We were just working on too many different things, and we had a lot of initiatives where we had one engineer and one product manager. And so we were moving slow because we were spreading investment too thin. And so bringing a bit of focus, forcing a bit this conversation about prioritization and what should we do and what's the trade off if we keep investing in 10,000 things at the same time? And I think that helped establish credibility with the leadership team and with the CEO and with the board.
B
That last one I see as a huge issue for a lot of new CPOs, just a lot of companies in general. What did you do to get a grasp on what was the work in progress and to understand if you were spreading yourself too thin, what did you do like tactically when you got in there to get your head wrapped around what was currently going on?
A
Yeah. So you try to understand how the teams are working and you try to understand what's in the back logo, what are we working on, what are. And then there were some documents. There was. When I say that there was no strategy, I'm being unfair. Right. There was a strategy, but the strategy was we need to do more. And so the strategy itself, I think was leading us to try to work on too many different things. So building of clarity around the three biggest problems to solve, that helped us to focus a lot. The other thing that I did was going across and discussing with all the engineering managers about what is that we're working on, what do we have on the roadmap and trying to figure out, do we really need to do all these things that we want to do. And there was a lot of iteration on current products rather than innovation and building completely new things. And so I, I thought we were a bit unbalanced within that. And raising this discussion to the executive team, to the cto, I think that was very beneficial for us to have those conversations. So those are some of the things that tactically I did one thing that everyone loved, which was very important. I think it's every strategic document we have a section that says what is that we are not going to do? And in that one we usually articulate how good of those ideas are. Because as a scale up, there are so many different good ideas that you could go after. But because of the strategy or because of different decision, what are the one that you want to really test faster and move quicker on. So I think that was key for us is to really say those ideas are really, really good, but we are not doing it. And this is why. And that's what we are going to prioritize.
B
I love that idea. I have not heard of people actually taking the time to acknowledge that their good ideas there. And some of the hesitation I see when we say we're not going to do things is people yell, oh, but it's a good idea. By recognizing that, I think that's a really nice step to say, yeah, we know that we just can't do it yet. It's not the right idea to do right now.
A
The other thing that I believe is important is when you think about funding and how many engineers or scientists do you need for each initiative. We want to think about what would it take to make this happen fast. So you don't want to have funding of one engineer for three years to build this feature. I want to put a team of five or 10 and build it in a quarter because that's going to allow you to experiment and learn faster. And so I think that was another mistake that we were doing. We were stretching out initiatives for a long time rather than focusing and trying to move faster. So also when you think about the greatest idea that you're not going to do, you want to articulate how many people would it take to do it properly, because that might be a trade off that the board or the executive team wants to make. And maybe we can go hire five engineers to go test this new idea. But it needs to be clear that it's five engineers for a quarter and not one engineer for a year and a half.
B
Yeah, I like that. And that prevents you from peanut buttering, which is what I call it, just spreading everybody too thin. I think we like to get into this mentality of as long as somebody's working on it, that means it's valuable and it's going to get done. But we never think about when it's a nice counterbalance. So coming in, Zenita, you before this you were working at Amazon and you were the head of product for Global Transportation technology. Amazon's a huge company. Can you tell us a little bit about what the transition was like from a large established organization like Amazon to more of a growth stage organization like Zenitha?
A
Yeah, for sure. Amazon was super structured, right? As a pm, all you have to think about this product, you have processes like working backward PRFAQs. There are tools to write and to write these processes. There are clear deliverables. It's very clear what you need to do to get promoted or to go to the next level. We had finance teams that were working with us to estimate the impact of initiatives. We have program managers to manage dependencies across teams. So there's so much structure around you that all you need to do is to be really, really good at product. In a company like Zonetta, it's the opposite, right? There's no structure. You have to create it. You have to prioritize what structure is really important for you at this stage of the company. You have to be Willing a bit to be scrappier. I think prioritization is even more important, not necessarily because Amazon is frugal, but because Amazon can afford to test and place more bets than a company like Zenetta. So I think prioritization is more important for scale up. And I always like to say at Amazon, as a product manager, you have to adapt to the culture in a scale up, as a product manager, you have to build the culture so it flips it around. And some of the things about Amazon is also there's a lot of dependencies between different teams. You might have multiple product teams and engineering teams working on the same space. And so it's about divide and conquer, it's about managing dependencies. At Zenetta, we don't have that. It's all on us. And so you have to be even more ruthless in prioritizing and managing. I do think also in a way managing product strategy in a scale up, it's easier than not at Amazon because at Amazon there are so many layers and so many VPs and executives that there's a lot of convincing and alignment needs to happen before you can start building. While at the Neta, at the end of the day there's a handful of people that you have to convince and what they really care about is the output that you're going to create when you launch all this stuff. So I think it's a bit easier to sell a roadmap and a strategy to a scale up rather than it is in a big tech company.
B
That's really interesting. Two perspectives. When you look at the product management culture and the leadership culture between the two environments, what do you think are the two biggest differences? Not two biggest, but some of the biggest differences.
A
Yeah. So maybe around product management the roles at Amazon were very defined. So PMs are very clear on their roles. At Zenetta you have to do a bit of everything and you need to jump into areas where maybe we don't have the right staffing or there are issues, so to mention one, we don't really have program management. At Zenetta, the product managers are expected to run their project to manage dependencies, communications, stakeholders and so on. Decision making is also different because Amazon is a very heavily. It's a writing culture. Everything is a document, every major decision is a document. And it's very peculiar on how you write documents and what needs to be there. And so while we adopted a bit of this writing culture, we also relaxed it quite a bit in Zaneta to be able to move faster. And we don't lose too much ourselves in the form of writing. But this decision making maybe is the third one. Amazon has been better data driven for a long time and so you have easily access to data to people that know where to find the data. It's easier in general to be data driven in a company like Amazon than it is in a scale up. Most of the time in a scale up we don't have data. We never tried this thing before and we don't really know. On the other hand, because we are such a smaller company, you have easier access to customers. And so I get less data than Amazon, but I do more facetime with customers. So I think it's about adapting your leadership style to whatever you are and then from a leadership perspective. One of the things that was impressive for me at Amazon was that leaders, they are really able to dive deep into the smallest of the details. I remember when I joined Amazon, my first couple of weeks, I had to write the document around safety thresholds for vehicle telematics. And it was quite a complex and tactical and technical topic. And I remember going in front of a VP and the VP was asking a super tactical question to find exactly the gap in my reasoning that I should have considered. So that was very impressive. And at Zenetta we don't have the same culture and I am the one that needs to ask the questions. So it's a skill that I think you need to build as a leader as you grow. But we have to be, I have to be faster in figuring out what is the right questions to ask even when I'm not an expert on the specific topic. And finally, maybe another difference that I think is interesting. Amazon is so big, right? Last time I checked, 1.6, 1.7 million employees worldwide. So there are a lot of layers and it's very hard for product managers to know the full context to be able to make decisions at the lower level. So there's a lot of approval and there's a lot of documents that need to be approved and travel up before you can make things happen. As a product manager in a smaller company, as a product leader, you do a good job to give the right context to the PMs. The PMs are more empowered, I think, to make decisions at their level and they can make decision faster because they don't need all these different level of approval. So I think you can move much faster in a scale up than you can in a company. In a big tech company.
B
I hear a lot of people in product management considering big tech versus scale up versus Startup. When you look at your experiences though, between a big tech company like Amazon and a growth stage like Zanetta, what are the similarities? What stayed constant for you where you felt like you had a good handle and you were able to transition?
A
Well, Yeah, I think product discovery was quite developed in both realities. And so even at Zenetta, we have great UX research, function and talent and we talk to customers quite a lot. So your ability to validate information and experiment, I think that was constant between the two. I think from an engineering perspective, the way that we build product using agile practices, bi weekly sprints, empower teams, I think that was also quite similar. I think one other similarity between the two was that the energy between the two companies was similar. So in both spaces there's a really good culture around innovation and a very compelling vision of transforming the space that we're working on, which I think it is very empowering, both in big tech and in a scale up. So if I were to decide and if I were to give a suggestion to product people, I would try to do both because you can learn very different skills and very different things based on where you are. Amazon was a bigger learning opportunity because there is so much resources around the roles and you have so much coaching and mentoring and guidance that I think is an incredible school for a product manager to grow in their career. A scale up is an incredible place to go after you have done big tech experience because then you can really prove yourself and you don't have this big shoulder of a tech giant behind you to protect your decisions, but it's really more in your hands. So it's, it's different. I love both experiences and I would recommend anyone, if they can, to try to do both.
B
When we're talking about growth stage companies, we mentioned in here like a lack of resources. Right. We have very small team. How do you at Zanetta really empower your team with the limited resources they have, with the few fewer people that you have to really take ownership over their product and still be innovative? Right. Still go after and try to discover opportunities. We should go after.
A
Yeah. So I think that's a bit of a misconception of big tech because people think Amazon has all the resources in the world and we can invest. But Amazon was very frugal and so there's a lot of internal competition for resources, but it was not unlimited resources. However, I think the difference is that Amazon can afford to place more bets and you can afford to be around more time because you don't depend on a single bet for the success of your company. So in Zenith, I think you need to be really more focused and figure out out of all the innovation that are possible, which one are the one that really help us to grow faster. And so what we did, I think the strategic work was a very important context for this. So explaining to articulating for everyone in the organization where do we want to be in the future helped each team to come up with their own priorities and figure out what should we do next to solve this problem. I think something that helped us to go fast is we assigned different challenges to product managers and we increase the seniority of the product management team. So they own their space, they own the strategies within the space and they can make decisions as part of the annual planning of what features do we want to build, what are the hypotheses that we want to test, what are the problems that we want to solve? So we do a three year strategy exercise mostly led by myself, then each product manager they plan for the following year. But we have a very high level idea of we think those are the five features we want to build in this space. And then we really go down to timelines and strict planning on a quarterly level. So this allow us from quarter over quarter we can shift priority between different projects. We can go test new ideas if something new comes up in the market. But the product managers are the ultimate owners of their space. I think that's important. Some other tactical stuff that I think I do that helps to get speed. I do a lot of experimentation by myself, especially when it's a brand new idea and we don't really, you know, it's just an idea that you heard from a customer. But maybe it's worth exploring. I tend to do a lot of those experimentation and validation with early customers myself. And I think it's such a cool learning experience for me to share something new that I enjoy that and it doesn't take away from product management effort until we know that there is enough traction there. The other one, I think for the most ambitious problems and maybe ambiguous, we usually pull people out of the systems, right? So I would take one product manager, move it outside of all the mechanisms and they really need to focus for a quarter to do discovery on this new ambiguous space. They usually work with one or two engineers, maybe a data science and they really go figure out what to do in this new space. So I think by taking people out of the system you give them freedom to go and explore and experiment a bit more and you can move faster. But that's Definitely something that we do to gain some speed. And finally, maybe when I think about experimentation, it's not necessarily only about the product and the features, it's also about the business model that you want to use. Maybe it's about the sales channel that you want to try, marketing messaging. So in general, I think about experimentation not only limited to the product function, but also to all these other functions where if we experiment a bit more and we get some feedback from clients, we can move even faster. And so I really think about product management as experimentation and I think that helps us to remain agile and to be fast.
B
When you think about shipping containers too, I work with a lot of industries where we're not necessarily pure SaaS. Right. And we're working in these very complex, highly compliant industries. How do you approach creating software and what might be different, for example, about creating software in a complex industry like shipping and logistics compared to pure SaaS or B2C type shopping experiences?
A
Yeah, I think there's a. I've heard this a lot in my career, but every industry, like shipping, people always think that the problems you're solving are unique. This industry is so unique and it's so difficult to automate or it's so difficult to solve this problem. What I found in my career is that there are very few unique problems in the world. So most of the time you can learn from different industries that are similar. And so I think that's quite important in shipping. The second thing is you are fighting against a lot of inertia. And so I will never forget at a certain point I was director of Business Transformation Pharmacy and I go on stage to present new product launches. And at the end of the speech, one of the senior VP of the company jumps on stage with me and he says, you're moving too fast, this is not good for the industry. We're moving too fast, we need to slow down. And that's the type of fear and inertia that you are fighting against. I think the way that there's a lot of stakeholders, management and change management that needs to happen internally with the people in your company, your team, your industry, to be able to move the needle. And so I think an important part when you are in a non traditional industry is really how do you bring people, companies with you in the journey? How do you make sure that they understand the goodness of the products and the vision that you have? And it's a lot of people and relationship management. So earning trust and I think face to face time and spending time with customers and with People, I think that's particularly important for this industry.
B
So you have deep experience in the freight industry too. Can you tell us a little bit about the inefficiencies that this industry faces? And then what challenges are you trying to tackle at Zanetta?
A
Yeah. So let me give you an example. If today you are a big company and you're shipping hundreds of thousands of containers, you have two options. You can go and buy a spot, a slot on a ship, on the spot market, short term market, or you can sign a contract. And if you have a lot of volume, you sign a contract, probably you're going to get a better price. The problem when you sign a contract is that this market is very volatile. We have seen cost of a shipping a container going from $20,000 to $50. And so the market moves a lot and it depends on a myriad of factors like geopolitical events, tariffs, port strikes, the Suez Canal closure, and there's always something happening. The second challenge is that the market is very opaque. So the market participants don't really know what the rates should be in the market. I always give these examples like you're trying to buy a house, but you don't know what the houses in the neighborhood are selling for. And so you're kind of in the dark. And so What Zenetta did 12 years ago, we started to collect contract information from large shippers. We anonymize, we aggregate, we standardize and we provide some market level benchmark so that you can go in our platform and search over 170,000 port to port combination and we tell you what's the market price in long term contracts and in short term market. So I think we have done an incredibly good job to become the source of truth for this data. But there are still many challenges that, that we want to solve. One is if usually you do all this negotiation and then your market position remains pretty much what it was before the negotiation, then why do we do this in the first place? Could we just attach our contracts to an index and maybe follow that? That's what we call indexing. And we see this happening in other industries like the oil and gas or commodities. So how can we help the industry to transition to indexing? The second challenge is that we provide a lot of data, it's a data product to customers, but we still ask people to put effort to come up with the right insights or what they should do about it. And so we can make it easier, we can make it more personalized, we can come up with insights that are specific to Customers.
B
Sounds like Genai may be a solution somewhere in here. How are you integrating that into your solutions? What are you thinking about Genai going forward for your challenges?
A
Yeah, I think it's going to be a new way to access data and we are in a unique position because we have all these data assets. So I think it's going to provide new ways to interact with data. We have experimented a lot this year and we launched at our summit. We were presenting a chatbot experience where you can ask what's happening to the market. I do not think personally the chat experience is where we need to go. There's a lot about being able to generate insights. I like the idea of graph generation and visualization generation through Gen AI. So that's all stuff that we are exploring. But even I think Gen AI is the new kid of the block and everyone is excited, but there's so much more we can do with traditional AI. And so one of the latest product that we launched, for example, is around forecasting and we call it Market Rate Outlook. We do a three months and six month rate outlook in the future. And we took a very unique approach where we combine machine learning and AI with the power of market expert that we have in Zanetta, together with the power of the community. So we don't really go full black box machine learning spit out a number, but we try to always provide context and information on why we think the market is going to move in a certain direction. So it's very exciting space, it's moving fast. I think we are for Gen AI we're very much experimenting and trying different things for AI. We do have some products that are already been used quite a bit.
B
Very cool. So I hear from a lot of product managers that work in traditional places like banks or things that don't really feel new and exciting, let's say, because everybody wants to be part of the Facebook or part of the Amazon or something like that. You've built a very successful career in shipping and logistics. What is your advice for people out there who may be considering going into an industry that might not sound super glamorous? And how should they really approach that when they think about their product management career?
A
Yeah, it's maybe a trade off between glamorousness and speed of growth in your career? I think so. For me it worked very well to get passionate about a space like transportation because I do think that industry knowledge really matters and I probably would have not made it to CPO that fast if I kept changing and swapping industries. So I think what it does for you, it helps you a lot to build the right empathy with the customers and to deeply understand what's the problem that they're facing. So I'm not saying I will never change from transportation, maybe I will. But I think one of the reasons why I grew so fast is because there were a lot of opportunities in this unglamorous industry and it was easier to kind of get into the right trains and to grow fast. The other thing that I think about a lot though, the more I stay in the same industry, I always want to be able to have the right curiosity and don't take things for granted. Once you stay a long time in the same industry, you start to understand how things are done in the industry or what you can or cannot change. And I always try to be very worried about it, where I want to be able to look at things with the beginner's mind. And finally, the way I think about it, the industry doesn't really matter as much at the beginning of your career. What really matter is who you work for, your manager and the people that you're in front of you Mentoring you are disproportionately important versus the industry where you work with. So for me, I'd like to think about learning and how can I position myself in the place where I can learn the most. And so for me, even msc, when I started as an intern, it was an incredible company because there was so much training around the industry and you get the opportunity to go visit a terminal, be on board of a ship. And so those experiences, if I look at it now, 12, 15 years after, they all mattered a lot. But when you're there, you don't really recognize it. So I think it's figure out a good manager, figure out a good company that you can work for and try to learn as much as you can. Don't be too afraid of the title or the name of the role that you're doing, but really try to focus on learning because I think that's how long term that is what matters.
B
Of course, there are things that people should look out for when joining an industry that might be traditional or so to adapt to software. What are some of the challenges that people should be aware of?
A
Yeah, I think we spoke a bit about it. There's inertia in this non traditional industry. Change is quite more difficult to implement. And also the main business of shipping companies is not to build technology, is to ship stuff, is to move containers, is to do logistics. And so most of the time you are Improving costs, you're improving efficiencies, you're automating things. And the reality is that there are not so many great product companies in the space. So you really have to do a lot of studies and research, and you need to be always willing to see what's happening outside of your industry and how can you learn and how can you try some of this stuff in your industry? So I think it's a. It's really about how you think about learning from different industries that maybe are more glamorous and more advanced, but how do you bring that back to your unique context?
B
Fabio, when you look at product management, what is your core philosophy about it that keeps you going and keeps driving your leadership mantras?
A
Yeah, I have several beliefs, maybe that I can share. The first one, I think product management is essentially about customer empathy. To be a really good product manager, you have to deeply feel bad for the customer's problem that they have and that you're trying to solve. So I think it's about customer empathy. It's about waking up in the morning thinking about how you can improve your customer's life. And for me, this affected my leadership because every decision that we try to make, we always think, would the customer make the same decision if they were here today? So we always start from the customers. The second one, I think it's product management is really about obsession, and that's something that works very, very well for me. I tend to obsess very easily when I'm in a new space or something new. I really go down rabbit holes. I read everything I can, I watch all videos that I possibly can, and you get borderline disillusion about what's possible. And you have to do that because you have to be able to convince yourself that there's no failure, there's only learning and this thing is possible and we're going to make it, and that's how we're going to make it. So I think there's this level of optimism and disillusionment that is important to be a good product manager. And this shapes my leadership because it helps me to really raise the standards for what good looks like and what a good product manager is supposed to do. The third belief is I think product management is about managing opposites. You have to think big, but you have to go deep in the details. You have to work with complexity, but you need to simplify. You have to be customer obsessed, but you need to move fast and be pragmatic. You want to think long term, but we have a Quarter closing. We have to deliver. You need to develop conviction, but you need to be changed and be flexible all the time. So there's a lot of opposing forces that you need to manage. And that's. For me, product management is more of an art than a science. There are aspects that are scientific, but it's really more about art. And like art, I think the journey never ends. Like the greatest artists, they never stop learning, get to the point where they're great, but they keep working on their craft and figuring out new learning opportunities. So I think about product as balancing opposite. And like art, I think product is about experimentation. And I'm Italian. I've been to hundreds of museums all across Europe all my life. I'm always impressed about the sketch, sketchbooks. You go to Florence and you can see Leonardo da Vinci's sketchbooks, where he was drawing the same thing a thousand times in many different ways from different angles, until you find the perfect one. And then when you go and it was making the masterpiece, I think about product in the same way. And all your experiments, prototype, user testing, they're just sketches in your notebook. And it's never really finished. It's about iteration. It's about continuously improving and experimenting until you find what works. So there's a quote that I found on this, which is, art is never finished, is only abandoned. And I think the same is true for product.
B
I love that. I think that's. I've never heard that analogy before, but I think it's such a good one. To wrap this up, too, I've got two questions for you. There are some unsung people in product management who are doing great work. Who do you think of that should need more notoriety for what they've been doing? And what can we learn from them?
A
Yeah, I can give you three of my closest friends that are building great things in the world. The first one is my former boss at Amazon. Paul King is now at Maersk. Paul taught me a lot about the importance of coaching and leading with empathy and really thinking about and putting people first. The second one is a good friend of mine, Michele Sankrica is the CEO of a company called Secro. He's building a tremendous new product. He's building a company and he taught me what high standards really mean. And I'm very thankful for him and the friendship. And then finally, I want to call out, he's not a product manager, he's an engineer. His name is Matt Fischo. He's a really good friend, a business partner, and he's trying to build the first retractable lightsaber and it's an amazing hardware product. And Matt is teaching me a lot about building hardware manufacturing and really building a community of raving fans.
B
Man, my sister is going to be so excited about that. She's a huge Star wars fan. I can't wait to show her. And then, last question for you. What would you tell your younger self?
A
I would say most of the things that you are worried about will never happen. Makes no sense to worry. When someone tells you no, what they really are trying to say is not now. And then there's one that you know, I have a 14 years old son so I tell him a lot this one because he's always worried about figuring out his way and what am I going to do when I grow older. And I would say it's okay not to know. I still think I don't know and that's okay. And the magic I think is in the journey. It's not really nailing the answer. So enjoy the journey and enjoy life.
B
I think that's great advice to live by. Thank you so much, Fabio for being on the show. If people want to learn more about you, where can they go?
A
Yeah, I am not super active on social media, but I do have LinkedIn, so LinkedIn is where you can find me.
B
Okay. And we will put the link to your profile there so everybody can go check it out. All of the links and the people that you mentioned as well will be linked to@productthinkingpodcast.com in our show notes for today's episode. Thanks again, Fabio for being on the podcast and thank you to our listeners. We'll be back next Wednesday with another amazing guest, so make sure that you like and subscribe. And if you have any questions for me about product management, go to DearMelissa.com and let me know what they are. We'll see you next time.
Host: Melissa Perri
Guest: Fabio Brocca, Chief Product Officer (CPO) at Xeneta
Date: February 12, 2025
In this episode, Melissa Perri sits down with Fabio Brocca, CPO at Xeneta, a platform transforming the ocean and air freight industry. Drawing on his deep experience at companies like MSC, Amazon, and now Xeneta, Fabio shares hard-won lessons on navigating product leadership in complex, traditional industries. The conversation explores Fabio’s journey into product management, his approach to leadership and strategy, transitioning from big tech to a scale-up environment, and the art of balancing customer empathy with business pragmatism. For anyone aspiring to product leadership in high-stakes, regulated, or complex sectors, this episode delivers actionable insights and candid reflections.
[09:38]
[11:18]
[12:49]
[14:45]
[18:43]
[24:44]
[32:33]
[36:37]
[38:24]
[40:44]
[42:40]
[46:17]
For more on Fabio Brocca, connect with him on LinkedIn.
Show notes and links: productthinkingpodcast.com