It’s the second last episode of Product to Product’s second season!
Listen to the episode below:
As we reach our final stretch of exploring the human side of product, we’re joined by Ben Mills, Head of Product at Venmo, this episode.
Overseeing a team of 11 product managers, Ben is a step removed from managing the actual product at Venmo. Instead, he’s managing the PMs responsible for different slivers of their product. The thing is, managing other PMs can get messy since PMs will undoubtedly have their own opinions on how the product should work.
Our CEO Latif Nanji sits down with Ben to discuss how he navigates the messiness of managing all these PMs. How does he provide guidance versus micromanaging? How does he balance being process-oriented and progress-oriented? And how does a product team lead handle hard decisions? It’s a conversation that’s beneficial not only to product team leads, but also any PMs looking to understand their leads more.
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: Ben, welcome to the podcast.
Ben: Thanks for having me.
Latif: Can you tell our audience a little about your background, and what you do at a Venmo?
Ben: I am Head of Product at Venmo, which means a lot of different things. But before that I worked at a company called Braintree, which does credit card processing online. And I joined very early on. I think I was the seventh or eighth developer that joined Braintree, and did a bunch of different things from purely technical roles, to product roles, to hybrid roles.
What I do now at Venmo is I manage the product management team. I report to the GM, or the CEO of Venmo, and I’m really responsible for the roadmap, and strategy, and what we’re doing next.
Latif: As Head of Product, can you tell us a little bit about your team? How many product managers do you have, and what does the structure of the team look like?
Ben: Yeah. We have about 11 product managers. And the way the team structure works is we try as hard as we can to focus the organization around product development, product engineering and design. Our organizations have the same structure. We organize these cross-functional teams of PMs, designers and engineers together. My team is organized in roughly three groups.
One that’s around our internal tools for our customer support team. One that’s focused on our app experience, like using the Venmo app, signing up, managing your funding sources. And one that’s focused on where we’re going next, which we call commerce. But it’s using Venmo to pay for things in-store and online. Each one of those teams has a lead that manages around one to two PMs.`
Latif: I noticed that you had primarily a development background before coming into this role. Is that true? And how has that influenced your role as Head of Product?
Ben: Yeah, I definitely had mostly a development background, but how I got into development at all was an interesting windy road. I went to pretty much art school, and mostly wanted to build things. At that time, the wave of UX and information architecture and user-centric design was getting really popular, and I was very into that. And I just kept getting frustrated that I couldn’t build things, and make them happen. So, I got more and more into engineering. I saw my job at Braintree as me learning the craft, so, that I could understand it more, so then I could go on to actually figure out what to build.
And one of the cool things that happened at Braintree. So, Braintree, the real product is in API. A lot of what I focused on for the majority of my time there was what we called the developer experience team. While I was technical, I was doing a lot of what I now consider product work today. Understanding our users, who these developers are, what they might need, and how we can build products to best serve their needs. I cut my teeth on a very, very technical product.
And now, moving into Venmo, I think for PMs, it’s always good to have a depth somewhere. Whether it’s you have more of a business mind and have an MBA, or really understand stats. Or maybe you have more of someone like me, who has more of a developer mind, and can understand how things might be built. Or maybe more of a design mind and understand how the interfaces might work, and how users would interact with it. I think it’s useful for you to have depth in one of those areas, but interest in all three.
I think my depth in engineering is certainly a strength in some areas. Weakness in others. But it’s served me well, especially with Venmo, considering payments is still a very technical problem.
Latif: Definitely agree about having one area of depth: design, technical, or business. I wanted to switch gears and talk about the messiness of managing product managers. How have you managed a top-down product strategy versus a bottoms up? And what that looks like for you and your team?
Ben: Whatever company you’re in, you’re going to have a mix of things that are fully bottoms-up, where you let a team go off, identify a problem, research a solution and then execute that solution. But there’s also a lot of places where you’ll have something, maybe a compliance risk, or a, “Hey, we need to hit these numbers for us to make the quarter, or to get that next round of funding.” Those things just happen, and that’s life. And I think the difference between a good PM and a great PM is someone who can then figure out how to take that, and look at it as constraints. And constraints inspire creativity.
What I see my role as is how do I help these PMs best approach it that way. Where it’s like, we have this compliance project that’s coming down the pipe that we just have to make happen in this timeframe because of regulatory pressure. Managing this PM who’s ultimately responsible for hitting these dates and dealing with this compliance issue, I ask how do we look at this? What is the user problem we’re solving here? Or what is the thing we’re going to do, and how are we going to take this as an opportunity to make things a lot better?
Let’s take an example at Braintree. The credit card industry as a whole changed some rules, which would have made it much more difficult for businesses that use Braintree to comply to those rules, without significant amount of work. That was a big constraint we had coming down the pipe. And the team that I was managing at the time actually found this amazing creative solution to it that not only satisfied that constraint, but it just made adding Braintree to businesses way, way, way easier. And that was a perfect example of what I’m trying to explain here, which is they took this annoying constraint, and turned it into this huge value for the user. That allowed a lot more businesses to, one, be more secure, and also just add Braintree faster, which is always better.
It’s all about guiding those PMs into finding what are we really going to do here? It’s not just about checking the box of this top-down priority. It’s about understanding the whole problem.
Latif: Very cool. You mentioned something in there that caught my attention, which was that constraints create creativity. Can you talk about an example of where you’ve created constraints that produced a greater result to the end user?
Ben: An easy answer that comes to mind is organizational structure. Separating responsibilities of teams is by definition creating artificial constraints. Where we’re saying, like, “Hey, I need you to just focus and become an expert of this area.” That idea of trying to find the right seams to split up your organization. Take Venmo for instance, understanding the application experience and using the app. We think that constraint will allow you to just go very deep in that, and find really interesting stalls for our users. Whereas, just letting things happen more project-based, then we would never sit down and have someone deeply understand how you manage funding sources, credit cards and banks in your Venmo account. That deep understanding will help us identify much more interesting problems that we can solve for our users.
Latif: Have you used time as a constraint before?
Ben: I view deadlines often much more as a tool that the team can use themselves. I usually encourage teams to set deadlines for themselves—I think that’s really useful. It’s a great way to keep them accountable, but I always find that it’s best to let them do that, not me. I mean, of course there are situations that happen where there is an external deadline. When that happens I think it’s best to all accept that, “Hey, regulatory set this deadline. A client set this deadline. We have to hit it.”
I generally found that if I artificially set deadlines, that skews too much into micromanagement. Then you have the reverse problem of creating an artificial constraint, and it actually reduces creativity because the teams feel less autonomous, and less engaged.
Latif: I think that makes sense to let the teams set their own deadlines. One of the exercises sometimes I like to push forward is, especially on the design teams, is let’s come up with a list of things that we could do that we would be able implement in the next two week cycle in development. Or something that fosters the idea of Pareto’s law of 80/20, that doesn’t necessarily come up with the full solution, but at least takes a bite out of the apple.
Ben: I firmly believe the goal we all have is to create super engaged creative teams. And I think the biggest ingredient you need to do that is autonomy. You can just go run. Solve this really interesting problem however you want to, but there is that balance of how do you make sure they’re being pragmatic, and not overly perfectionist about it. Yeah, I think stuff like that I would generally describe it as time boxing. To say, “We can’t spend forever ideating on what we want to do here. Let’s pick the best thing we can do, and move forward.”
Latif: And have you found that’s been an issue with respect to managing your strategy? Saying this is the problem we need to solve, here’s the time box. Have you seen teams maybe take longer or go off the rails in other directions you weren’t expecting?
Ben: Definitely. Generally though when I reflect on those situations, there are a lot of things that I realize I should have done differently. That’s where I think a huge part of my job is setting expectations. Saying, “Here’s the problem you want to solve. Here are the guardrails.” If I set a really generic problem of we want to make money at Venmo, people can take that in any direction. So, I think it’s more we want to focus on specific aspects and here are further guardrails to help you focus. Setting that upfront is absolutely key, and also setting the level of urgency of we want to come up with a good solution, but we’re looking to see an impact in the next couple quarters versus the next couple years, versus the next couple weeks. All are very different things, and the more you just talk about that up front, I think everything goes much more smoothly.
Latif: What other guard rails besides time do you use? Are there other qualitative or quantitative factors that help the cadence and structure? What do those guardrails look like to you as a product leader?
Ben: I think scope might be the other big one. For instance, we needed to make some changes. We had a top-down thing come down where we need to make some changes in the way we add bank accounts to Venmo. There were a lot of questions of could we rethink the way payment methods work overall at Venmo? Can we make it more dynamic? There’s all these things we can do that would impact the full experience. And I thought it’s awesome that you’re thinking about that, but we need to put some scope here.
Saying some of this is out of scope and finding that balance. I don’t ever want to just say, do this and check this box and move on. There always needs to be room for that creativity. But asking how do we improve the overall experience of adding the bank account makes perfect sense. Maybe you expand that out to how you would also add a credit card too, or a debit card. Like those are all very related things. Let’s focus there, but going all the way out to how payment methods work throughout the whole Venmo experience, feels too big. Let’s keep it a little more contained.
That’s probably another place where there’s negotiation. Usually what I like to do is let the PM go off and just think creatively about this, no restrictions. And then let’s sit down and talk about it and agree upon those guardrails. And then we’ll move forward. That always usually goes well. People respond poorly when you enforce constraints right away. I think everyone appreciates when we’re given time to think about it, we had a discussion, we agreed upon a compromise and we moved forward. That always feels really good and collaborative.
Latif: And there’s also this concept where you might end up providing guidance versus maybe getting a little bit to close to the situation and micromanaging. How have you managed that balance and trade-off ? How have you incorporated that into your own management style?
Ben: Some of this is less about managing PMs specifically and just being a good manager. Where it’s understanding what I need. Being very clear with each person I manage of here’s what I need. This is what I need to make sure I’m doing my job well.
But then also letting them say, “This is what I need from you to do my job well.” Certain PMs want to talk every day, orwant to talk constantly and make sure that we’re all in sync. Where other PMs might be like, “I got this, let’s just agree to check in at key points, and we’ll move forward.”
So understanding what people want is a key step and setting those expectations early I think helps a lot. I try as hard as I can not to solve problems. Instead, I try to help people identify problems. Whenever you get into solving problems, that’s where you get dangerously close to micromanaging. And of course, I’ve crossed that line probably more times than I would have liked, but I generally have a principle of asking how can I make sure that I’m just helping them identify the right problems and we have the same context. Those have always served me well.
And then when I inevitably cross that line and go to deep into solutions, trying to just step back and admit that I made that mistake and try to move forward.
Latif: Yeah, that’s a really interesting one. It seems counterintuitive to say that solving problems with your team members is micromanaging and product management. Because in another department, whether it’s marketing or even a design lead coming in and solving a difficult design problem, we wouldn’t consider that micromanaging.
Do you find that there are a lot more individual contributors in your product organization? How much autonomy do you give to one PM versus another? I just ask this question simply because of the fact that I’ve always been of the opinion, I want a PM to run horizontal across the whole company.
Ben: I think you and I are very aligned on that. I generally think of it as a good thing to let the PMs run and take ownership. I mean, we would sometimes internally say it’s like the mini CEO of that area. Marty Kagan said something like, “Product is a huge feeder into CEO-type roles.” Seeing what I’m now dealing with every day for the last the couple of years of just managing PMs, it’s a very CEO-type role, where you want to encourage your team to do more and want to be the coach.
If you step in and do too much, you don’t get the talent, creativity and power you need.
Latif: Absolutely, I think that’s the transition in my career going from product to CEO. I pick and choose one battle a quarter I think for about a day and get in the weeds with product, so I make sure that I’m still close to some of the stuff that they’re working on.
How have you managed to delegate, but keep yourself informed and stay accountable to the people that you report to?
Ben: I think this is where I actually spend a lot of my time thinking about process. Which is weird for me because I’m someone who maybes hates process. I generally think I want to get back to that mode where you’re just a really small group of people in a garage doing great work. And it always feels like process is a little bit like red tape.
Process is the glue that allows me to empower autonomy, but still make sure I’m doing my job well and that Venmo is moving in the right direction. When I say process, first of all, I don’t mean Jira or stuff like that. Those things are important, but I mean more about how do you communicate? When do you talk? And what do you talk about?
So I spend a lot of time thinking about how do we have just enough and just the right amount of meetings to make sure that we’re in sync and talking regularly. But not enough where it feels like everyday the PMs are constantly giving status updates and meetings. Of course, I don’t want to do that. So what I’ve found is, and you just said this about how you try to once a quarter dig in with the teams. Every week, I try to sit down with the engineering lead, product lead, design lead, for each area and get them to walk me through everything that’s going on. Just to make sure that I have in my mind what’s happening.
We also try to do regular reviews, where at any key point, any PM can say, “Hey, I want to get in front of the leadership team to say here’s where we are on this project. Here’s what we’re thinking about. Here are the problems we have.” And I think that cadence allows us to get in front of a lot of things and allows myself, and like you said before, all the other stakeholders feel comfortable with what’s going on.
So I think regular communication is key. I think it’s easy to say it’s regular communication. Why I say process, not just communication, is it’s actually agreed upon to have some actual cadence of communication.
Latif: What would be the last process you saw in Venmo’s product team that just absolutely fall flat on its face and what did you do to solve it?
Ben: One of the things we’ve been trying to do is get more disciplined about having artifacts of where we’re at. Maybe like showing our roadmap, which is kind of ironic considering who I’m talking to right now. We used probably what you all probably know a lot about which is the simple way to do it, just a spreadsheet that we kept updated. That crashed and burned pretty hard because I think we got into this world where I was asking these PMs to update this spreadsheet every week and it wasn’t clear why they were doing it and what value we got out of it. Because looking at just the status updates wasn’t very useful. Really it was about having that discussion.
I think it was doing that and then almost watching that go for a few weeks and realizing this isn’t really adding value. The PMs just see it as busy work, the leadership team really doesn’t care about looking at every single project every week, they just care about hot topics. I almost thought of it like the process itself was a product that I was managing where the iteration was how do we solve both “users problems.” Leadership is one user, the PM team is another, and the thing that they both actually wanted to do is talk about hot topics. So we have this leadership review where every week we have this standing hour which is a time slot where all the leadership teams are in one spot and any PM can come in and share whether it’s, “Hey, we’re about to launch a project. Here’s all the information about it.” Or maybe, “Hey, we just did a bunch of research and we’re about to start implementing. Here’s all that research. Let’s talk about any feedback you have.” That has become way more valuable for the leadership team and the PM team than just updating a spreadsheet.
Latif: I love that idea. I think that is an incredible way to get great conversation. I like the framing of hot topics. How often do you have it? Are there 15 minute time slots? How many people are traditionally in the room? Give us some color and flavor as to how this all came to be and what things are working well and what things probably you’d like to see improved.
Ben: I think the one thing that has really organically come into focus from that meeting is it’s all about what are the hardest and messiest and scariest problems of any project. There are the things that you’re most worried about with any given project and this meeting has turned into a forum where we almost always lead with that. We’re about to launch this big new feature. What’s the one thing that keeps you up at night about it, and what are you doing about it, and what can we all do about it? I think that framing has created so much clarity so quickly about what’s going on. It might be, “Yeah, there’s this big problem. I’m really worried about it, but I think we got it. We’re okay right now.” And even then, it’s so valuable for myself and the rest of the leadership team because then we know what to watch out for. If we see any updates that are about this thing, we know to really dig in and understand what’s going on versus something else that might not be as important.
I think that’s a guiding principle that has helped us a lot. The attendance of the meeting is something I think we’re going to iterate a lot on. Right now, my goal is to keep it as small as possible because it’s all about how do you have those discussions and really dig in and talk and collaborate. Sometimes with these type of meetings, they go into a phase where there’s just so many people there that it’s almost more of a presentation and that’s not really the point of that meeting. The point is to really dig in and talk.
So right now, it’s just the leadership team. What that means is the PM, the designer, the tech lead. But really all the engineers could come. That usually doesn’t happen just because they’re too focused on other things. But the goal is the team that’s working on something and the leadership team, discussing in-depth.
Latif: With respect to balancing process and progress, have you noticed which processes may have impacted progress?
Ben: I think the one other area—this is really the nitty gritty—that I think we’ve struggled with trying to find the right balance of is how do you just do the normal ceremonies of agile development? So, stand ups, no problem, but where I think sprint planning and backlog grooming has actually been something that we’ve struggled with a lot. Because one of the things that Venmo has is a pretty big team, but we’re ultimately all delivering just this app—which is a very small footprint. That means that we have the iOS app and the Android app and web app. So how do we make sure that for any given change, we’re coordinating changes across all of those platforms?
Whenever we have one of these teams, it’s like we have these little sub-teams. We have an Android team, we have an iOS team, we have a web team. So what we’ve been trying to figure out is how do you do the right level of backlog grooming and sprint planning? Do you get all the engineers? I think the traditional way to do this is to just get the whole team. All the engineers, the designers, the PM, all together, look at the backlog, and decide what you’re going to do and move forward. But that’s been hard because you have iOS engineers and Android engineers who really just have no context of what’s happening in the back end or vice versa.
So, I think we’ve inhibited and isolated between these two extremes of having everyone on the delivery team really have simple sets of meetings, versus having maybe two to three different backlog grooming sessions where the PM has to go to all of them just to make sure that all the teams are in sync. I don’t know if we know what the right answer is there yet, but that’s certainly been another place where we’ve iterated a lot of our process.
Latif: Can you talk about your product management meetings, just with your product managers? Do you have those types of meetings and what do they look like? Where do you find the most value in them, and what have you learned?
Ben: So I think the one meeting that we’ve iterated on a few times and it’s now starting to feel very good is something we call the product leads meeting. At the beginning, I outlined the organizational structure for the product team at Venmo, but really there are three people that are the leaders in each of these areas and they all report to me. The four of us meet weekly, and that meeting I view as we’re the product team of Venmo. We’re tasked with making sure we’re investing our most valuable resource correctly, which is our engineering and design teams’ time. Are we happy with that? The way we answer that is quickly going over here are all the things we have in flight, how much time and effort we’re investing in those, and here’s what’s going on in the market. Here’s key data that we’re looking at.Here are our key OKRs for the overall business, and are we tracking well against them?
One of the problems I’ve always seen organizations struggle with is they start to transition from a really small startup team into a bigger organization—which is definitely happening at Venmo right now—is you get too much siloing. You’ll have one team that’s doing great but they don’t really know what’s happening around them. So this meeting with these leads allows the app experience lead to say, “Oh, wow. I hadn’t been thinking about how our business involvement is changing.” Sharing that context through data and actual key results we’re looking at has been incredibly valuable for the product leaders across Venmo.
For the product team itself, we’re still iterating a lot. Right now, we’re trying something out that we’re calling the product critique meeting. It’s another meeting where it’s the whole product team and a PM will present and go through a narrative they wrote, or they’ll go through a design sprint they led, or go through a research plan they’re about to take off. The goal of it is 1) to still share context and let any PM across the company know that this being worked on and 2) it’s a place for us to critique each other and push each other and find ways to improve as a product team overall.
That’s been really interesting. We just started that, so we’ll see if that lasts or crashes and burns. I think I’m very excited about that because it’s a great way for us to grow as a product team.
Latif: What would you say is the number one thing heads of products should do to contain the messiness of managing other PMs?
Ben: I think the biggest thing that they should do is over-communicate at the start. Talk more at the start. It feels counterintuitive because I think it’s that whole micromanaging thing again. I don’t want to try to talk about; I want to just trust people are smart and are going to do the right thing. But I’ve always found being way more up front about expectations and saying, “Here’s the scope of this project,” or, “Here’s the way I need you to give me updates on status,” or, “Here’s what I want to dig in with you”. Doing that up front just smooths everything over. And then, most importantly, having that actually be a conversation two-ways where it’s, “Here’s what I want” and listening to what they want, makes everything go much smoother.
Latif: Very cool. The last question, and this one’s much more important, is, when is Venmo being introduced into Canada?
Ben: I can’t speak to any future product plans right now!
Latif: Whenever you’re planning on coming to Canada and introducing your products here, we welcome you guys with open arms.
Latif: Ben, where can our audience find you online?
Ben: You can find me on twitter at @benemills.
Latif: Thank you so much Benjamin for being on the podcast.
Ben: Thank you very much.