We’ve reached our season finale of Product to Product’s second season! 🙌

Listen to the episode below:

In our final episode of the season, we explore the human side of product one last time. And making it even more special, it’s our first live podcast recording. We’re joined by Gustavo Melo, Senior Product Manager at Amazon. (Fun fact: Our CEO Latif Nanji and Gustavo used to work together, so it makes this convo even more exciting.)

When Gustavo (or Gus for short) joined Amazon’s wedding registry product team, he sensed some tension. The technical side of his team wanted to develop cool features, while the non-technical side wanted to deliver business value. Seeing this major gap, Gustavo took it upon himself to reverse this tense team culture around.

Latif sat down with Gustavo to understand how he managed to do a 180 with his team’s tense working relationships. Gustavo offers practical steps other product people can take when trying to bridge the gap between the technical and non-tech sides of their team.

Tune in one last time this season, as after this episode we’re taking a short break. We’ll be back before you know it with a brand new season and theme. ✌️

The episode can be listened to above, and we’ve also included a transcript below. You can subscribe to Product to Product on iTunes (here) and Google Play (here), or get the latest episodes delivered to your inbox by subscribing here.

Latif: Gus, welcome to the podcast.

Gustavo: Thank you, sir.

Latif: Could you tell us about what you do at Amazon.

Gustavo: So, I’m a Senior Product Manager at Amazon, and I manage the wedding registry product.

Latif: Can you tell us a little bit about your team structure there? Is it under the pretence of the two pizzas per team?

Gustavo: That sounds about right. Everybody loves to talk about the two pizza teams for Amazon, and wedding registry is a great example of that. But we have a team that centralizes our marketing product, engineering, all under one single team. Probably in total, we’re about 15 people and that’s sort of split out between those different functions.

Latif: Were you the first product manager on this team?

Gustavo: I’m the only product manager on this team.

Latif: So, can you set the tone for us and tell us a little bit about what the relationship was like when you started between the technical and non-technical people within your team.

Gustavo: I think, as I was coming into the role, there were actually a few changes in place, structure-wise. And the big one was we were unifying the tech and non-tech people together. Before that, there was essentially separation there, where the tech team is reporting into a tech manager; non-tech team is reporting to a separate management structure; and there’s a matrix relationship between the teams where they collaborate on projects.

Latif: Was that something you were familiar to seeing, and what kind of challenges did that present in terms of communication between the two teams?

Gustavo: Well, it’s a pretty common setup, depending on different companies you look at. I’ve worked at a couple of places where an engineering team reports to an engineering VP. You had a non-tech team, whether it’s people planning product or marketing, reporting to a whole separate structure, and you don’t really see both of those converging until the very top of the organization.

For smaller companies and organizations, that’s not a big deal because everybody’s together, and you’re all, just by definition, growing in the same direction. Amazon is very much my first time working at a large corporate environment, so I thought it’s been interesting to see how that presents some differences.

Latif: Talk a little bit about those differences. Myself having come from a startup, even if product and engineering are in two separate teams, we try to think of them as product development—as one unit moving forward. But in a large organization there might be reporting structures, and they have differences in terms of their incentives or motivations. Can you talk a little bit about what challenges that presented you and how you overcame them?

Gustavo: When I came in, the team was essentially in the process of merging. I was hired as the first product manager within this new team to actually lead this initiative forward, and we were just at that point where now you have tech and non-tech working together under sort of the same single leader, which is a common theme at Amazon.It’s just how we like to do things.

But one of the bigger challenges there is definitely, culturally speaking, when you have a team of engineers that’s used to operating almost in a silo. You might have an initial document that comes from a non-tech team that says, “Here’s what we’d like to do”, thrown over the wall, and you wait, right? As a product manager, you might provide that document, wait a while, see what engineering comes up with and either launch it or not launch it, depending on what that looks like. When I came in, it was very much the beginnings of trying to change that towards, “How do you align what we’re planning with what we’re building in a much faster, more collaborative way?”

Latif: I think almost every product manager I’ve ever talked to, experienced or not, has gone through this. All they’re really hoping for is engineering to think the way that they do, and so this is a fairly common problem. How did you approach that problem? How did you will it in the way that became most effective for you and your team?

