In part 3, we will look at the erratic driver product manager. In part 1 of this series, we looked at the underminer. In part 2 we looked at the dinosaur product manager.

The erratic driver is a leader who either can’t make up their mind, can’t stick to a plan, or both. This disrupts the work of others, hurts productivity, and threatens schedules and team commitments. Team members may work on items that are subsequently rejected, or they may spend precious time waiting for decisions that aren’t forthcoming instead of producing key work items.

There are usually two types of erratic driver product managers:

1. A visionary who thinks ahead and sometimes struggles to stay in the present, consistently disrupting the team with new ideas
2. A manager who lacks confidence in their own decisions as well as others

The first erratic driver tends to be easier to deal with, but both can do a lot of damage due to their behavior. The first place they do damage to is the product itself. When they change their minds a lot, the vision and value proposition of the product gets muddied and lost.

The second area of damage is to productivity, and scheduling goals. Since they change their minds and second guess the work and commitments teams have agreed to take on, there is a lot of duplicate effort, wasted effort, and plain old waiting around for someone to make up their mind.

On one team I worked on, the head of product had a reputation of approaching software development the way 5 year old children approach soccer (or football depending on your locale.) They start off more or less together, and then things quickly fall apart. Sometimes they chase the ball, sometimes they chase each other, sometimes they move the ball down the field, sometimes they try to score, or defend. Sometimes they even try to score on themselves. Many times, the ball is forgotten by all the players when something interesting and shiny appears to distract them. It’s entertaining to watch, but not very effective at reaching goals.

The head of product oversaw several products and services, and fortunately, each of the product managers that reported to him were shippers. They worked hard to get great products out the door consistently and effectively. Each product manager had a good balance of domain knowledge, market knowledge and technical skills. That meant that the teams they worked with were productive and effective and were able to get things done, but when the product lead changed their mind, they would be undermined and foiled. This company was well funded and had a great pool of talent, but there are always limits on people, resources and logistics. However, depending on the whimsy or stress felt by the head of product, priorities would shift. Needed resources and people would be pulled off of one project and assigned to another. Marketing and sales campaigns would be put on hold, with others suddenly requiring strategy and copy. Progress would start on the new initiatives, stop on others, and productivity would shift to other groups projects. Repeat this on a cycle of 2-5 weeks, and you should be able to predict the outcome.

None of the products or services were ready at the times they needed to be. That meant sales suffered, and the credibility of the company suffered with not only existing customers, but also with potential customers. The company eventually gave up their technical leadership credibility in the market as well. They were surpassed by competitors who were better at managing schedules and were able to honor their public commitments.

A bit of investigation revealed that the head of product lacked confidence in their ability to make decisions, and was easily influenced by powerful stakeholders. In fact, they would misinterpret senior management brainstorming ideas or even misinterpret their moods as directives for the project. That meant that decisions were delayed, overdue, and changed frequently. Not only were the technical teams impacted, but marketing and third party commitments with PR and tradeshow vendors were changed. The products would be late, 3rd parties would charge for work that wasn’t required, and everyone suffered. This problem could have been dealt with if the product manager had trusted their teams and listened to their advice, admonitions and warnings, but they didn’t have confidence in them either.

I worked as a project manager on one of their products, and we were able to create a visible process so that when the head of product changed their mind, everyone knew about it. In the past, information would trickle out to different team members at different times, causing a lot of confusion and needless effort. I also asked them to help me create some mechanisms to deal with their erratic behavior. (I was a bit more diplomatic in how I addressed it than written here.) I then set up frequent meetings with senior members of the team to provide the head of product to discuss concerns, and to shield the team from freakouts. We also created a process on decision making, and asked that any change in direction be driven by real evidence. We also assured the head of product that any success or failure was shared by the team, not one individual, and when required, one of us would step up and take responsibility for a tough decision when the head of product felt paralyzed.

