Episode Thumbnail
Episode 73  |  18:21 min

Back to Basics: Ravneet Uberoi on How to Work with Engineering

Episode 73  |  18:21 min  |  03.12.2021

Back to Basics: Ravneet Uberoi on How to Work with Engineering

00:00
00:00
This is a podcast episode titled, Back to Basics: Ravneet Uberoi on How to Work with Engineering. The summary for this episode is: <p>It's easy to forget that building really great products is a team sport: the best product managers know how to work with their engineering and design counterparts to move their businesses forward. In this episode, Ravneet Uberoi, a Group PM at Box, joins Maggie to share her advice on how to build strong relationships with engineering plus the best career advice she's ever heard.</p><p><br></p><p>Like this episode? Leave a ⭐️⭐️⭐️⭐️⭐️⭐️ review, hit the subscribe button, and share the pod with your friends. You can also connect with Maggie on Twitter @maggiecrowley</p>

It's easy to forget that building really great products is a team sport: the best product managers know how to work with their engineering and design counterparts to move their businesses forward. In this episode, Ravneet Uberoi, a Group PM at Box, joins Maggie to share her advice on how to build strong relationships with engineering plus the best career advice she's ever heard.


Like this episode? Leave a ⭐️⭐️⭐️⭐️⭐️⭐️ review, hit the subscribe button, and share the pod with your friends. You can also connect with Maggie on Twitter @maggiecrowley

Maggie: Welcome to Build, this is Maggie. Today I have Ravneet Uberoi, a Group PM from Box on the show. I've been thinking a lot about making sure that I'm nailing the basics and sweating the details this year. So in this episode, Ravneet gives her take on one of the most important things for product managers to get right, and that's how to build strong relationships with your engineering teams. I hope you enjoy it. Ravneet, welcome to the show.

Ravneet Uberoi: Thank you. Thanks for having me.

Maggie: Yes. I'm excited because today we're going to talk about a topic that I think comes up over and over again, and that's how to work effectively with an engineering team. There are so many stereotypes about product managers and engineers out there. So I'm excited to get into some specifics. But first, where I want to start is with the experience that all product managers have when they're new, and that's having to convince your first team of engineers to actually build something. So, Ravneet, when we talked before, you had a great story about this. What was your first experience like and how was that different from what you expected?

Ravneet Uberoi: Yes. Oh my gosh. I couldn't agree more that that's sort of... I think getting that relationship with engineering right can be some of the most daunting moments for a new PM. I know that when I first started out as a product manager, I was expecting the stereotype of a group of somewhat cynical engineers. But I think I didn't quite realize how alone I'd feel in that first moment where you're standing in front of a group of five, six engineers and trying to pitch an idea to them and get them excited, and what you get back is just blank stares. And I don't think I realized just how lonely that one versus many dynamic could feel, of one PM and many engineers. And I think that's when I realized that this was something I would really, really need to work on to get rid of that dynamic and really work as a team together.

Maggie: Yeah, I agree. And I think there's so much built up around," Okay, I want to get this right, and I don't want to mess this up, and this is my moment." And then you get that room of people just looking at you like" Is that it?" And then it's sort of like," Okay, where do we go from here?" How did you approach that, and what was your strategy for how you solve for that problem?

Ravneet Uberoi: So I think in the beginning, I realized that I just needed to fully immerse myself with my scrum team. I had to spend the majority of my time with the engineering team, really getting to know them individually and as a team. Understanding their day- to- day, understanding what frustrated them and what excited them, and why they were in this role to begin with. Understanding what kind of languages they like to code in. Really deeply understanding them as individuals and as a team, before I could take a step back and go back to vision and strategy and so forth. So I took a very personalized approach to building individual relationships.

Maggie: Where there any specific rituals or practices that you think helped you make sure you were doing that work?

Ravneet Uberoi: Oh yeah. I think first off, I set up one- on- ones with every engineer on the team, and had a regular cadence going around that so that I could build those individual relationships. Because I realized that, I think sometimes we think of the engineering team is this one unit, but really it's a group of people with different interests, different motivations and reasons why they're there, different things that they want to learn more about. So I took the time to get to know each person on the team through one- on- ones. I tried other rituals like setting up weekly lunches for the whole team to bond. I made sure that we spend enough time just in the area where the engineering team was. Obviously, I was seated right next to them, which also helped, because I very much thought of the scrum team as my core team. But made sure that I spend enough time physically there in a given day that I wasn't just always running around in meetings. So I think just that presence was a big part of it.

