We’re doing something a little different in this episode – we have a guest to help us see different disciplines’ perspectives on Product Management and healthy product teams.

Today we had the chance to sit down with one of our favorite Software Engineers, Aaron Roberts to talk through what makes a Good Product Manager from the point of view of Development. All of our hosts have had the opportunity to work with him previously, and it was a joy not only to get to chat with him again but also to dig into what he sees as both the good and the bad when it comes to product management when building products.

Product Outsiders – Ep 3

[00:00:00] Will Sansbury: Welcome to product outsiders, we’re not product managers. But we’re close.

In a world awash in MBAs and fancy suits. We’re the people standing on the outside, our sleeves rolled up, ready to get some stuff done. We might not be product managers and the way you think, but we’re undeniably passionate about solving problems for real people in ways to create real value. Whatever you call us, we’re dedicated to building great collaborative teams and making incredible products together.

Today’s episode is a somewhat touchy subject. We’re going to be looking at what it takes to make a great product manager, but we’re not going to look at it from our own perspective or from what we’ve seen in the past. We’ve actually got a guest in our hot seat today. Who’s going to speak to us from the perspective of a software engineer about what makes a great product manager, Aaron, welcome to product outsiders. We’re glad you could spend some time with us today.

[00:01:12] Aaron Roberts: Hey Will. Thanks. Happy to be here.

[00:01:14] Will Sansbury: Tell me a little bit about yourself, Aaron. How long have you been a software engineer?

[00:01:17] Aaron Roberts: I’ve been doing software engineering for about seven or eight years now.

[00:01:20] Will Sansbury: How’d you get into software engineering? What do you love about it?

[00:01:23] Aaron Roberts: I think I like the complexity of solving problems. I was big into math in high school and college and attended a summer program where I got my first hands-on keyboard experience doing some programming and really just kind of felt like it fit with all my other abilities. So.

[00:01:38] Will Sansbury: Awesome. So you’re the classic mathlete current software engineer.

[00:01:42] Aaron Roberts: If that’s the classic then? Yeah, I guess so.

[00:01:45] Will Sansbury: Well, we’re grateful for you to spend some time with us today. In just a moment we’ll get into our conversation about what it takes to make a great product manager. But first I want to introduce my co-hosts.

[00:01:55] Amber Hansford: Hey, I’m Amber Hansford, I’m currently a UX manager, former product manager and former front-end developer.

[00:02:02] Tammy Bulson: I am Tammy Bulson. I’m an agile coach by day writer by night, and I am interested in anything that has to do with people working together to build great products.

[00:02:15] Will Sansbury: Awesome. And I’m Will Sansbury. I am a tech writer, turned UX designer, turned product manager. So today on product outsiders, we’re talking about what it takes to make a great product manager. We’ve got Aaron with us here seven years in the software engineering game. All three of us have had the pleasure of working with Aaron and the previous job, and he’s one of the best out there, undeniably. So of course, when we started talking about getting perspectives from people outside of product management, about what they need and want from product, you were the first name that came up when we talked about software engineers, Aaron. That’s my first question for you. What do you look for in a good product manager, someone that you feel like you’ve got good partnership with.

[00:02:55] Aaron Roberts: You know, like you said earlier, it’s a touchy subject, but it’s also a good question. I think there’s a lot that people expect from product managers. And so it’s, it’s hard to nail it down to like, what is one thing that makes a good one, but the top point that came to mind when you first started talking about this subject was someone who knows what needs to be done and why it needs to be done. Not necessarily has any particular opinion on how or not necessarily opinion, but just doesn’t actually try to get into the weeds on how it needs to be done, because there’s just so many different ways that any particular problem can be solved, but really understanding what the business case is for a particular feature or solution or product set.

And then why, why we’re doing it. What’s the use case, not only the business value, but like, because our customers need it, because they did this because this study shows that because blah, blah, blah, blah, blah, blah, where it comes down to this is going to help the business thrive or help the product just, be better.

[00:03:51] Will Sansbury: I want to play devil’s advocate with you for a moment here. How does knowing why you’re building something help you be a better software engineer? Can you just pull the tickets out of JIRA and write the code and stick it into Git and along we go?

