I was called into a meeting with a team here in the office a couple weeks ago because they told me they had a “question” about the estimations that they were doing. As we started talking, it became immediately apparent what the problem was, they were getting into arguments about whether their estimates were “too big!” Apparently, someone had told them that they “couldn’t” have any stories that were above a certain value, or at least that’s how they took the directions they were given. I stopped them for a minute and had a quick discussion about the reasons why we estimate stories, and why it’s incredibly important for the story points to reflect the size the team thinks the work is, regardless of what other people “want” them to do. I walked away to leave them to their work, and was entirely unsurprised when I saw some 20-pointers land on the backlog. Far too many teams suffer from some malady similar to that of this team — they forget why we’re asking them to estimate, so they start to engage in anti-patterns that undercut the very purpose for which estimation exists. In a follow-up conversation with another member of our Product Team, I started to think about how to describe Story Points as something other than “estimates” — and I came up with the idea of them as a “signalling tool”…
There are a great many company cultures in the world that go out of their way to avoid conflict of any kind. And, while the intent is good — nobody wants to work in a combative workplace — the common practice of lumping all conflict together into a single bucket and trying to toss it out the window winds up being counterproductive in many ways. You see, conflict isn’t always a bad thing; certain types of conflict actually make us better at what we do. When we engage in constructive conflict, we hone our ideas, challenge our own assumptions and biases, and push others to do the same. In an environment completely absent all conflict, we might as well all just be “yes men” and simply rubber-stamp every idea that comes around. Successful businesses are not built that way. Here are some things to think about when it comes to engaging in constructive conflict.
Don’t Reward Behavior You Don’t Want!
One of the more common challenges that growing companies face is balancing the needs and goals of the company with the needs and goals of its employees. And, unfortunately, all too often decisions are made with a business perspective that don’t take into account the potential effects on the personnel side of the equation. The simple fact is, people will do what we incent them to do and what we reward them for far more often than they will do what we want them to do, if there is any misalignment between the two. This applies across the business — from high-level executives to entry-level employees, and even out to our products — how we position, package, and price our products can often drastically affect how people will perceive and use the product.
While people always seem to nod their heads when you tell them this, it’s rather insane to realize just how often we create competition between these two things. Here are some things to consider when you’re trying to figure out how to get people to do what you want, or why they’re not doing what you expected.
The Dangerous Myth of “Consensus”
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…
Leading Through Influence: Limiting Choices
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!
Clarity Drives Success
I’m often asked what I think makes a successful Product Manager, and after giving it some thought, I’ve narrowed it down to one key factor: Clarity. When applied to our daily jobs, this can mean any number of things: clarity of communication, clarity of purpose, driving discussions to clarity, or even insisting on clarity from others. But to me, clarity is perhaps the number one indicator of whether or not something that you’re doing is going to be successful. After all, if it’s not clear why, how, or for whom you’re doing something, can you actually measure your success or failure? Some companies thrive on a culture that lacks clarity — perhaps because a lack of clarity often goes hand-in-hand with a lack of responsibility and accountability.
Let’s look at some ways that clarity drives us to be successful in everything that we do…
Leading Through Influence: Driving to a Decision
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.