Maggie: I'm curious what other tactics you tried to help working with this. Because I think I've definitely done the have one- on- ones with everybody, but I even think that sometimes those are awkward, and it's hard to figure out what the right approach is and why you're doing it. So I'm curious. What were the other sort of things that you tried that you found worked for you?

Ravneet Uberoi: Well, I think one of the things I thought a lot about was, how do I break this idea that I am in product in a different function and they are an engineering in a different function? I didn't want us to think of ourselves as coming from two different departments or functions and having to work together. I very much wanted it to be like, we are one team of six people that have a mission that we're on. And so I never wanted to be in a meeting where it was them presenting to me or me presenting to them. I wanted it to be a conversation. Things like weekly demos, where when engineering presents their work on a weekly basis, I made sure that I had a demo to bring to the table as well. And my demo would be a customer story of the week. Like here's an interesting conversation I had with the customer, here's a use case, here's my analysis I did on the data on what I'm seeing. But I made sure that I had a demo to bring to the table as well, so that it was never a unilateral sort of communication. And so I think that really helped. Similarly, I think posting customer stories on Slack. As soon as I had a customer conversation, I would post a use case alert in our team's Slack channel, just so that the team felt like I was also contributing context and information, and I had something to show for the work I was doing. And that helped, I think, bridge some of the awkwardness in the conversation.

Maggie: Yeah, I love that idea about, or the point about how it's not your function product versus engineering, it's one team and trying to achieve an outcome. And I definitely think that the point you made is really important about how you have to bring something to the team, too. It's not just, how do I convince logic the engineering team into doing what I want them to do? It's about, they have expectations that we have to bring the right data to prove that the stuff is that we want to do is right. And how do you build up trust so that you guys can work together and actually have a good working relationship? I think is super important.

Ravneet Uberoi: Yeah, absolutely. And I think as part of building that trust, I realized that if this was going to be a two- way conversation, then I really had to ask them for their input. And so that meant not just coming in with," Here are the requirements, here's what I've seen, et cetera," but saying," Here's what I think we should do based on what we're seeing, based on these various customer examples I've been bringing in over the weeks, based on what we've seen in the data, but what do you guys think?" And I think just always taking that extra second to ask," What does the team think?" And then waiting for a response and not moving forward without getting meaningful input from your engineering team, can go a really long way in starting to make this a two- way conversation.

Maggie: One of the things I've tried to do is always make my first port of call when I have an idea, is my engineering director and my design director. So the second I have an idea, they're the first people I go to to say," Okay, what's your first reaction to this, right track, wrong track? What information would make this argument more persuasive?" And that's a question I've used a lot. Which is, you have an idea, you're going to an engineering team, and then you can say," Okay, it feels like this idea is not working." What information could I bring that would get you excited or make you believe that this is the right thing to do?

Ravneet Uberoi: Yeah, I really like that. I totally agree. I think seeding that idea early and often with your engineering team as compared to waiting for it to be fully baked, can also go a really long way. I used to think that I had to have it all buttoned up. I have to have all the data, all the research, just go in and convince. But instead, I started to see it as, this is iterative with my engineering team as well. Where I come in with a 30, 000 foot level view of this is what I'm thinking directionally, it seems like the company's heading this way and here's some things we might want to think about. So start percolating those ideas early and then get the team's feedback and iterate on it together until when you get to the final result, everyone is actually bought in, because they've all been invested in it from an earlier point in time.

Maggie: Right. There's a myth that the idea of what we are working on has to come from the product manager. Or I'll think a lot of people get into product management thinking," Oh, I'm going to be the one who decides what we get to do and what we're going to build." And I think that's such a bad feeling to have, because it doesn't really matter. We don't get any points, I guess, for having the right idea, we get points for creating customer outcomes. And so I often think that the best ideas I've worked on have come from engineering in the first place.

Ravneet Uberoi: Oh yeah, 100%. I agree with you. I've definitely seen that. To me, the best ideas just they come from the team that's entrenched in the problem and wants to work on solving that problem. And at the end of the day, you shouldn't even be able to tell where the idea came from, because it was this group effort.