[00:04:04] Aaron Roberts: Yeah, but that doesn’t sound like fun. I mean, yeah, of course, any software engineer can do what’s assigned to them, right? Any high school student can do the homework assigned to them. But what teacher says, go do this homework without having any particular reason why. There’s usually some method to the madness and students need to know that just like software engineers need to know why they’re doing what they’re doing, what gets them out of bed in the morning to come to work is not taking the next task off the block and doing it. It’s having some momentum behind what they’re doing and some reason behind it at the end.

[00:04:35] Amber Hansford: So you’re saying that throwing requirements over the cube wall, isn’t like, fun?

[00:04:40] Aaron Roberts: Well, it may be fun, but at the end of the day, it’s not very satisfying.

[00:04:45] Will Sansbury: I think if you’ve got a lot of them and you print them out and put them in a three ring binder, you get a good satisfying thwack when you throw it over the wall.

[00:04:51] Aaron Roberts: True. True. That’s true. I didn’t think about it from that perspective.

[00:04:56] Tammy Bulson: So Aaron, if you have a good product manager, who’s given you the why behind why you’re building something, what happens when, or, or what, in your experience, if you, um, are building something that you all thought was the best guess based on what would take care of the customer, but then when it goes live and the customer doesn’t seem as joyed as we thought they would be, how would you like to see a product manager handle that situation? Or do you ever do, do we close the loop back with software engineers? Or how does that handle when, what we deliver does hit the mark?

[00:05:33] Aaron Roberts: Yeah, that’s, that’s also a good question. Um, one of the things that I like to see is any kind of metrics or numbers when it comes to product adoption or feature adoption from our customers. And that’s not necessarily something that even has to fall on a product manager’s shoulders, but there has to be some way for it to get back to engineering. It could be baked into the requirements upfront. So, a good product manager might actually be thinking about this upfront and build analytics into whatever the feature is that they’re working on or whatever the product is. That’s in question and have some way to have a dashboard, even if it’s an automated loop cycle that we’re talking about here, something like that is forefront in an engineer’s mind usually when they’re going through something, but with a good product manager, it may not be the first thought, you know, because you’re not necessarily worried about the numbers. You’re just trying to get the feature out the door. So having that kind of mindset as well, I think would help, you know, keep you, I guess it’s just keep that loop closed quickly. Like you said, the faster that you can make those changes in the faster you can push those things out. The faster you can get that feedback and see, oh, our adoption went up 10% because we did X, Y, Z thing, you know? And that, and that is something that when measurable, makes a really big impact on the team to be able to see, you know, the outcomes right away.

[00:06:40] Tammy Bulson: Yeah, so it’s, as a software engineer, it’s important for you to know where something lands in the wild, not just go code at, build it, put it out and go move to the next thing you care about, what happened.

[00:06:51] Aaron Roberts: Yeah, absolutely. Especially if it’s something that helps with revenue. I know that, you know, revenue is top of mind for a lot of folks in the management chain, but from my experience and, and me particularly being a numbers guy and a math guy, it’s just nice to see those numbers. I mean, it’s nice to see, oh, this had this XYZ impact, whether there’s any specific benefits to the team, if there’s OKRs is that you have to meet or goals that are responsible for, you know, helping with potential bonus structure down the line. It’s not, that’s not really the part of it, but just seeing that something’s making an impact also helps.

[00:07:24] Tammy Bulson: Nice.

[00:07:25] Will Sansbury: Aaron I’m curious if you can share with us a story from your experience. Think about the best product manager you’ve worked with and what they did that really made it a great experience for you, and tell us about that person. How did they show up for you?

[00:07:37] Aaron Roberts: That’s a tricky one. I’ve had some okay product managers. I think, I don’t have tons of experience just because I’ve only been on a total of three teams in the seven or eight years that I’ve been in the industry. But, I would say that I’ve got a pretty good, I don’t know if it’s a good story, but just someone who is looking out for the engineers at the time, which is also something that you might want a good product manager to do is coming in and telling actually a different product manager at the time, who was very adamant about how a particular piece of functionality needed to get done and exactly how much time it was going to take based on his or her information that they had in their head, which may or may not have been accurate.

