In today’s episode, we have the ultimate showdown between product management and developers. Meet our guest Rob O’Brien. His career started in information science technology, giving him a good grounding in app development. He has since gained extensive experience managing engineering teams as well as coaching product employees and building product teams. O’Brien shares what he believes to be the biggest missteps that product managers can take and illustrates why product managers should be available for feedback throughout the development process. Hear why it’s important to have good communication between product management and developers and why the entire team should be present during stakeholder feedback. We also discuss how to identify what should be the company’s top priority at any given time, and how you can use the RICE or MoSCoW methods to objectively determine what to pursue at a particular point in time without conjecture. Join us for an energetic discussion on all things development, product management, and teamwork!
Key Points From This Episode:
{{addCallout()}}
Transcript for Episode 264. Product vs. Developers with Rob O'Brien
[INTRODUCTION]
[00:00:00] MN: Hello. Welcome to The Rabbit Hole, the definitive developer’s podcast. Living large in New York. I’m your host, Michael Nunez. Our co-host today –
[00:00:08] DA: Dave Anderson.
[00:00:09] MN: Today, we're talking about the fight of the century. It’s product versus tech.
[00:00:14] DA: Yeah, that's right. It's Godzilla versus King Kong. Which one's which? It is hard to tell. They both have their downsides and their upsides.
[00:00:24] MN: Yeah. I think we're both tech individuals and software engineers, but we got a special guest in the building. He's going to defend the product and we’ll –
[00:00:32] DA: A contender.
[00:00:34] MN: Yeah, contender who's going to destroy both of us at the same time single-handedly. We have Rob O’Brien in the building. How's it going, Rob?
[00:00:41] RO: It's good, man. How are you guys doing?
[00:00:43] MN: Chilling. Chilling. Rob, tell us a little bit about yourself.
[00:00:46] RO: Yeah. My background started in Information Science Technology, which gives me a little bit of a background in tech. Learn the basics of development and all that, but with a mix of project and product management. Have managed engineering teams, but have also coached product people and build out product teams. I think I got the right skill set to hold my own in this little bit of a battle. I think I'll go Godzilla on this one.
[00:01:10] MN: I didn’t see the movie, brother. That’s not fair.
[00:01:12] DA: He got the draft pick of Godzilla. All right. All right, fine. We’ll take King Kong.
[00:01:18] MN: We’ll both be King Kong. We’ll do some Voltron deal.
[00:01:22] DA: I'll be Diddy Kong.
[00:01:27] MN: Yeah. Let's talk about, I think we were doing the outline for this episode. I learned a new word, and it's called faux pas. Both of y'all had helped me out in pronouncing that word.
[00:01:39] RO: Faux pas.
[00:01:40] MN: Yeah, because I was like, fullpass. I was like, this is the fox pass. But it's not. It’s the faux pass. We're going to talk first about Rob, we're going to talk about the product first. I'm sorry. The outline was written that way. I promise, we didn't do that on purpose.
[00:01:52] DA: No, you got to just hit him, hit him low. We fight him dirty.
[00:01:57] RO: I'm in your world. It's two on one. Whatever you guys want.
[00:02:01] MN: Yeah. Let's talk about some of the product missteps that happen. What are some things that we may see product managers in the wild do? How do we address some of those issues and what can we do to bring a resolution to certain things?
[00:02:17] DA: I mean, I feel like, sometimes you get in a situation where everything is top priority. That can be so frustrating. It's not always the product person's fault. I could blame them. Yeah. Oh, [inaudible 00:02:33]. Okay, great. Yeah, just take the punch.
[00:02:37] RO: Sorry. I'll counter it. Don't worry.
[00:02:40] MN: Then my question, Michael – I have a question. I mean, I've been in development teams where that happens. There's a lot of thrashing. Where like, you're working on this one thing and it's the most important thing. Then suddenly, there's this new thing that you have to dive into for the next sprint. Rob, you say that that is the product manager’s fault. Dave, did you think that it was someone higher, like a C-suite, or someone else who has input in the work that gets done?
[00:03:05] DA: I mean, you can end up with so many stakeholders that are all trying to get their own thing into the pipeline. To them, each thing is most important. Or even if there's different users, or different kinds of users that are represented in the product. They’re maybe the most important thing for a different, each user. In the end, one thing has to be the most important thing that is worked on.
[00:03:35] RO: Yeah. There's something really interesting, we always say when we coach junior product people, or people who want to learn how to be a product manager, product owner. One of the pieces is you say no a lot more than you say yes. I'm saying yes once to some person at some short timeframe, and I'm saying no to everyone else. Because you can't have a million priorities. You have to have one. Everyone's saying no for now, and one person and one thing is yes for now. You use concepts like sprints, and whatever else you could be doing to get that priority straight and to say, “This is the goal. This is the focus.” Everything else is a no for now.
[00:04:08] MN: I love that. It's like, your blinders are on. You have said no to the whole universe of possibilities, except for these 10 stories, or your 20 points, or whatever you're committing to for that sprint.
[00:04:23] RO: Exactly. The no to yes ratio needs to be very disproportionate. That's how you know you're doing it right. Otherwise, you're going to be doing the faux pas’ that we're talking about here, where your dev team’s like, “What are we doing? What's the highest priority? Because I don't see a priority. I just see a list.” Very different.
[00:04:40] MN: Yeah, I'm glad that I'm not that person. Because I usually say yes to everything, and then nothing will get done. That is a huge, huge problem. As you mentioned, it's just being mindful of who you say yes to. By saying yes, you have to turn down everything to make sure that the thing you did say yes to gets done. That's good. That's good to know. I think I've felt the extreme end of everything being top priority. I know that it can definitely cause some burnout. I think that If the product manager can laser focus on the thing that gets done.
If the product manager can focus on the thing that can get done by saying no to everything else, then not everything is top priority. This one thing is top priority. We need to get done. I think that, Rob, do you think it's the product manager’s job to identify, or figure out what is the thing that is top priority? How do you come to that conclusion that it is top priority over the other things?
[00:05:37] RO: Yeah. It's absolutely the product person's priority. It is their number one job. It is the hardest and most important thing you can do is saying no to everyone, except for the one, or two people you are saying yes to for that duration. There's a lot of different techniques you can use for it. Prioritization techniques. There's RICE, there's MoSCoS, there's all these different prioritization techniques that you can use to have a fact base behind this.
The technique itself isn’t what's important, but using that as a tool to say, “This isn't my gut feel or my opinion, here's the data and the framework I use behind it. We can now disagree on something that is not an opinion.” It is a framework that we're using and using that to align with all the people who said no to, to say, “Look, here's the data. Do you want to argue with that? Great, then let's change the data.” Trying to take it away from, I think, this is most important to this framework is telling us is the most important, is a really, really big and important tool for product people to use.
[00:06:33] DA: Right. MoSCoW, that's the classic, like most, could, should, would.
[00:06:37] RO: Yeah, exactly.
[00:06:38] MN: What is RICE? Honestly, I don't think I've ever heard of RICE before and I'm getting hungry.
[00:06:43] RO: Yeah. RICE is a framework that consists of four attributes that you use to judge and prioritize each piece of the thing you're trying to prioritize, or the item you're trying to prioritize. It's made up of – it's just an acronym. There's reach. How many people is this feature, or story, or goal going to touch, impact? How much impact will it have on the people that it is reaching? Confidence. How confident are we that we can finish it? Effort, which is I looked at developers study, what is the level of effort to complete this?
Those give you that nice, full mix of things to say, we can use that scoring and we can talk about, well, the effort on that is extremely high and the impact is extremely low. Is that the right thing to work on? Probably not.
[00:07:23] DA: Yeah. Then, it's just like, it's not feelings. This feels very important to you, but the math says, or the label is that low impact, low effort, or what have you.
[00:07:38] RO: I do want to throw a counter punch here. Counter punch to a product person will do the faux pas of making everything top priority. The devs faux pas is over-committing and giving us too many things that would give us the ability to prioritize. I might say, these are the top four priorities. The dev says, we can do all four of this this spring. You know you can’t. You just lied to me. It was only two and you just screwed up everything. It’s a challenge, right? That's why it's a lot less of you.
[00:08:05] DA: Okay. I think the big lesson is the power of no. You can say –
[00:08:11] RO: The power of no on both the power.
[00:08:13] MN: Yeah. It's not just a product person at this point. That team needs to also be realistic and say, “No, we can only do two of the four, or our velocity shows that we will complete X amount of points, which means that we might be able to get one or two a year requests done.”
[00:08:31] RO: It’s a great way to train your product person. You can train your product person to only pick one top priority, by only saying, “We can do one thing this sprint.”
[00:08:40] DA: Rob, I’d second that. That’s just a bonus.
[00:08:43] MN: Rob, I think we could do all of them, bro. Come on.
[00:08:46] DA: Yeah. I do feel like, when we’re thinking of all of our pet peeves, this list is also that. It's like, can we say yes to all these? I'm going to say yes to all of it, Rob. I’m ruining it. Another thing, acceptance criteria, like grooming. Getting in the grooming. Sometimes, you will get a ticket that is just like, “Please, build the thing.” I swear to you. I have literally gotten a ticket, where it was like, there is an entire page and it has all of the features and functionality. It's like, here is a ticket for the page. Just make the page the same as the old page, doing cutover to new technology. Just make it the same. Build it.
[00:09:35] MN: Build the thing. Oh, man. Yeah. The idea of having unclear acceptance criteria from the product person given to a developer and then we have to figure it out. I think what makes it worse is when you do it. Like I say, you do your best, you looked at the picture, you made it and you bring it back and it's like, “No, that's not exactly what I wanted.” It’s like, “Wait. But you did ask for anything.”
[00:09:58] DA: Yeah. I mean, I think that kills me about this is it makes it really hard to talk about trade-offs. If you just do this thing, then how do I decide how I can ship sooner, or what is really the most important of this whole cornucopia of different buttons and widgets and things inside of this thing?
[00:10:24] RO: Yeah, I think the biggest thing there for product people is that you can't – You got to force yourself into certain frameworks to challenge yourself. There's a lot you can learn from BDD, behavior-driven development, to make sure you're thinking about what is the behavior, the functionality is trying to drive. I've done this with data products, where there is no – if there's no front-end software, but you can still follow the same format.
A really common one is gherkins that comes out of this, which is given when then, and you're saying given, the preconditions, what has to be true beforehand. When, the action that whoever, or whatever system this is taking, and then then, which is the result that you want afterwards. It's quite hard. It sometimes feels overly complicated to use that structure. For product people forcing yourself to use that structure, will get you away from just writing really long paragraphs about what you want it to do, or being like, make the thing work. I don't know how to phrase this. It gives you that structure and the starting point that the team can then – the dev team can give you feedback on.
[00:11:27] DA: Yeah. Definitely makes it easier to articulate. Although sometimes, you end up in the form of like, “As a user, I want blah, so that I can do the other thing.” Sometimes, there's no really deep thought about what the user is, or what those other criteria. Then, it just seems very samey.
[00:11:49] RO: That's different. What you're talking about is not acceptance criteria. What you're talking about is the user story. It’s the top. It’s the description. The description itself is oftentimes vague and I agree. The generic user story format is – A lot of people have evolved from it. There's something called job stories, which is a slightly different format. Acceptance criteria should be very explicit, very pass-fail, yes, no, thumbs up or thumbs down, it's done, or it's not done. Where the user story is a description, is telling a story and is meant to drive a conversation. It is not meant to be that explicit. The acceptance criteria is the criteria to say, is this functioning as we needed? Yes or no. It can't be vague.
[00:12:28] MN: Yeah. Just imagine if you have – I’m sure that there are acceptance criterias that are clear. I mean, writing user stories and ensuring that there is a story makes sense is a plus. I think, the acceptance criteria, as you mentioned, Rob, is the specific set of ask that the story is asking for, for it to be considered complete. When that is not clear, then the developer – I think this might be, I'm doing a counter and then punching myself. I think the idea is that if the –
[00:12:59] RO: Join Godzilla, Bobby. Join Godzilla. Come on my side.
[00:13:02] MN: I just sat on myself.
[00:13:03] DA: It’s a classic Kong move. Just punch yourself in the chest.
[00:13:05] MN: Yeah. The idea being that if a developer reaches a story that they may think it's unclear acceptance criteria, then they should be asking questions about those acceptance criteria to ensure that everyone comes to an agreement before the story starts.
[00:13:22] RO: Yeah, exactly. I think, there's a big thing where one of the faux pas I see for developers is to, maybe in grooming, or refinement, you're looking through the story, or maybe later when you're working on it, and you realize, there's a couple other different scenarios that I'm thinking about that aren't captured here. Well, that's not my job. I'll ignore that. Probably the person should have thought of that. That is a massive faux pas. No, no, no. Call that out. Get the product person on the phone. Talk to them.
More times than not, a developer will catch things that I've missed and they're really, really good things, or can actually change the story for more impact. Because yes, I might have thought about that story and the acceptance criteria for 20, 30 minutes. You spending the time developing it and getting in the weeds, you're going to uncover things that I didn't think of, and that's extremely valuable to have that open communication between us.
[00:14:13] DA: Right. Yeah. You learn so much as you go in and you peel back the covers and see how all the pieces are coming together and what it actually means to interact with the thing in a real way.
There's that phrase that a certain friend of the show loves to say all the time, stories of promise have a conversation. That's like closing the feedback loop. If you're learning things when you're doing the story, then you should connect back to the product manager and hopefully, they're available for you to have those conversations with. I know, that's another thing that maybe it's essentially related, whereas the product manager is just stretched so thin, that they're just not available to have those conversations and they need to put too much pressure on the acceptance criteria to be bulletproof.
[00:15:09] RO: Yeah. To your point, you're misunderstanding the role and you're almost thinking too highly of yourself and your work, but you're not going to get it perfect. The point isn't to get it perfect. The point of the product owner is to get that initial pass, get the team's feedback to make it better. Then as you build it, be available to make it even better after that, right? We're not doing waterfall here. That breaks down to all the levels. That breaks down from the high-level planning, to the basic planning, to the middle of the building that you can iterate, you can change, you can think about things.
You're just looking for the outcomes and you really need to be focused on those outcomes, rather than the specific task ahead of you, or the output. You're looking for outcomes. If everyone's anchored on the right outcome, which a story will often give you, this user is trying to achieve this thing for some reason. If everyone anchors on that, and rallies around that, the details can change, and they should change, because you should just do what is best based on the information you have.
[00:16:04] MN: You know what really grinds my gears? There could be a story that gets introduced by the product manager. It usually follows up with, “That should be easy, right? We should get that done really fast.” What do you guys think? I think, this is a one, right? Do we have to go and vote and see if this is a one across the board, people? Nah, it's a one. Let's make that a one.
I always find that really frustrating, because I don't want to tell the product person or anyone how to do their job. I know, they may not mean it that way, but it definitely feels like the person is trying to tell me how to live my life and do my job. I'm not really keen on that, I guess. Especially, the idea that – or they work with one person. They may work with the tech lead and do all the estimations that way. That's another thing that I've seen. Have you all seen anything like that before with estimations, with the product owner and the tech lead?
[00:17:02] DA: Oh, yeah. Totally. I mean, Rob does it all the time.
[00:17:08] MN: You’re working together. Yeah.
[00:17:10] DA: I'm joking. I think he likes to be so invested in it, but you hold your estimate close to your chest and you're like, “Oh, okay. I was surprised by that.” I think that's the right way to do it, where you maybe have an opinion, but you're not trying to put a thumb on the scale too much.
[00:17:26] RO: Yeah. I think to Bobby's point, there's levels of how bad you can be. You can try to estimate it yourself as a product person. You can try to sway everyone and tell them what it should be. You can only work with one dev that you think will give you the estimate that you want and there's all these various levels. I think for product people, I always take it as a learning opportunity. I don't code. I don't look at this stuff. For me to learn about the complexity of something by hearing your estimate, I might ask you to explain it. It shouldn't be because I think you're wrong. It's because, what did I not know? What's the opportunity for me to learn something about technology and development that I didn't know, which will make me better at thinking about the products I build?
[00:18:04] MN: Get that feedback loop going. Also, if you're spending the time to do estimates, which is a time consuming process, and you're putting your thumb on the scale and various ways to skew it, then you're losing a really powerful tool, like to say no to things that might be more complicated than you think. If you think it's a one, but it's actually a five, then you're going to be like, “Maybe I don't actually need this. Maybe there's an alternative. Let's think deeper on it.” Yeah, it's a tool. Look at it in the long-term and do it as a team, and it'll – maybe you'll get good at it, but it's still really hard. You're still going to be wrong.
[00:18:50] MN: Right. They're called estimates and not actuals. Because you're busy, you're estimating and you’re learning the team and the infrastructure and the code base, you know what may need to be refactored and what doesn't. That particular part of the code base is pretty hairy, so it's going to take X amount of time. You get better. It's like a thing, a routine that you do and you get better over time. With the same team, you'll get the sense of how to do your estimations right.
One thing that I have seen before, and I'm glad that we have Rob in the building to help us out, is often, the work that software engineers do is usually just headphones on, you give me the work and I'm just going to punch keys and semicolons until it works. I don't want to talk to people. Do all product people think that that's how developers normally operate? I mean, I know that that could be a trope that I can see. I myself can be that person. I'm curious, if this product also takes that extraverted people’s person role when it comes to operating within the team?
[00:20:02] DA: You got to keep the devs out of direct sunlight. Don't make eye contact with the developers.
[00:20:09] RO: Make sure they have snacks.
[00:20:12] DA: Just give them a closed bar.
[00:20:13] MN: A coffee. A coffee. You always got the coffee all day.
[00:20:15] RO: No, I think it's one of those things that there's a very common misconception that engineering, or tech, or any of those is like, look, they can't talk to people. They'll confuse the business. They can't speak business and business can't speak tech. That's why I'm here. I need to build this wall between them to save them from this terrible conversation, where everyone will get upset. It's not true. I think, the thing is, you have to understand the frame that people are coming from and their skill sets and their knowledge base.
When a finance person comes in and starts talking to a tech person, you don’t want to just have the conversation be around, “We need to make this much money this year. How can we do this with software?” What a ridiculous question. No engineer is going to be able to answer that. Also, you want to protect your engineers from having to deal with someone saying, “Hey, what are you working on? This is the most important thing right now.” No, that's not. That's not [inaudible 00:21:06].
[00:21:07] DA: Oh, man. Like the CEO coming in.
[00:21:10] RO: Yeah. It's just a matter of getting people comfortable and having the right conversation that happens gradually over time. The more you can get your developers to be thought of as partners with the business and knowing them individually. We do a couple things on our team that I really love, is our developers are demoing the work that they complete directly to the stakeholders, whether that be the CEO of a company, or a finance person. Not only that, all the work that we complete, shout out to DD from Stride who started this. All the work that's completed, we say, “Who developed it?” We say, “This feature was developed by Dave Anderson. Thank you, Dave, for building this.”
You have to have a connection between your developers and your stakeholders, because that's how you get the most knowledge sharing, the most understanding, the most robust conversations. If you have a pigeonhole of just a product person, is the only person who hears from both sides, you're playing whisper down the lane, or telephone, or whatever gamey things, child, that will explain to you how bad of an idea that is.
[00:22:09] DA: Right. I guess, there really is a critical role for the product manager to find a common ground, or a common language that can facilitate the conversation between the two, because like you're saying, if a finance, or marketing persons in there and they're like, “Oh, I got my KPIs. I got to push my numbers.” It’s okay like, “I appreciate the help of someone like me.” Okay, what does it actually mean for the area that we're working on? What is the metric that we are caring about? What is the overlap between us?
[00:22:45] MN: I have a question about the shielding. This may have to do with what the organization itself outside of the developer and product, but what if the product manager feels like they need to shield them from the feedback that they may get from the stakeholders? What if the stakeholders are raw and authentic? They're saying, “Yo, this is trash? Why did it take five seconds to load?” Everyone knows why it's complicated. The stakeholder, or the people demoing it to may have some critical feedback that might be – what's that? The radical candor feedback that can be delivered during a demo.
[00:23:26] DA: Right. Or like, it’s not done yet. It's not done yet.
[00:23:31] RO: Here would be my thing, and maybe this is throwing it over to you guys. Do you think it's better for the product person, one person to feel all that pain directly? Or do you think it's better for the entire team to feel and hear that feedback? I think, if I heard – I've seen developers be like, “Yeah, my product person is pissed off. That's their job. They take the hit. I don't need to hear it.”
Well, that's not going to motivate you, or incentivize you as much as all of us jointly as a team, not as the product person. Us as a team, riding and dying by what we deliver. Good, bad, ugly. It's not the product person's job. It's not their fault. It's everyone. I think that's really important to building that team mentality of, we really don't want to point fingers. We want to say, “We as our team delivered this. You don't think it's good enough? Let's chat about it.” You don't point at the developers. You don't point to the product person. You say, “This is what we did. We're proud of it. Let's chat.”
[00:24:25] MN: Yeah. I think that some you just brought up, the idea of the product manager having to take all that feedback in by themselves and write it out and make it more, the feedback more tangible. Would be a little difficult on the product managers to have to deal with that. I'm pretty sure that if multiple people in the room are listening, the feedback that gets dished out wouldn't be as radical cantered, I would say. If so, then we're going to have to fight outside. That's just how I feel. That's just what's going to happen.
[00:24:55] RO: You also brought up a good thing that reminds me. It's like, I've been in multiple sprint reviews, where we're demoing what we've done and we've gotten feedback. I think, Dave, this was while me and you were working together. We've gotten feedback from a stakeholder. We take the feedback, we say, “Great.” It wasn't just me. The whole team was there. When we go back and discuss it as a team, my interpretation as the product person was actually wrong. It was incorrect. I said, “Oh, they meant this. Let's go build that.” Luckily, my whole team was there and they go, “That's not what I understood the feedback to me. I thought it was this.” Everyone on the team besides me thought that and I go, “Wow, I must be wrong.” We go double check with the stakeholder. Yeah, the product person was wrong.
Thank God, the whole team was there to give their own interpretations of what they meant and we had more than one perspective, because we would have gone and wasted a lot of time building something that I thought.
[00:25:44] DA: Yeah. I think that's a great mindset for a developer to have, where it's like, you want to build the right thing. You want your software to be useful and used. Having that connection with the stakeholder internal, or even the customer, going out in the field and having your product manager connect you with product, or with customers who are actually using the software and are impacted by it, you can better empathize with the solution you're trying to build and second guess if the proposed solution may not be the most ideal one.
[00:26:24] MN: I think there was a couple of the product faux pas’, although Rob held it down and actually had a couple counter punches to that.
[00:26:31] DA: Yeah. Godzilla in one corner. King Kong and Diddy Kong.
[00:26:38] MN: Yeah. We got a little lumps. I got a black eye. I'm cool, though. We'll definitely going to want to talk about more of the dev faux pas, because I know there's a couple up my sleeve that I've done and I’m going to punch myself a lot next time, Dave. I’m sorry. We might lose. We might just lose.
[00:26:56] DA: Yeah. We'll have to say, best out of three.
[00:27:00] MN: Yeah. We're going to have the best out of three this one.
[00:27:02] RO: Best out of three. There you go.
[OUTRO]
[00:27:04] MN: Follow us on Twitter @RadioFreeRabbit, so we can keep the conversation going. Like what you hear? Give us a five-star review and help developers just like you find their way into The Rabbit Hole. Never miss an episode. Subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson, and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