Maggie: Yeah, I totally agree. So what are some examples? I think a lot of PMs might be listening to this and saying," Yeah, yeah, I have a great working relationship with my engineering team." What are some things to look out for that actually mean that there might be more work they can do to have a better relationship?

Ravneet Uberoi: Going back to that initial example of pitching an idea to your engineering team and getting blank stares in return, I think that's that first indicator, right? Is like when you're getting blank stares, when there are no followup questions, when the PM is doing all the talking and there isn't a conversation, I think that's an early indicator that the team is embodied that you definitely need to be sort of more aligned. I think the other thing that I noticed is for me, once you have an idea and you're talking about it and so on, one of the things I look for is, is there a debate among the engineers on how to solve this problem? Because engineers love a good debate. And I think it's a really healthy sign if they're energized about the problem that they'll be vigorously debating the issue. If there isn't debate, then I think that means that there's lack of energy or intellectual... Certainly, there's lack of intellectual rigor going into this. And so that means that something might be off.

Maggie: Right. If it's just like," Oh, this PM said we had to do this thing, so we're going to do it, and we're not going to think beyond just doing exactly what was written in some tickets somewhere."

Ravneet Uberoi: Exactly. Right? If it's just like," Okay, yeah, we can go do that." And everyone's like," Yeah, okay." Something's wrong.

Maggie: Yeah. We're working on a project right now and one of the sort of a bigger cross, it involves a handful of individual product teams. And I think that was the moment that I was waiting for, was when we went from," Okay, this is the thing we're going to work on." And then there was that quiet period, and I'm sitting there stressing out thinking," Uh- oh, do they hate me? Do they like it? How they feel?" And then seeing a Slack channel start to light up with questions and examples and debate. And that's when I knew," Okay, we're good. We got over that first hump because they're engaging in the problem."

Ravneet Uberoi: Yeah, exactly. And then I think the second big win for me tends to be when you're at a point where you need to explain the problem to another team, right? Whether it's a cross- functional effort, you have a dependency on another engineering team and you go into that meeting. When an engineer on the team is able to take the lead in explaining the customer problem, the business context, the use case, that's when I'm just like," Hallelujah." Because then you know that that handoff went smoothly. That engineering gets the why, and then they can go and lead the what, and you are just there to facilitate. But you don't always have to be the one who has to explain the use case of the business context. And so that's really big is when they can translate that themselves.

Maggie: Yeah, I agree. I think that's definitely a pitfall that product managers can fall into when they think that it has to be them or that if it's not them always leading that discussion, that they're not doing their job or that they think that that's the only way that they can show they're doing their job. And I agree. I think it's much more powerful when the PM steps back and allows the team to present. Because that means that they've done their job so well that they don't always have to be the voice.

Ravneet Uberoi: Yeah, exactly. Exactly. And then you actually now have more voices that can carry this forward, that can evangelize this idea, that can present and demo this idea. One of the things that I love to do is ask the engineering team to show off the work when we're at an all- hands or any space which involves sort of demoing our work. I would love if our engineering team was doing the demoing. Because it not only creates a platform for them to truly shine, but again, it makes it a collaborative effort where it isn't just always product that has to carry that forward.

Maggie: Right. This is definitely leading question, but I'm curious how you think about the impact that building these relationships has on your career more broadly.

Ravneet Uberoi: Well, I think, first off to be an effective PM, you need to work in a kind of airtight way with your engineering and design counterparts, right? It's just truly like three... You've heard, there's so many different analogies for this. There's the idea that three legs of a stool product engineering and design. But really, I think a PM cannot be effective without their engineering and design counterparts. So truly just, I think not as confident. So there's that. For me personally, I've just learned so much from working closely with my engineering team. I've learned so much about persuasion and influence and things like that, that we've been talking about, but also I've grown as a person through those relationships. And I think some of my closest professional relationships now are with some of the engineers on my team, and that's been really fruitful for me.

Maggie: Yeah, I agree. I think I would echo that in my own career. And I do think that at some point it's going to be really hard to progress if you don't have those relationships, because you're right. It's really hard to build something well, if the team isn't working well together while they're doing it.