Uh, so you know, a lot of, uh, angry vibes going on in a particular meeting where this one particular product manager was very adamant that all you have to do is this, this is what needs to be done, I need it done exactly this way and it shouldn’t take you very long. It should take this amount of time. And it was very, uh, technically driven that meeting of do XYZ thing. And there’s no ifs ands or buts about it. It has to be done in this way. And then on the other side, other individual who is standing up for us basically came in and said, listen, you don’t get to tell the engineers how to do what they’re going to do. Not exactly in these words, basically sit down and shut up, you know, almost, in a way that was constructive at the time and not obviously sounding like that. It really helped us to see, it helped me at least to see that different dichotomy of what that can be, and it was really nice to see someone have that effect on someone else in a way that they could constructively say, listen, we are going to do what we’re going to do. We need you to tell us what needs to be done and why, and then let us figure out the how, because that’s our job. That’s what we’re supposed to do.

It’s a pretty generic story, but that, I remember that very distinctly early in my career, actually, it kind of stuck with me that whole time.

[00:09:25] Will Sansbury: Yeah, that’s an awesome story. We’ve talked in one of our previous episodes about the myth of the single wringable neck and this notion that gets put on product managers, that everything is on their shoulders and they’re responsible for the entirety of the world. And I think a lot of times when people are fed that line of bull crap and don’t realize that it’s bull crap, they can get into a situation where they come in and try to control everything. So, you know, I think it’s one of the things that we’re passionate about. One of the things that really drove us to start this podcast in the first place, is that we’ve had that experience of working with teams that are really all in it together, where you’ve got designers and software engineers and product managers and testers and all of these different disciplines coming together, working together to drive these goals together. And it sounds like you described a product manager who gets that, right? Who understands that it’s not that you have to stay in your swim lane, but it’s that you do something really well. Do that really well and let the people who do this other thing really well, do it really well. I wouldn’t hire a general contractor to come in and renovate my house and tell them exactly what brand of drywall to use, you know, that sort of thing.

[00:10:30] Aaron Roberts: Yeah, and at the end of the day, it came down to like a trust thing, I think, right? And it could easily come down to that for anyone that’s in the same situation, one negative experience in the past, you know, would suddenly send your trust, you know, out the window for someone who’s in a similar role, even if it’s three companies later.

I mean, that thing can just like weigh on you for a bit. If you’re not able to push that aside and say, we’ve got to be able to trust the people that we have and make sure that they are supported well enough to do what they need to do.

[00:10:59] Amber Hansford: Yeah. Sometimes I believe that trust is one of those commodities in corporations that is in short supply at times. And it comes down to the fact that it really is the baggage that you carry from wherever you were before, or even if you were in the same company, but in a different group.

I wanted to ask you if there was the opportunity to sit in on an interview for a product manager at your company, what would be the one question that you would have to have answered that you would ask them?

[00:11:34] Aaron Roberts: Um, so I have sat in on a few interviews of that type of product manager interviews. And that is a really good question. Let me think for a second. Hmm. I think that something that would be important to me to ask would be just how in general, that person might deal with an engineer or even someone off the team who is trying to, I guess, overstep their boundaries in such a way that they were, I mean, similar to what the other individual in my previous story was, was doing, how would they deal with someone who was handling a situation like that poorly, where they were trying to push too much into the engineer’s swim lane or push too much onto the testers swim lane or not take accountability for not having done the job that they were supposed to do, which is define the requirements, define this, define that, or, or just understand the business need at the time. And how would someone that was coming into a role deal with someone like that who was on either the same team? Cause if you have a couple of product managers or product owner, product manager, kind of dynamic going on. And then how would you handle taking that on and making sure that that person is either coached in the direction that helps them not, it helps them support the team more, or how would you handle interacting with that person on a day-to-day basis to make sure that they weren’t a detriment to the team in some cases, which it can be, if they come in and say, Hey, you have to do things this way, that way. I’m not sure if that made a ton of sense, but that’s pretty much when I got,