This helped a tremendous amount. Unfortunately, since they were coming from a place of fear rather than fast paced visionary thinking, they did a lot to undo the process, even though they saw the value in it. We were constantly undermined, and our senior team members spent a lot of time trying to keep the team protected from freakouts and churn, reviewing decisions and work products over and over with the head of product, and dealing with other team members who were pulled off track. In spite of some success on our project (our project was the only one that shipped on time and on budget that quarter), the head of product’s track record was so poor across their entire portfolio, they were eventually asked to leave the company.

The erratic driver:

• changes their mind frequently
• overthinks options to solve problems or what to develop next
• delays decisions on tough problems as long as possible
• second guesses and over-rides prior decisions
• interrupts team members, and sometimes the entire team, pulling people off task by having discussions, or making pronouncements about changing direction
• disrupts team alignment with regards to product development
• has trouble differentiating between short term vs. long term goals and ideas
• confuses the team about timelines and priorities either due to indecision, or by getting excited about something new
• is unhappy with developed features
• wants the team to move faster (to keep up with their ideas)

How do you deal with an erratic driver?

• make decisions visible so everyone knows what is going on
• make project management visible so that deviations are spotted quickly
• use a process to manage work to reduce confusion about priorities
• provide realistic costs to changing a feature, or direction – when faced with the potential impact of change to productivity and schedules, that helps determine if the change is needed now, or is ok to do later
• make sure there is a product roadmap prior to signing on to a project
• use roadmaps to manage development priorities and planning to keep things focused and on track
• create a brainstorming roadmap to use with senior team members only for whimsical ideas or long term ideas with a process for promoting these ideas to the formal roadmap(s)
• provide a safe place for brainstorming and letting off steam, instead of randomly interrupting team members
• utilize user experience techniques to help remind us to focus effort towards customers, not by the turmoil in the leader’s mind

On another team, I worked with a visionary erratic driver. (Side note, many, if not most entrepreneurs are erratic drivers at least at some point. Their brains work quickly, they like to entertain a lot of ideas, and they are thinking longer term than where the team is currently at. It’s easy for them to be thinking years in advance, and they get frustrated when labour intensive efforts like software development can’t keep up with them. Learning how to deal with visionary erratic drivers is an important skill for product managers.)

This product manager had a rare gift of being able to identify unaddressed gaps in the market, and quickly come up with technology solutions to match. Once they put their mind to it, they could come up with very polished pitches to stakeholders and get people on board who shared their vision. They could almost effortlessly attract funding and willing team members to work with them. Unfortunately, once the team was settled in and getting productive, they would constantly brainstorm and share ideas for features that would be implemented down the road. They would get excited about these feature ideas, and the team would feel pressure to implement those brainstorm ideas now, instead of when they were intended to be developed. That meant that the evolving product was incoherent, and short-term priorities were often missed.

The product manager also spent a lot of time studying new technology, and would second guess prior technology choices when something new and shiny appeared. We were using JavaScript frameworks, which tend to go in and out of fashion faster than designer jeans. That meant the team was at times bombarded with new framework information, which pulled valuable efforts away from current development. Some team members worked on items agreed to and specified on the roadmap, while others strayed due to confusion and individual direction. As a result, demo days were dreaded because the product manager was always unhappy. “Why did you work on that?” “That isn’t what I wanted at all.” and “I didn’t mean for you to work on that now. were common.

The team was misaligned and frustrated, productivity suffered, and the end result was a product that was disjointed and difficult to use. I sat down with the manager and discussed their behavior and the corresponding team reactions, and asked if we could set up a system to help.

Once I carefully and as non-threateningly as possible went over the manager’s behavior, I suggested some process tweaks. I asked them to work with me on setting up a process for brainstorming whimsical or half baked ideas. The idea was to disrupt the team less, and to have a rule in place to determine whether the team members needed to be interrupted.

To help with team alignment and erratic decisions and work products being developed that weren’t focused, we formalized a product roadmap, with three sections listing efforts and associated priorities:

1. Current development
2. Near-term development
3. Future development

Next, to take technology decision churn out of the picture, we pulled technology out of the product roadmap, aside from high level goals, such as supporting mobile devices and using a modern framework with great user experience. We then tasked the technical team with making the decisions about technology, and helped them create a technology roadmap. The product manager could have input and was consulted, but the technical team were ultimately responsible for picking the right combination of technology to meet product goals.

To make the product manager aware of the cost of changing their mind, we worked with the project management process to make sure work was visible, and effort was accounted for. It was important for them to understand that whenever they change their mind, team members lose productivity and need to refocus before becoming productive again. Also, it was important that they understood the efforts required for new development, and what the trade offs were. If you change now, what are you going to give up? In addition to raw efforts that are required, team members also need to spend some time archiving their current work so it can be picked up later on, researching and getting up to speed on the new work tasks, and then getting productive again.

To help align customer needs with product development, we worked on incorporating field data into the process, so we set up formal weekly meetings with marketing and sales and PR. I helped the UX and graphics design team to come up with a review process for the product manager so they could approve designs prior to implementing them. We also created design documents that outlined style specifications for products such as fonts, colors, logos and other important issues. I then worked with the UX and design team to help them communicate their designs more clearly, and to add their needs and goals to the technical roadmap.

Finally, we set up a formal process for sheltering the team from getting disrupted by new ideas, creativity flashes and self doubt. We started with a weekly meeting among senior team members for brainstorming and sharing half baked ideas. From that, I created a spreadsheet where we would record the ideas the product manager wanted to keep, and we had a promotion rule. Ideas that were really far out were at the bottom of the list. If they were talked about again, they started to move up the list. If they were mentioned frequently enough, I would ask if they should be promoted to long term roadmap commitments. Often, the product manager would say no, but sometimes they would want the idea promoted and added to the near term. Any new changes during development were spelled out with associated effort and cost. That would also help determine if ideas for features or change were serious and needed to be acted on immediately or in the short term. We would review the list periodically, and some ideas from the bottom of the list would be removed.

Visionaries have hunches, and sometimes they need to bypass the process because they have good reason. That meant the product manager also had veto power, since they were ultimately in charge of the product. If they felt very strongly, they could stop work and guide the team in a new direction if they felt strongly enough. At first, they wanted to use this more often if they felt they weren’t getting their way, but once we would pull up the roadmap, discuss current commitments, and associated costs of change, they would back down. Sometimes though, they had a gut feel and felt strongly enough to change and deal with the associated costs. They were almost always right about these changes.

The product manager was uncomfortable with the process at first, but I asked them to respect it for one two week sprint, and see what they thought. After the first sprint demo, they were much happier, but were still concerned about delivering the software when they needed to in 8 weeks time. It wasn’t without hiccups and backsliding and issues. (I would find out about the product manager varying from the process and confront them about it, and we would adjust. Either they would adjust their behavior, or we would tweak the process.) However, we delivered in the time frame that was required, and because of the process, we had a much more focused, usable product that the product manager was happy with. The team met their commitments, and the process was formalized further and later coached and enforced by the product manager instead of me. Surprisingly, the UX and design team were the happiest with the outcomes – they got constructive criticism early, and had far less re-work after sprint demos.

Erratic drivers are incredibly common in visionary roles, and it’s important to learn how to work with them. Visionaries are able to marshal both the required resources and technology together to create new products. They have a rare gift. The downside is that they think quickly and are creative, and when they get excited about new things, they can infect others with that excitement. If it isn’t managed properly, passion and excitement can become distracting and destructive. Many company founders are visionaries, and early stage software startups are full of erratic drivers. While they are most common in new ventures, visionaries with erratic driver tendencies are found in any kind of organization. Good processes and solid communication are important to work on when you encounter the behavior. Some of you who are reading this might have erratic driver tendencies yourselves. If you are a product manager who is an erratic driver, start creating your own process to keep your activities focused on shipping great software, and safeguard against needlessly distracting or holding up work when waffling on decisions. If you ask for help from key team members you trust, they will step up and help keep you honest.

