There are a lot of different hats we wear as Product Managers, which means that there are a great many opportunities for us to do the right thing, at the right time, for the right people. But the inverse of that is also true — by virtue of wearing so many hats, there are a lot of opportunities for us to do the wrong thing, at the wrong time, for the wrong people. These anti-patterns have a tendency to sneak up on us and bite us when we’re least expecting it, and therefore least prepared for them. But by being aware of them, we can keep our eyes open and try to avoid them if we spy them sneaking up on us in our rear-view mirror. This is far from an exhaustive list, but I’ve compiled five mistakes that Product Managers often make that set us up for almost inevitable failure.
Telling a Team How Long They Have Instead of Asking Them
Ah, yes…the classic move of committing a development team to work before they even know that it’s coming. I’m guilty of this one, as I would suppose all of you are — or have been in the past. But this is literally one of the worst things that we can do as Product Managers, and I have a terrible time trying to come up with even one situation where doing this and not course-correcting extremely quickly didn’t come back to bite me in the ass. We simply can’t commit to something on another team’s behalf — we don’t understand the technology (even if we think we do); we don’t understand the complexity (even if we think we do), but most importantly, we’re not the ones who are going to actually be doing the work. We don’t pretend to be the customer (or we shouldn’t), so why do we think that we can pretend to be the development team. One of the fundamental tenets of agility is that we don’t know what we don’t know — and we should leverage the resources that we have to figure out these unknowns. So next time someone wants you to commit to something — even if you firmly believe it to be trivial — just don’t do it. Instead, tell whomever is asking you for the work that you’ll check with the team and get back to them with a sizing estimate and a possible timeframe. It doesn’t have to be an arduous, detailed slog — but we owe it to our development teams to have a say in what they’re working on and how long they think it will take. They’re the experts, not us — so treat them like it.
Making Commitments to Customers Without Thinking It Through
This is another all-too-common faux pas that Product Managers commit — especially early on in their careers. We are, by nature, people pleasers (assuming that we’re not sociopaths), and as such it can be exceptionally tempting when working directly with a customer to want to commit to something without vetting it outside the conversation. It feels good. It sounds good. It makes the customer feel special. But it will kill you in the long run. Because it’s just one customer’s request. It’s just one customer’s issue. It’s just one customer’s perspective. And you’re placing a huge social capital bet when you tell a customer that you’ll “ensure that their issue gets addressed”, only to hang up and realize that you have 25 higher priority issues and not enough developers to even take those on. You place yourself, and your team, in an impossible situation when you do this — you’ll wind up finding data to back up your promise, you’ll start to move things around that are clearly higher priorities to others, and you’ll essentially sacrifice your credibility just to fulfill that promise. Don’t be that person — head it off at the pass. Tell the customer that you’ll have to review their feedback and get back to them — quickly, of course. But never, ever commit to doing something in the moment that you aren’t 100% sure that you can deliver — and even then pause, analyze, and stall until you can make sure that you’re not sticking your neck out.
Ignoring Repeat Behaviors Unaddressed in Retrospection
As Product Managers, we constantly have it drilled into our heads that we’re not part of the Scrum team; that we’re “chickens” and not “pigs” — so we should listen and not talk. And, for the most part, this is true — and good, useful guidance. But there are also times when we need to assume the mantle of leadership that comes with our role, and bring up issues, questions, or concerns to the team when they’re simply not addressing underlying issues that are affecting their ability to perform. Often, you’ll see these in patterns during retrospection — not obvious items, but the underlying themes behind them. Maybe there’s one person who’s not pulling their weight; maybe the tools that they’re using aren’t really fit for purpose; maybe there are external dependencies that keep popping up over and over again. We need to be the voice in the room that holds the teams accountable, and pushes for them to ask and answer the hard questions. We cannot sit idly by and watch retro item after retro item related to a similar theme get raised and dismissed, or raised and barely touched. Part of being a self-organizing and self-organized team is accountability, and as Product Managers we’re often right there in the room as a voice that can impose and enforce that accountability, and who can help in some of the next-level problems that the team may not be able to directly address themselves. If you see something, say something — as the adage goes; and that counts double for paying attention during retrospection to ensure that the teams are doing what they need to improve constantly.
Blindly Doing What Your Boss Wants You To Do
Don’t get me wrong — we all have a boss, and at some point in time we have to bend to the authority of those who have positions of power in the organization. But what we can’t do is always bend to the HiPPO in the room, to always do what’s asked of us, to always take on the pet project of our boss or our boss’ boss. We need to take the role of Product Management seriously, and that sometimes means pushing back on those in the organization who want us to do something not because it’s in the best interest of the customer, but because it’s locked in their mind as the “right” thing to do. That doesn’t mean that we just shake our heads and say “No” — there are many ways that we can push back without saying “no”. Rather, we need to take the input and feedback from these key stakeholders and analyze it, collect data around it, and return with a position that’s supported by facts and not merely opinion. We need to use all of the tools that we have available to us to control and push back on random ideas and solutions that don’t actually have problems.
Letting Confirmation Bias Skew How You Read the Data
Lastly, it can be very difficult at times to collect data that challenges our assumptions, that makes us question the things that we “know” to be true, and that generally go against the path that we think we really want to take. But this is actually when data is the most important — not when it confirms our assumptions, but when it challenges or disproves them. This is where the Product Manager must have the strength to take the data at face value, and to use it to determine how you should proceed — do you pivot your project into a slightly different direction, given the feedback and data that you’ve collected; or do you put a hold on things until you can find the supporting data and proper market for the solution that you’re trying to build. Either way, what you do not do is to continue working on something, knowing that the data’s not there. No matter how much you want to; no matter how close you are to the work; no matter what your instinct or gut is telling you, you simply do not do that. Data is data — if it’s not supporting your presumptions, that’s not the data’s fault. Sure, you can look for more data, different data, take another tack to find something that supports what you want to do — but you don’t do that while working on something the data is telling you is wrong. You’re wasting time, effort, and resources doing that, for what all indications are that there’s no “there” there. Product Managers must be able to admit they’re wrong, that they are heading in the wrong direction, that we’re pursuing a solution without a problem. We analyze, assess, and then act.