[00:12:57] Amber Hansford: I got it. I got it. And I also am one of those folks that moved out of development into product, and I would try to critique code. I was very quickly shut down as I should have been.

[00:13:13] Aaron Roberts: Yeah. One thing I’ve noticed is it’s good to have someone that is interested in understanding how things work potentially at that level, but to come in and try to critique if you’re not deep in the woods of it. I mean, you’re, you’re going to have a bad time. Like basically things change so rapidly from even if you were a developer that went into like a TPM type of role, I mean, even then, if you’re not an individual contributor, things will change like that. And you just maybe have no idea what is happening anymore. Even after just a year. It’s very, very easy for that to happen and to get into a position where you just think you know, but you haven’t been in it, you know, or you’re not directly impacted by, or not directly impacting the team that that’s, or the code that’s in question so it’s hard to make that call, but staying out of it is the easier way, right? Trying to just let them do their thing and trust that the engineers and the managers on that side of the organization are doing what they need to do.

[00:14:08] Amber Hansford: For those folks listening, who want to move out of development into product, use me as kind of the poster child of what not to do, but that’s honestly how I started speaking in analogies, because it, it got me that step away from the code. If I could talk about things that weren’t real, but there were the good metaphor for what I wanted. It was the way that I could bridge that gap without telling a developer how to do their job.

[00:14:39] Aaron Roberts: Right, that makes sense.

[00:14:40] Will Sansbury: There’s a delicate balance there. I think though, because there’s also something incredibly valuable in having that beginner’s mind and asking kind of the obvious, dumb questions, even if the technical or architectural level, there’ve been times in my career where we’re working through something as a team and I go, well, have we looked at it this way? And I ask a question that I expect to be a quick pat on the head and go sit in the corner and instead it blows the conversation wide open, you know? So I think you gotta be open to both of those. I really think the difference is posture. If you’re coming at it from a place of humility, then you can ask questions and you can push into other people’s work in a way that is not threatening and does not devalue what they bring to their work, but for whatever reason, maybe I’ve just been unlucky. It seems like there’s a lot of product managers out there who have some fairly significant issues with their confidence and their self-esteem deep down to the point that they are very uncomfortable letting someone else be better at something than they are. I’ve always wondered. I don’t know why that is, but it seems like that’s the case often.

[00:15:41] Aaron Roberts: I think if I could just touch on that a second people have that type of, I don’t know, mentality in almost any industry that they are in. I don’t think it’s very specific to product owners or product managers. I mean, there’s engineers who have egos the size of the earth. You know what I’m saying? I mean, this is not something that is specific to a product manager, but it is like you said, having that awareness to come at it from a perspective of, I may not know much about this, but I will ask this question in a way that is not, you’re not accusing anyone. There’s no accusatory nature to the question. You’re just saying, I don’t know anything. Tell me how this works and why it’s done this way, just for my understanding. And if you’re kind of coming from that way and somebody will come along and they go and explain it to you, and then they’re like, wait, that’s actually not what I wanted it to do. That’s actually it wasn’t the intent, you know?

And if you can poke at it that way, it’s a very, very common thing. And just trying to tease out, you know, what is exactly happening here and engineers will do that amongst themselves all the time. It’s actually very specifically a type of engineering practice, I guess you would call it to like debug your own code just by reading it out loud to someone or, or to no one. It’s called rubber duck debugging is one that’s you’ve probably heard of. Just explaining the code to someone who’s sitting next to you and then you’re like, wait, why is it doing that? I didn’t that wasn’t part of the requirements here. That wasn’t what I was supposed to do. And you can figure stuff out just as easily that way.

So I think that you’re spot on in saying that you should be able to ask those questions and comment from that way, but having to have the right mindset really makes a difference.

[00:17:12] Will Sansbury: I think that’s what we see when we think about these teams that are really phenomenal, teams are firing on all cylinders, delivering greatness for their customers, those aren’t teams where the designers go over and decide all the design questions and then put them in confluence with the engineers can go read them, and then they build all the code. Right? These are teams that do pretty much all of the activities and delivering software together to some degree, but they have the wisdom and, or the, I don’t know what I’m trying to say. The wisdom or the wherewithal to let the person who’s best at it, guide the team through their parts.