Note: I first wrote about the erratic driver management pattern in this article for Agile Connection.

In part 1 of this series, we looked at the underminer. In part 2 we will look at the dinosaur product manager.

A dinosaur is a product manager who is out of date, and they obstinately refuse to consider anything that is current. They have their model of the world, and they refuse to learn anything new. They might be out of date with any or all of the following: the market, competing products, their customer’s current expectations, pricing, monetization models, marketing and sales approaches, current technology and design trends.

Tyrannosaurus image from Wikipedia.

Of all the product management anti-patterns, the dinosaur is the one that I find to be one of the most painful to witness. As a technical product manager who works with new and sometimes cutting edge technology, I run into the dinosaur quite often. It’s painful to observe because you see all these people working so hard, and the team inertia is moving in a direction, yet one person is getting in the way. It sucks the life out of teams, and it’s also one of the most difficult behaviors to deal with.

Dinosaurs are people who for whatever reason have stopped learning. They have a specific approach and they are frozen there. Often dinosaurs are more experienced people who are fatigued with learning new technology, or they might be jaded after too many campaigns. Software is a tough, demanding business.

I get the learning fatigue. As you have more experience and have learned a lot, it is tiring to learn yet another web framework, a new set of productivity tools and yet another design paradigm. Right now I am learning some new approaches to mobile development, and a whole new templating engine for web applications using responsive design. It isn’t as much fun to learn as when I was new in the industry, and I have to fit that in between engagements and deliverables.

However, I have also met dinosaurs who had very little experience, but they have still chosen an approach and refuse to update their thinking.

Recently, two executives asked me to help them with a difficult problem at their company. They were creating a new product to expand their product line and steal market share from an emerging, lucrative market. Their existing customer base was maturing, and there were strong economic forces at play that they felt threatened current revenue streams. They didn’t want to get caught when an inevitable decline hit the market, so they were looking seriously at other sources of revenue that better fit emerging market conditions. They implemented a “20% time” for technical teams to spend time coming up with product ideas, held facilitated brainstorming workshops, and engaged heavily with their enthusiastic supportive customers and trusted industry contacts.

As usual, the problem they posed to me and the real problem were two different, yet related things. They didn’t say anything about the VP of Product Management, other than mentioning them in passing. In fact, they said the problem was an alignment issue between the experienced people in the company, and a young engineering team. The execs gave me the impression that the engineering team on this project were the problem here – they weren’t respecting the more experienced people in the company. But the execs said they would let me figure out what the problem was. All they wanted was a great minimally viable product they could start introducing to the market.

As I met with more people in the company, alarm bells started to go off. I didn’t meet the VP of Product, and it felt like people wanted to shut them out. Any mention of the VP of Product was met with a silent tension. When I met with the technical team, they seemed depressed and were checked out. They sauntered into the meeting with me, and most of them were late. The product owner was the last to arrive, and while she was pleasant and polite, she spent most of her time with her face buried in their smartphone. The lead engineer on the project took me through an abbreviated walkthrough of their prototype, and aside from some UX and design issues and some unfinished parts here and there, it looked solid. In fact, the fit with the market was obvious, and the technology had a lot of potential. I found it exciting, but the rest of the team were sombre looking and weren’t engaged. I started asking clarifying questions and they slowly started to wake up.

They had stumbled on a very difficult navigation problem, and asked if I had any ideas from my UX experience. I suggested looking at game design, because this sort of problem is well addressed in video games, but often poorly addressed in enterprise applications. After a couple of shocked moments, engagement turned to excitement. We brainstormed, some team members started researching compatible game engines, and looked for examples on the web. At the end of the hour, the team asked if they could extend the meeting further, and most of them were able to stay in the room with me. The frenetic pace of excited brainstorming continued for another 45 minutes, and then we realized we were all tired. The lead engineer wrapped up the meeting, and the product owner took me aside and told me it had been the best meeting they had ever had for that product. In fact, in the two years she had been in the company, it was the best technical meeting she had attended.