Gustavo: Ultimately, that’s where the people aspect comes into play because the mechanisms that you put in place where you say, “We’re going to start doing joint planning sessions and review sessions for our plan documents. We’re going to do joint reviews of the project design.” All of that is great and it all makes sense, but everybody tries to do that in some way, shape, or form. Seeing meaningful change in outputs comes from how you relate to the people you’re working with. How you relate to the engineering team, the relationships you build there, and the day to day working methodologies that you put in place.

Latif: Absolutely. For the audience, Gus and I have known each other for some years. We’ve been in these organizations that are twenty to fifty or even at most a hundred people, and so if we want to build those relationships, it’s really quick and easy because you can go over to their desk. It’s not at another building. You can grab lunch with them. At Amazon, or any other large corporation, what are your thoughts on how those relationships can be built faster so that it can enable that team to drive home their product to market?

Gustavo: I think there are a couple of approaches to it. My Amazon experience has been lucky in that regard because my particular team is all sitting together in the same building. One of the things that we actually did was move the engineering team down one floor so that they were literally just one room away from all the non-tech folks. And that, I think, made a larger impact than I thought it would. Now we all organically see each other every day because there’s only one kitchen on this floor. Everybody has to pass by the kitchen at some point, or see each other outside of just the sprint planning and the daily stand ups. From an Amazon standpoint, I think I’ve been lucky in that regard.

But the bigger question is how do you deal with an engineering team that maybe is located in a different country. There are plenty of examples of teams within Amazon and even some of the other companies that I’ve worked with. I get a lot of practice with that at Amazon, when we interact with different teams. When our team needs to get a project done that involves collaboration with a whole different team within Amazon, doing that is super interesting because their product manager might be located in Seattle, their marketing people might be located in New York, and their developers might be located in India or anywhere else in between. To do that, I think comes down to what principles are bringing people together and how they work day-to-day. What are the specific principles that drive the decisions that you are making and that’s the one thing that I think Amazon excels at. You go to the Amazon website, you look up the Amazon leadership principles, and there is that list of 12 or 14 of them that people really live and breathe.

Latif: What would be a principle that you’ve had to rely on to bind the non-technical and technical teams together? Or have you had to pull from other sources as well?

Gustavo: For Amazon, it’s two big things that have worked for us: our stress principle and the dive deep principle. Diving deep has been a tremendous positive for me as a non-tech person who has been out of the tech hands-on game for almost ten years now. I started my career as a developer, but I haven’t really worked in code for a long time now. The newer generation of development tools and languages, I really don’t have an instinct for anymore. Being able to sit down with somebody from the development team or to do a phone call or screen share session, where we’re talking about what’s going on with this project. What are the specifics of what we’re designing for? What are the difficulties that the engineering team is facing and delivering on that vision? What are the trade-offs they’re having to make with their designs? Really diving deep into that and forcing yourself to understand from a technology perspective, why are these trade-offs important.

One example might be, you are trying to build a feature that sends out an email to your customers whenever they take a specific action. If your engineering team comes back to you with a design that doesn’t look like the original thing that you pitched, you have two choices there. You can say, “No, I mean this is not what the requirements were”, or you can sit down and try to understand where they’re coming from. Try to understand what technology challenges they faced to come up with the design that they ended up with. That’s the big difference I think between PMs that work very effectively with tech teams and PMs that end up having to rely on other people to help bridge that gap. Both ways work. I’ve done a lot better by working directly with engineering teams without needing an intermediary.

Latif: It sounds like there might have been some challenges along the way and you were able to get to a point where you were having those deep dive conversations. Before that though, was there chaos that needed to be corrected and what did that look like?

Gustavo: One of the interesting situations that you find yourself in when you have a technical and business team working towards their list of priorities and trying to align the two and come up with the outputs that everybody wants, is that you have different interests. You may have people on the technical side say, “What we really need to do is migrate the system over to this new technology and we’re investing 30% of our resources over the next three months to go do that because it’s super important.” And you have a business team saying, “Well, what we really ought to be doing is launching the new version of the main feature that 80% of our customers use everyday before the end of this quarter, because that’s really the biggest lever we have to drive the growth we want.”

When you have that in place and you have two teams that have two separate reporting structures, how do you resolve that conflict? How do you get somebody who manages an engineering team and somebody who manages a business team to align on how things should be prioritized and organized. We love to say that product management is about owning that roadmap and saying, “Okay, I know what’s important for the business as a whole. I took input from everybody and I’m making the call.” But that’s not how the world works. You can make the call but if your team isn’t aligned with that call, you’re going to have friction all the way.

