A common theme in online discussions and forums around Product Management lies in how to level up our skills and be a better Product Manager. While there are a lot of different options available, just as there are as many different aspects of Product Management to focus on, there are some very specific areas that any given Product Manager can assess themselves in and decide what next steps they want to take to become a better Product Manager.
As Product Managers, we’re often involved in making decisions and driving others to decisions that need to be made — sometimes dragging them kicking and screaming toward the future. And in doing so, there’s often an undercurrent of “reaching consensus” that runs through discussions and permeates meetings comprised of varying people with a wide breadth of interests and agendas. But the simple fact is this: consensus is, more often than not, a means by which the great is sacrificed at the altar of groupthink. Great ideas are rarely consensus-driven ideas; they challenge too much of the status quo to be something that everyone can agree on. Let’s explore some of the ways that consensus-driven decisions suck…
I’ve touched on User Stories on several occasions, my favorite being Why Your User Stories Suck! Today I’m here to share with you a very common, yet very commonly overlooked, way to check each and every User Story on your backlog to see whether or not it’s really “ready” for your Dev teams. One of the most frequent causes of delays and slowdowns in most Agile implementations that I’ve seen comes from a lack of balance in the User Stories that the team is being given to deliver — stories that are too big, or which are dictates, or which just exist on the backlog because “someone asked for it”. What we need to do as Product Managers is to occasionally take a close look at each of our backlog items and make sure that they meet the INVEST criteria — Independent, Negotiable, Valuable, Estimable, Small, and Testable. If we do this simple gut-check on a regular basis, we’re far more likely to see our teams succeed and to reduce the amount of time wasted in long, drawn-out planning sessions.
I was working with a future mentee last week and we noticed a recurring theme to some of our discussions — that a large part of good Product Management results from limiting the number of choices that our teams and our executives have to choose from, so that they make decisions that reflect the actual priorities that should be driving our next moves. In most organizations, there is an almost unlimited number of ideas, concepts, directions, and motivations from which to choose — and trying to manage all of them at once is certain to drive any Product Manager insane in very short order. Rather, in order to ensure that we’re doing the right things at the right times, we need to be constantly limiting the possible permutations upon which we drive decisions so that we can be sure that we’re moving in the right direction while being open to new ideas and concepts!
We’ve all been there — whether you’re a Product Manager or not, you’ve sat in a meeting that’s going far longer than it should, horribly off-agenda, listening to people bicker about some minor point that’s preventing anyone from moving forward and actually making an actionable decision. Usually what happens is the loudest person in the room wears down everyone else until they feel that they’ve achieved some perverted form of “victory” before either the meeting runs out of time, or (even worse) they think that their decision is that of the group and there’s nothing more to discuss. This is especially a problem if, as is the case in many smaller companies, the loudest voice in the room also just happens to belong to the CEO or COO of the organization. These meetings are the bane of everyone’s existence, not only because they’re ultimately pointless and a waste of everyone’s time, but because they contribute to a culture of direction from the top and not innovation from the ground up. If the CEO is always right, then there’s no point in anyone who’s not the CEO making decisions.
But that’s not how these meetings should happen, and it’s not how they have to happen. With a little bit of planning and preparation, any good Product Manager can run an effective meeting where people feel like their voice has been heard, their positions understood, and everyone leaves the room with a mutually-agreed plan in place.
Know Your Players
I like to think of a meeting as an opportunity to exercise my directorial skills — and I mean that in the theatrical sense. Every great director knows not just which parts his performers will play, but how they will play them. You don’t cast someone meek and quiet to play Sky Masterson in Guys & Dolls, and you don’t cast a loud, obnoxious diva to play Christine Daaé in Phantom of the Opera. You know the roles, and you know the players available to you — and it’s your job as a director to place the right people in the right role at the right time to see them shine onstage. Similar considerations need to be given when planning your meetings. Who’s the person on the exec team for whom nothing is ever good enough? Who’s the manager always looking to promote one of their team players over themselves? Who’s the director always looking for the next innovation to try out? By knowing the players in the meetings that you’re scheduling, you can predict to a high level of certainty how that meeting will play out, assuming that you structure it correctly, anticipate objections and concerns, and facilitate the shit out of that thing!
The Meeting’s Not the Meeting
Regardless of how well you know the players, you have to realize that the meeting isn’t actually the meeting. The meeting is the opportunity for everyone to get together and air their grievances — kind of like Festivus. But the real meeting happens outside the “meeting”. Any time you just get a large group of people into a room, you’re going to have chaos — sometimes it’s controlled chaos, but it’s chaos nonetheless. This is why we meet with every stakeholder who’s going to influence the decision before the meeting. This is where we do the heavy lifting, where we figure out what it’s going to take to move the person to a “yes” and to eke out all of the objections that they might be holding onto, waiting for the right opportunity to cast their die on the table. If we fail to meet ahead of the “meeting” we’re doing nothing but throwing our direction to chance. We don’t do that — as Product Managers we play the role of the House, and the House only gambles when they know they’re going to come out ahead.
Drive to Decision
It’s so easy to just give in when a meeting starts to go sideways — when you have your CEO staring at his phone, and your Director of Marketing writing emails to their subordinates, and your VP of Sales reviewing their weekly numbers. So don’t let them. Demonstrate to them that you value their time, and require that they value theirs. Focus the meeting, focus the discussion, pull people out of their laptops (by force, if necessary), but drive to a decision. Make outrageous statements, make a declaration that a decision has already been made, don’t show more than two options — one if at all possible. Structure your entire meeting, from beginning to end, around making a decision that matters and take the time after that meeting to confirm it and to plan the next steps. We had a rule at one company I worked at that if you walked out of the meeting, you walked out of the decision — a rule that our CEO tested once, probably inadvertently. Needless to say, he never left our meetings early again. Make rules, stick to them. Make an agenda, stick to it. Take only as long as you need to come to a decision — if everyone agrees in the first 5 minutes, that’s 55 minutes they have to go do real work.
If you can demonstrate to others that you’re dedicated to respecting them, respecting their time, and making actionable decisions, they’ll naturally follow. If you let them run roughshod over you every chance they get, they’ll happily do that as well. The decision is yours to make, so do the right thing.
To be subjective, or to be objective, that is the question, and the best product managers already know the correct answer is “both.”
As product managers, we constantly face situations where the unknowns outnumber the knowns that we can rely on. It’s our job to drive out that uncertainty and ensure that both people and efforts align toward a common objective. Sometimes these discussions flow smoothly, as the goalposts that we set can be quickly and easily agreed upon – things like providing a quality user experience, solving valuable problems for our customers and our market, and introducing competitively differentiating capabilities are hardly controversial.
What does become controversial, however, is how we go about those things as a team, what exactly we should do, and who we should be building those products for. And when those discussions come up, it’s inevitable that everyone at the table will have different ideas about what those things are – and, unfortunately, the vast majority of those ideas will not be based on hard data. Hence why we, as Product Managers, need to make it our business to ensure that we’re bringing data to the table as we represent and advocate for our customers and our market in those conversations; to do so, we must provide stakeholders with the right mix of qualitative insight and quantitative data that will not only help win them over to our preferred course of action, but also minimize the risk of later changes of course.
Great product managers use both qualitative and quantitative data to make the right decisions.
The common wisdom in the Product Management world is that more transparency is always better — transparency into the planning process, the roadmap, the product strategy, prioritization, design, development, etc. And while transparency is certainly important, generally speaking, it can also have its dark side, especially when the culture in which you are being transparent doesn’t understand or respect the goals of transparency, and subverts your attempts to provide clarity and understanding in order to further their own agendas.
Rarely, however, is transparency itself to blame for these problems — rather, it’s transparency combined with other dysfunctional behavior, or transparency that’s not well thought-through or explained in a way that others understand why things are open and available. When these behaviors or cultures converge on a transparent process, the outcomes aren’t always pretty. Here are three examples of transparency that results in incongruous outcomes…