Next up was a meeting with the VP of Product. They had been in the industry since the early 1990s, and had seen a lot of past success. You can guess what happened next.

The VP of Product spent the first 15 minutes of the meeting name dropping and telling me all about their accomplishments. When they asked me a question, they interrupted before I could finish answering and began to berate me. This continued on for the remainder of the meeting – any time I spoke I was interrupted and ridiculed. When I changed tack and asked for a demo of their ideas, they showed me a PowerPoint slide deck with an outdated theme, and the product screen examples they had created looked straight out of the 1990s. With a bit of probing I found that they didn’t just treat me with derision and aggression, they were that way with just about everyone. It was obvious that a dinosaur was derailing an important product effort and potential new revenue stream.

I advised the executives of what the problem was, and you guessed it, they already knew. Instead of dealing with the issue, they were trying everything else but having a difficult conversation with the VP. The VP still had a lot to offer the company, but not in product management. They had hoped that a consultant would have some sort of magical solution idea that would get them off the hook, and would somehow get the VP on board.

In two other recent experiences, I have met inexperienced dinosaurs. Both were startup CEOs who had product ideas, and managed to attract friends and family investment to hire technical teams. They didn’t have product managers, and had decided they were going to play that role in their company to save money. They had immediately latched onto the first technology ideas that were presented to them, and refused to learn anything else. Unfortunately, in both cases, they had outsourced development to teams that were inexperienced and placated customers, and made complex, risky development efforts sound simple, quick to implement and inexpensive. Both of them approached me because they had spent a lot of money on solutions that didn’t make it to market.

They were afraid. Yet, in the face of losing their businesses, they refused to listen to contrary advice from people with experience and track records of shipping software. They clung onto their initial ideas and conclusions they had made a year or two ago, and refused to budge. This was likely a controlling dysfunction borne of easy wealth and the arrogance that can come with it. They were intimidated by people who understood technical things, even though they had hired those people precisely because they had technical expertise.

The dinosaur product manager:

• Believes in “one true way” approaches to marketing, sales, products and process. (This tends to coincide with their way.)
• Scoffs at new technology or pricing models
• Scoffs at design trends
• Makes fun of consumers who buy products or services they consider to be fads
• Talks more about “the old days” than being productive in the present
• Dismisses ideas that aren’t their own
• Makes fun of new technology environments
• Equates every new design, marketing or technology paradigm with one from the past
• Blocks efforts to update technology or architecture, even when when it’s needed
• Underestimate the risks, complexities and efforts of their solution ideas
• Reacts strongly to people with more technical knowledge, and especially more recent knowledge and skills than they have. They may be antagonistic, belligerent, use ad hominem attacks, or they may be passive aggressive and simply undermine them.

How do you deal with a dinosaur?

One of the most difficult things when dealing with experienced dinosaurs is that they are often right about a lot of things. They often express their ideas poorly, so it is easy to dismiss everything they say. Sometimes what seems like scoffing and denigrating behavior is simply an attitude problem borne out of harsh experience. The trick is to figure out when they are blustering due to fear, obstinance or unwillingness to change or if they are complaining about a valid issue. This requires patience and trial and error.