Ravneet Uberoi: Right. Because I think at the end of the day, a product manager's core aspect of your job description is alignment. Right? And fundamentally what you're doing is you're handing off... There's all these handoff points. There's handoff points with engineering and design, with product marketing, with sales, with customer success. So you need to make sure that all of those handoff points are as smooth as possible, because if things are falling through the cracks, then you're just not going to get the kind of outcomes that you need as a team. So I think across the board, making those handoffs as seamless as you can should always be the core focus.

Maggie: Yeah, agree. All right. So while we're on the topic of product and what makes us successful, I'm curious. What are the best pieces of advice, career advice, that you've received?

Ravneet Uberoi: Oh, I like that. So actually, some of the best career advice... Can I give you a couple? You said pieces.

Maggie: Yeah crosstalk.

Ravneet Uberoi: It's not my advice. It's some stuff that I've heard from one of my favorite professors in grad school, actually. Something she said that I've recently taken to heart is this idea that a good career story always has these two ingredients, which is serendipity and audacity. The idea was that you need some element of serendipity, right? Sometimes you got to go with the flow, you need to just sort of let things play out and see where they take you, but you also need to be audacious and sometimes make tough decisions and be willing to turn that ship around. And so I've been thinking more deeply about that just as in terms of like when do you let life take you somewhere, versus when do you pump the brakes and turn that ship around using two analogies for cars and ships in one sentence?

Maggie: I love that though.

Ravneet Uberoi: Yeah, I think about that a lot. And I talk to a lot of friends about that, too. It's like now is the time to be audacious. The second one, also from the same professor, ties back to what we're talking about actually is this idea that you don't always have to dazzle people with how smart you are. You can also dazzle them by how kind or compassionate you are. You can also dazzle them with how funny you are, how thoughtful you are. And I think taking that back to working with engineering, as someone who deals with imposter syndrome, as someone who's not technical, when I started out in product, I was so worried of... I wanted to seem smart in front of the engineering team. I wanted them to think that I was really smart. And I realized that if I stopped focusing on that and instead I really just focus on how to be a really good working partner with this team, that the rest of the stuff just kind of falls into place. So I think when you take the focus away from trying to be the smartest person in the room to something else that you can bring to the table, it can really go a long way.

Maggie: Yeah, I totally agree. And I love those two pieces of advice. Who was the professor?

Ravneet Uberoi: Her name is Youngme Moon. She teaches brand strategy.

Maggie: Yes, I was curious. Disclaimer, we both went to the same grad school.

Ravneet Uberoi: And Youngme has a fantastic podcast as well. So I recommend everyone check that out.

Maggie: Perfect. Okay. Well, good segue. My last question for you is, what are you reading or recommending to people these days?

Ravneet Uberoi: I think just in this crazy world we live in, I consume a lot of short form content, just sort of bite- size pieces. And most recently I've been recommending James Clear's newsletter. So James Clear, I don't know if you're aware, he wrote this book Atomic Habits that is a bestseller around how to form long lasting healthy habits. I actually haven't read his book, but his newsletter is fantastic. It's a three to one newsletter. And what he presents to you every week is three ideas, two quotes, and one question. And it's a really, really quick and easy way to reflect on your own habits. And I think especially as the new year is kicking off, I found it to be really helpful for me to think about how I changed my own habits.

Maggie: Oh, I love that. That's awesome. I like that it sounds like that's short. I have several newsletters I subscribe to that are piling up in my inbox and will probably continue to pile up in my inbox for the rest of the year. So maybe that's one I could actually get through.

Ravneet Uberoi: Exactly. That's one that you can read it like five seconds and be like, inaudible.

Maggie: Awesome. Well Ravneet, thank you so much for coming on the show. I loved your examples and your advice. Appreciate it.

Ravneet Uberoi: Thanks so much, Maggie. Thanks for having me.

More Episodes

[Rebroadcast] Answering Your #1 Question: What's a One-Pager? (With Daphne Funston)

Giving Presentation Feedback as a Manager

How to Turn Advice into Action with Whoop's Ben Foster

Building Early Stage Products with Levels Co-Founder David Flinner

Prioritization with Productboard's Srinivas Krishnamurti

Product Manager vs. Chief of Staff with Drift's Terrance Rogers