Latif: How did you change that culture? It sounds like a problem whereby these teams each have their different sets of priorities. Product management is responsible for setting the priorities. It’s really not necessarily just a playbook you can run because of the different types of personalities that may be in the room as well as the structure of those teams. So how did you come to a means of solving that tension so that the teams could move together and be aligned?

Gustavo: One thing that comes to mind is an example from a different company before I joined Amazon where the technology team said, “Let’s migrate to this new platform” and the business team said “We need to launch this new feature ASAP.” Coming into Amazon, I had some previous experience dealing with that exact challenge, where okay, I have seen first hand what happens if what I do as a fresh product manager is put my foot down and say, “No, this is what’s important. This is why it’s important. We are going to go ahead and do this. That other thing can wait.” I saw the practical results of that where first you get friction from your engineering team, and second you probably get some attrition on your team if these projects are long term enough. Ultimately, you don’t get the best quality product at the end of the day because your team doesn’t have their hearts into building it.

My approach at Amazon was much more people-focused and continues to be much more people-focused. I spent a huge amount of my time investing into having deep conversations with the people that were leading and managing the technology delivery of our projects. We have a software development manager who the developers report to. The biggest key to better results that we are talking about came from building that bridge between those two roles. Myself from the business point of view saying, “Okay, here is everything for what’s out there today, what’s important for our business and why.” But at the same time I realize that as a developer, maybe you don’t necessarily connect to all of those points. Half of your motivation comes from just building cool technology or working on the projects that you know will improve operational performance and so forth. Building that bridge and being able to align with the person leading the technology delivery means saying, “What are your priorities? Why are those your priorities? Let’s have a frank conversation. As much effort as I’ve put into outlining my reasoning for why the businesses should move in a certain direction, I need to get the same back from you on the technology piece. I am putting in the effort, you need to put in the same level of effort.”

A part of why this is such a great success story for me is because I got super lucky in having a tremendous partner on the technology side, who was not only capable of doing that, but a natural at doing that. Once that conversation starts coming out, both sides very quickly realize that there is room for compromise everywhere and there is room for compromise in deliver—without compromising on the outcome that you’re trying to get.

Latif: What were some of the immediate effects you found from having those positive conversations, with respect to the product, and then what were some of the longer term effects that you’ve seen?

Gustavo: Probably the greatest immediate effect everybody on the team saw was, when you talked to a developer or when you talked to myself as a PM, we started having the same answers for a simple question like, “What are the top three priorities for us to deliver over the next quarter?” That sounds like an obvious thing to say but it’s really not. When you don’t have that alignment where people believe the things that you are working towards and you ask them in a hallway chat or over coffee, “What do you think are the top priorities?” you don’t get the same answers because people speak from the heart or from whatever their personal views are.

As soon as they started to see that we had frank conversations about what needs to get done, in what order it’s going to get done, I did my part to drive as much clarity into that as humanly possible. Making it stupid simple even though we have very complex projects and very complex delivery. There are just three simple lines on the whiteboard and every time we all get into work, we see those same three lines are still on the whiteboard. These are our top three priorities right now. There is very little room for misalignment there, once people buy into it.

The biggest effect of that is, I don’t have to worry at every stand-up or every sprint planning session about whether what the team is working towards is really the stuff that we want to be able to deliver on. Once that worry falls away, I spend less time policing and monitoring and trying to be reactive and I spend more time thinking about what comes next or how I can help improve delivery of this thing. How can I drive more clarity to a piece of the requirements? How can I start working on the next thing that we’re going to have to deliver? That increases productivity for everybody.

Long term, I think team culture is the biggest long term effect. The culture of the team as a whole looks much better when you have people from very different roles who all can talk to each other and there is no underlying, under the surface tension over what am I really working on and why doesn’t that person agree with me on this thing that I think is important. When that under the surface tension falls away, people bond a lot better and those bonds become the foundation for that next level for a team.

Latif: What I’m hearing that’s really interesting is, when I think of product management as a job function, it’s a very malleable function. It’s supposed to go fill in the gaps but a lot of the stuff you’re talking about is reflective of a job of actually a CEO in some sense. Team building, communication, leadership, alignment.