• Talk to the person, and ask them what is going on, and point out how their behavior can be damaging and misconstrued if it is well-intended. Ask them to work with you and help the team move towards something successful, even if it means compromising.
• Training and knowledge gaps are common, particularly with more experienced people. See if you can set up training or online materials to help them get confidence in something new and threatening.
• Set up a safe place for ranting and complaining about new models, even if they seem to be consumer or process fads.
• Play to their strengths and experience, and divide labor so that they have input and crucial parts to play in direction, but others are in charge of revenue models, marketing schemes, technology and look & feel.
• Have them do competitor analysis, and have them perform user experience heuristic evaluations and pricing research of competing products.
• Make sure they engage with customers who have differing views from their views and preferences
• Take technology, design and other decisions out of the conversation, and have them provide constructive feedback in a neutral way. Their concerns may be valid, and if so, they will be happy to abstract them and present them differently. If they are not valid, they probably won’t do anything but bluster.
• Let them win at times. A lost battle on a non-core issue is better than losing the war.
• Be consistent and patient. It can take a while for them to win respect of other people with new and different ideas, and to get on board with new ideas and approaches.

If the person is coming from a place of fear, most of the above points won’t really help. In that case it will likely require some repositioning of their work and power. Following a process that uses team-based decisions and approaches can really help in this case. In many of these situations, a hardline approach is necessary, because a team member who obstructs can kill productivity and hijack business initiatives of the entire company.

Ask the champion of the new approach to present their approach to the group.

Next, hear out any criticisms of the approach, because there may be valid points. A dissenting opinion presented constructively is incredibly valuable.

Then make it clear, once the decision has been made, that the decision must be supported by the team, and anyone undermining the position will be asked to leave the team. (Also make it clear that undermining behavior will be monitored and will not be tolerated.) Often people who appear to be on board with the decision will undermine by amplifying problems and use that as evidence to criticize the decision. Peter Block calls this “resistance through compliance” and it is insidious and dangerous in organizations.

Here are two dinosaur examples with different outcomes.

An organization had grown from a two-person startup to a thriving company with close to 100 employees. They had created an MVP, tested it in the market and attracted a lot of initial investment. Trouble was, the market changed drastically and suddenly. The product manager became a dinosaur, slavishly sticking to their initial idea. Their product concept and understanding of the market had worked for over a decade, but they couldn’t get on board with the new market reality. There were also a lot of retirements and younger people moving in to replace their existing customers. That meant that during purchasing decisions, younger people (who use a lot of apps on smartphones and are more fashion conscious) were brought in to provide opinions. A middle aged CTO might have a social media marketing person sitting in meetings analyzing the offering from their perspective. Their expectations were much different, but were taken very seriously.

The dinosaur product manager became more entrenched and combative, and taking any criticism (real or imagined) quite badly and personally. They became more isolated, and the rest of the team were realizing they needed some big changes. The dinosaur also hated any usability issues and was quite scoffing of UX practices. “Our customers don’t need something that is usable…” was often their response.

One Monday morning, the product manager came into work a changed man. We didn’t know it at the time, but the CEO, the CTO and a major investor/advisor had taken him out to dinner that Friday night. They asked if he wanted to continue being obstructionist, or if he wanted to work with everyone else to solve the problem? After all, the company and a lot of investor dollars were at stake, and his behavior wasn’t going to help the team. They had decided early on that the core members of the team would agree unanimously on decisions moving forward. To get unanimity meant that if a person was a lone dissenter, they would be asked to leave. The manager told me later on that the discussion hit him really hard, and he spent the weekend mulling over options.

He moved quickly once he made a decision. He immersed himself in new pricing models, spent hours with potential customers doing field research, and hired a UX expert and visual designer to help them create a new product. The results were dramatic. They turned around a failing product into a big seller, and they sold the company to a larger player in the industry for a tidy sum.

In another situation at a large, established company, a dinosaur product manager was stuck in her ways when it came to marketing and sales. That was one thing, but she also refused to allow the technical team to pay off technical debt through refactoring, and would rarely allow them to update tools and infrastructure. She was also, bafflingly, incredibly stubborn about the look and feel of their e-commerce site. It was six years old and really showing its age. Any UX improvement or change, no matter how small, was met with enormous resistance.

