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.

Track maintenance car image from Wikipedia.

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.