Is that something you had expected to do when you thought you were coming in? Or did you just realize this was the most immediate problem you need to solve and now that you’ve made those changes that you’re moving back into “traditional product management?” Or do you feel like this is going to be a big part of your job going forward?

Gustavo: I feel that it was definitely just the most pressing problem that we needed to address, that I saw as soon as I came in. I don’t know that I was expecting to be leading the charge on that at all, but I have also been through enough different types of companies and working with different types of founders and different types of managers to understand that every environment you go into is a different beast. So, I stopped having that expectation of, what is my day-to-day really going to look like as a PM on the new team. I came in with an open mind and I saw this as the one thing that if we didn’t fix, there was no path forward. It didn’t matter how ambitious our strategic roles and the strategy overall was. I ended up spending a lot of my time doing that.

One of the great things that I love about Amazon in my time there so far is that it is a very fast-paced and dynamic environment and one of the consequences of that is that my work in pushing forward the strategy piece couldn’t slow down at all. I have to figure out how to work smarter or work more hours but make sure that we’re pushing all of that forward.

I am lucky in the regard that I have had enough experience in different types of companies to understand what working smarter means, so that it doesn’t overwhelm me. I figure out how to push both of those arms of the initiative forward.

As a result of doing that, I’ve actually been able to switch my focus a little bit more towards working on delivery of more complex projects that touch other parts of the organization, and where I act as more of a liaison between our overall team and other businesses within Amazon—as well as the stuff that you mentioned. Just getting more into the strategy of where we are trying to go as a business.

Latif: What are you thinking in terms of how you plan to maintain this? Are there certain tactical things that you’ve got in your back pocket or tools that you’re using to make sure that this moves forward in the right direction?

Gustavo: To maintain something like that and how you keep it moving forward is the way that you solidify the relationships that you are building. One of the things on the engineering side, the manager does a fantastic job of keeping the engineering team working well together. They have monthly team outings and things of that nature. One of the things that I noticed as I came in and I saw her building that piece, is how do we make that a little bit more inclusive so it’s not just all the engineering team together, going out as a team for lunch or dinner. I inserted myself in there and I said, “I want to be part of that. I’m not the guy on the other side of the fence that you only talk to when you need a requirement and so forth. We’re part of the same team.”

Something that diverges a little bit is this idea that there is tech and then there is business. I reject that violently. There is just one team trying to get something done and two different skillsets to do it. Because of that, I don’t like the idea of having the cultures be built up so separately from one another. One of the things that I did was insert myself a little bit more into team outings, making sure that we’re bringing in other people from other areas of the team and that the invite is always out there.

Beyond that, the one-on-one relationships are super important as well. One thing that has worked really well, that I have noticed, is when I have the chance to sit down with one of the engineers there isn’t a necessity from a requirements standpoint for us to have an in-depth chat. But instead just asking questions walking into the engineering team room, at the end of the day, as people are starting to wind down from their focused work and asking people informally, “How’s it going? How are we doing on this project? On that project?” Outside of that stand up that is in everybody’s calendar, outside of that sprint plan that they are used to doing, that informality adds a ton of value because people are giving you a different perspective on what they’re doing.

When you put all of that together, that then allows you to successfully rotate people when you have people who leave the team. You don’t necessarily lose all of the momentum that you’ve built as a result and as you bring in new people, they incorporate into what’s existing.

Latif: Absolutely. I really love the point that you violently reject that the non-technical and technical teams should be working in silos and that they are one team trying to accomplish a singular goal. I think that is a really strong message to end off with. Is there anything else you would like to add?

Gustavo: Part of getting the right results is very much about getting the right people in the door. If you’re at that point where your challenge is really, who can I relate with, who can I build a bridge with. If the answer is nobody, then either you need someone else on your end—and it can’t be you building that bridge—or you need to bring in someone new on the other end to help. You need to find people on all different sides of the organization that have that compatibility; that are able to build that relationship.

Latif: Where can people find you online?

Gustavo: They can find me online @gusmelo on Twitter, and you can always find me on LinkedIn.

Latif: Thank you so much, Gus, for being on the podcast.

Gustavo: Thanks for having me, Latif.

Subscribe to Product to Product on iTunes (here) and Google Play (here), or get the latest episodes delivered to your inbox by subscribing here.