This was flat organization with an open environment, and anyone could suggest ideas for improvements or new revenue streams, and field reports were frequent. No matter what anyone said, she would argue against anything she saw as a threat. She would often literally frighten away younger employees who had good ideas based on observations.

Senior managers tried to work around her, then ordered her to help implement an add-on feature to help increase sales. She appeared to be enthusiastic when they were around, and made all the right noises, but she was resisting through compliance.

She didn’t understand SaaS style pricing models, and her views of pricing, marketing and sales were hopelessly out of date. The projected numbers were staggering, but every meeting she was involved with was a painful fight. A marketing designer described a particularly painful “pixel by pixel” review meeting of pre-release marketing designs that took hours. Everything seemed to be painful, took way too long, and people asked to leave the project in droves.

Since the team was moving one way with executive directives, and that didn’t suit her outdated ideas, she actually hijacked efforts to secretly develop the solution the way she wanted. Part of the team at any given time were also working on her competing ideas. We found out because there was an anonymous tip about this from an abused employee to a politically powerful person. Her revenue model was so outdated and wrong, the legal department got involved and sent out a cease and desist warning internally. She continued in her undermining and obstructionist behavior, so she was let go. After she was gone, the teams moved quickly, and after 9 months of fighting, implemented the new feature with a completely new redesign in 3 months.

Avoid Dinosaur Behavior

It’s easy to fall behind in a massive industry that is constantly changing. It will happen to all of us eventually. The important thing to remember is that no one knows it all, and it’s ok to say: “I don’t know.” Very few people will look down on you for not knowing something, and if they do, they aren’t worth paying attention to anyway. Here are some tips:

• Stay current by reading industry news, a little bit each day
• Talk to your customers and ask them about problems that haven’t been solved yet, and about other applications they like to use
• Study User Experience and keep abreast of developments in that field
• Aim to be a lifelong learner
• Take online training courses. There are a lot of free and inexpensive courses out there that allow you to work at your own pace
• Attend conferences, workshops and local events in your community
• Delegate to people who are more current than you are
• Check your attitude – are you resisting change, or is your discomfort due to a deeper, important issue that needs to be addressed?

Any new revenue generating, marketing, design or technical change will involve problems and stumbling blocks. There will be fear of the unknown, resistance to change, and there should also be healthy dissent. In fact, any decision without some healthy dissent will likely be a poor one. The trick is to not let the dinosaurs hijack decisions or turn teams away from new initiatives just because they stopped learning and don’t want to help anymore.

In part 1 of this series, we will look at the undermining product manager. The underminer is a manager who says one thing to your face, and does the opposite behind your back. Underminers may also sow seeds of doubt about your competence to others on the team.

Disney’s “The Incredibles” image from Wikipedia.

When product management goes well, it has a big impact on the success of a project. Product managers help get alignment between technical teams, business teams, and end users. They can help teams deliver a polished product/service instead of a “bucket of features” that are packaged together at the end of a release. Great product managers can help teams build the right product, at the right time, at the right price.

But poor product management can cause a lot of problems. Instead of having a positive impact, they can detract. When product managers persist with unhealthy behavior, they can derail projects, demoralize team members and destroy productivity.

Recently, a colleague approached me because they were having misgivings about a new product manager that had joined the team. The team saw the value in the role, and had hired their first product manager. After the initial adjustment of adding a new team member, they were expecting some positive outcomes, but instead, technical leadership were very concerned. They asked me if the behavior they were seeing was normal for a product manager. What they described might be normal, but it was certainly dysfunctional. I was reminded of an article I wrote a few years ago on management anti-patterns so I decided to revisit that content but with a product management slant.

An underminer is someone who says one thing to your face, but does something else (often the opposite) when you aren’t around. Underminers might be motivated by their own agenda and wish to circumvent current plans and work items. If they want something else worked on other than the current work items, they will go from person to person until they find someone who will agree with them. People will often quietly work on items that aren’t being accounted for at the request of an undermining product manager, which skews team efforts.