So, you know, I, the way I always try to think of it and the way that I coach the product managers that I lead is their job is not to be the expert on the product. Their job is to be the facilitator of the team, getting something out. That’s great. And there are times that they’ll be operating through expertise and there’ll times that they will be the absolute idiot in the room.

And both of those are okay and necessary. So, that kind of notion of the team coming together, doing things together, starting and finishing together is so critical for teams that really manage to produce a lot of that.

[00:18:17] Aaron Roberts: Yeah. I will say one of the difficult parts of that is that you’re rarely on a team that got to start something together. You’re often, very often, thrown into a team that is either already up and running or has been up and running. You know, either just got up and running has been up and running for years and like cycled individuals out as, as people, you know, churn. Which is just, you know, the cost of doing business. You’re very rarely in a situation where the entire team was hired and then was like, go do this thing and then spun that thing up from scratch, you know, in a way that they were able to do it, how they wanted to, or how they felt was necessary. And that’s really one of the, I think, big hurdles to get over as any team or any product manager joins a team, or even an engineer, is to figure out how you can get to a point where it feels like you guys are all working together on something that you all built rather than just like maintaining something that’s been around for 10 years, you know, or, or less in some cases, but in legacy software, it’s hard to find something that is you can truly own and want to take ownership of because you weren’t around when it was built, right? Why is it done this way? I don’t know. It was like that when I got here, right? And then somebody, people are coming at you trying to figure out why stuff is like this and nobody knows because it’s been like that for however long. That’s a really serious problem, I think that is hard to address.

[00:19:34] Will Sansbury: And I think that dovetails all the way back to your original point though, Aaron, right? There are product managers out there, certainly, that look at their backlog is just the collection of the items that somebody was screaming about loudest and the order of who’s screaming at which volume, right? And so when it gets to the team, it’s this disconnected jumbled mess of incrementalism and good product managers are going to be in the business of driving clarity for the vision of the product. And they’re going to be in the business of helping the entire team see that we may have a product that’s been around for even 25 years, but the way we’re changing the world right now is this. And here’s the collection of stories and here’s the collection of epics. And here’s the work that does that. If product managers can drive that they can get to the point that the team can start and finish something together. It’s just a much smaller something. Right.

[00:20:24] Aaron Roberts: Which is totally fine. Yeah. But a project, a anything that the team can get behind is, you know, is important, not just, like you said, change this there and that over there and increase the font size here and update this button over there. You know, that’s not going to bring a team closer together collaboratively. It’s just, like you said, incrementalism, that is, while important, you know, it’s not a project that will get everyone on the same team, I guess, I should say. For lack of a better word.

[00:20:49] Will Sansbury: And strategically it’s a path to death, right? There’s no product that has been on that road for very long, that have suddenly become wildly successful.

[00:20:58] Aaron Roberts: Right.

[00:20:58] Will Sansbury: You’ve got to have vision and strategy.

[00:21:00] Aaron Roberts: Right.

[00:21:00] Will Sansbury: Get there. Yeah. Awesome. Well, Aaron, thank you so much for spending some time with us today. This has been a great conversation. We’ve enjoyed kind of getting your perspective of what product management means and how it works best with software engineers. Enjoyed getting to reconnect with you. Haven’t seen you in quite a while, so it’s good seeing your face and hearing your voice.

This is the first in the series that we plan to do with different disciplines, working in balanced collaborative teams to deliver products together and understanding what different disciplines need the product managers.

We hope that you’ll tune in for our next episode, where we’ll be looking at another discipline, the user experience piece, and how a user experience designer or researcher best collaborates and works with the product manager. If you’re interested in hearing more, or you have a topic you’d like us to cover, or even if you’re somebody sitting out there and you’re thinking, you know, what? I love what I do, but I wish product managers understood this. Get in touch. We’d love to have you come and join us and sit in our hot seat for an episode. You can check us out at productoutsiders.com and find us on any podcast provider stay gold, friends.

[00:22:03] Amber Hansford: Stay gold.

[00:22:06] Tammy Bulson: Stay gold.

[00:22:07] Aaron Roberts: What, am I supposed to say something?