The undermining product manager:

• Doesn’t respect estimates and timelines
• Doesn’t respect team decisions, particularly with regards to product direction, milestones and priorities
• Gossips about team members when they aren’t around
• Second guesses decisions behind other team member’s backs
• Goes from team member to team member until they find the answer they want
• Agrees with you or the group, then does something contrary to the shared decision when they think no one is looking
• Constantly blames other people, other groups (and you when you aren’t around) for any fault, real or imagined
• Seeks out allies to work on items secretly, and to also engage in all of the above behavior

Underminers are destructive because they ruin productivity, create distrust among team members, and weaken the credibility of the people they disagree with.

In a product management role, they are especially destructive because they ruin team alignment and shared goals, which is an important aspect of team success. Sure, once in a while you have to make an unpopular decision or work with some people in private to get things done, but that work still needs to be transparent and working towards shipping the product. In fact, many times a product manager makes an unpopular decision because it helps with goal alignment and ensures the team stays on track. An underminer doesn’t share the goal of shipping software in the manner the team has agreed to do already. The resulting toxicity caused by an underminer also kills individuals’ intrinsic motivation to work on a project, which is a primary driver for our work.

Underminers are motivated in different ways. Sometimes product managers are directed by powerful stakeholders who feel they aren’t getting their way, and that the technical team aren’t listening to them. Instead of dealing with this head on, they prefer to have a plant or someone on the inside who is doing their bidding secretly. In other situations, a product manager may read (or misread) the political tensions in an organization and feels that if they show some initiative and push the team in a different direction, that will lead to their own success and a promotion or similar reward. Still others are in a position that is beyond their expertise, and they are desperately trying to find some control, or deflect their lack of skill by putting focus on others.

Underminers are horribly toxic for teams (and companies) because they are good at marketing themselves to powerful people in the organization, and are quick to take credit when something goes well. Once they have built up enough credibility, they also shift blame onto other team members who can become vulnerable politically through no fault of their own. This means that the people with the most power are the last to see through the undermining behavior. By then, the damage has already been done. They also cost the team a lot of extra money and lost productivity in frustration and a lack of alignment. A project will need to draw on more reserves than initially budgeted due to their behavior, and many won’t survive.

How do you deal with an underminer?

• Make your process and decisions visible to all stakeholders. When something subversive is going on, it should be obvious.
• Utilize project management tools for visibility on individual’s work. Daily standup formats are good for this. If people are working on something other than what they have agreed to work on, it should be visible quickly.
• Ensure team members approach the rest of the team if someone asks them to do something off the record to get their approval.
• Make people accountable for not working on what the team has agreed on. Often a little public Q&A is enough to get people to realize what they are doing is inappropriate. If it persists, deal with it as an HR matter.
• Do not tolerate gossip, blaming or calling people’s work or decisions into question. Foster a culture where people stick up for each other. When undermining starts, it should be obviously different from the norm and discouraged.
• Bring business and other stakeholders into the process so they feel included, and address their concerns in case they feel the need to subvert. When they do, deal with the issue head on and ask to work on a solution other than someone who will cost the team more money and threaten the success of a project.
• When you discover an underminer who is unrepentant, fire them when you have enough cause.

The underminer is so deadly, not only will a team miss their shipping targets and go over budget, the team will lose confidence in each other, and the organization. I’ve seen teams start to falter and people start to spend their time looking for a new job after two weeks of an undermining manager appearing on the scene. They are nasty, and it’s important to screen for this sort of thing when hiring.

It’s also important to examine our own work and habits as product managers on a team. While we may not intend to undermine, we may exhibit these behaviors from time to time. It’s a good idea to have personal retrospectives periodically, and when we catch ourselves exhibiting underminer habits to take immediate action to correct them. If we are under stress or feeling frustrated with the progress of the team, we can easily fall into this sort of behavior. All it does is detract, so we need to police ourselves whenever we are tempted.