Product Management by Committee: A Recipe for Disaster

Introduction

It sounds like a really attractive proposition -- let’s all get together and decide, as a team, where we want the product to go! It’s a deceptively simple concept that nearly always results in the safest, least innovative path forward, and dooms companies who embrace such a product planning approach to a slow, agonizing death as the market accelerates past them. Nobody wants to be the pace car in a race; you want to be in the front of the pack, leading the way. And nobody ever leads the pack by creating a product by committee or consensus.

Recognizing the “Product by Committee” Culture

While many organizations are very open about their committee-driven approach to Product Management, others try to hide the fact behind a veneer of traditional product approaches. But that doesn’t mean that they’re not making the same mistakes behind closed doors.One of the most obvious indicators that a company is stuck in a committee- or consensus-driven approach is the existence of lengthy meetings about product and strategy that end without any clear decisions or actions to be taken to move things forward. We’ve all been in these meetings at one point, but when they are the rule rather than the exception, there’s a good chance that what the executive team is actually seeking is consensus, not action. These long-running meetings wear down those who resist or want to advocate for new directions, until the end result winds up being the least-objectionable direction for the most people involved. Innovation has never happened by wearing people down until they just give up and follow the pack.Another common indicator is an unwillingness or inability to actually commit resources to projects until “everyone” agrees that the project is worth doing. You’ll see this when project plans have to go through multiple levels of “approval” or “review” before anyone can start working on the fundamental precedents to success. This generally results in delays in getting started, putting off the necessary research, design, and planning efforts until it’s too late to do them right -- which results in lower quality, longer time to market, or even an over-allocation of resources to speed up development time.

A direct corollary to the above two points is an outcome-based indicator -- when a project takes longer than expected, is more complicated and involved, or even just outright fails, a committee-oriented company is more interested in assigning blame and pointing fingers than they are about learning from what happened and improving for the future. This kind of behavior feeds into the vicious cycle of both an inability to commit and a disinterest in investing in the kind of precedent work needed for true product success. Modern, agile companies realize that failure is not an end, but only a beginning -- if we always succeed, then we must be taking the safest and least innovative steps possible. And if we punish those who “fail” rather than engaging with them to learn how to be better, we instill in the entire organization the same lack of commitment and fear of risk that started in the executive board room. People who are afraid to fail are afraid to try -- they will do just the bare minimum, so their necks don’t stick out far enough to get chopped off.Another outcome-based indicator is the end result of all three factors above -- every step forward in the product or company is simply evolutionary and not revolutionary. New features aren’t pushing the market, they’re complementing the existing capabilities of the platform. Redesign, refactoring, and re-architecting doesn’t test the boundaries of what you can do with modern technology; rather, it focuses on how you can take what exists and just make it “better”. Companies that focus on using the least amount of effort and resources to achieve evolutionary change in their products are just extending the inevitable disruption of their market by someone more willing to take risks, take chances, and innovate rather than merely evolve.

What Creates a “Product By Committee” Culture

Most companies that are stuck in a product-by-committee approach probably didn’t start out that way, nor did they expressly intend to adopt such an approach (though I have seen some companies that, out of sheer insanity, intentionally adopted such a counter-productive mode). More likely, the culture slowly shifted into such an approach due to any number of factors, all of which make sense from an objective perspective, and all of which can actually be pretty easily remedied......The first, and perhaps most key, factor that pushes companies into dysfunctional product planning methods, is a culture of risk aversion. This feature can slowly seep into a company culture over time, as growth begins to slow from the 60+% year-over-year increases that many startups wind up seeing as they ramp. When that rate starts to decrease, the fear of losing the customers and revenue that keep the company afloat starts to creep into the minds of the leadership, which tends to display itself in increasing risk aversion. Nobody wants to do anything that might cause the ship to shift uncomfortably in the waters of the market, so ideas that don’t play to the core competencies of the organization start to lose some of their focus. Research and development investment slips until there may be an R&D team in name only. Large customers start to dictate large portions of the product roadmap, because the company “can’t afford to lose them.” And while this is a rational response, when it goes too far the company simply loses the ability to innovate at a core level, which radiates outward from the executives to the rest of the organization. Safe choices are rewarded, risks are avoided, and everyone has to agree before anything gets done.

Another key component of organizations using committees as their primary product guidance is a lack of delegation, accountability, and responsibility. Companies that struggle with these basic concepts of organizational performance tend to keep the decisions among the executive committee because they don’t actually trust others to do the work in the way that they want them to. This kind of approach makes sense when you’re a 25-50 person startup; you can afford to own the entire process from start to finish; but as you grow to 100, 300, 500, or more employees, the central core of the company can no longer effectively manage through direct authority throughout the organization. Delegation becomes necessary, and along with it both responsibility and accountability applied equally throughout the organization. Modern, successful organizations empower their employees at all levels to make the decisions that they need to on a daily basis, and hold them accountable for those decisions. Enabling people at the lowest levels of the organization to make and learn from mistakes is far cheaper than mistakes made at the very top that trickle down without any effective challenge or understanding of the actual ramifications. We delegate work responsibly because that’s how large organizations function; holding power and authority because we’re afraid the people under us will make the wrong decisions means that we’re actually afraid that we’ve hired the wrong people.Lastly, committee culture usually arises and thrives in a vacuum of clear direction, strategy, and vision for the company at the top of the organizational pyramid. When we don’t have a clear picture of who we are, who we want to be, and how we’re going to get there, a pall falls over the organization as a whole, obscuring our abilities to effectively prioritize the wide variety of decisions that come up on a daily basis. Rather than have a clear direction to ask “How does this move us in that direction?” we have to have constant, high-level, detailed discussions on every single such question. This also plays into the lack of delegation -- if people at the top don’t even know where the company is going, how are the subordinates in the organization supposed to make decisions that aren’t going to cause waves further up the chain? Far too many companies see vision and mission statements as “fluff” or “soft skill” elements that they can do without -- and they pay the price in the end, as without such clarity every single decision about the product requires full review and assessment, whereas with such clarity it’s often a simple, binary, yes/no call that can be made quickly and effectively -- providing clear direction to everyone in the organization and enabling them to take on such decisions themselves.

Why Consensus Never Really Works

Now, you might be thinking to yourself, “What’s the real problem with a committee-based product plan? Doesn’t that mean that everyone agrees, and isn’t that a good thing?” To this I respond that if, in fact, everyone agrees, there’s not only no problem, but there’s also probably no reason to have a committee reviewing the product direction. Having a “committee” implies certain things about the planning process -- that there’s disagreement among the stakeholders, that these disagreements arise from fundamental debate around the product's direction, and that the company won’t go forward until there’s common understanding among the committee members. Certainly, not every group decision is bad; it’s when they become the rule rather than the exception, and prevent the company from innovating and pushing boundaries that they become deadly.One reason why this is so is that committee decisions almost alway suffer from some level of analysis paralysis, as each and every member of that committee is bringing with them a different set of interests, agendas, fears, and motivations. In order to push something through such a committee, you have to ensure that you have sufficient information to assuage every single member’s interests, agendas, fears, and motivations. When you start hearing the classic refrain of, “That sounds good, but I’m a little concerned about…” you know that you’re going to leave that meeting without a decision for the umpteenth time. There will never be a time when an actually innovative and market-shifting solution has all of its ducks in a row and all of the necessary data to get people on-board without question -- analysis paralysis puts us in a position where the interesting ideas die and the boring, safe ideas pass through regularly.Another thing to keep in mind when assessing the effectiveness of a committee culture (or lack thereof) is the concept of distributed authority and how it can trigger the psychological situation known as the “bystander effect”. For those not aware of the concept, the “bystander effect” describes how people respond to situations in which there are a large number of people involved in a critical situation, and how many people will choose not to take action based on their expectation that someone else will or already has. The more people there are involved in a decision, the more likely people will defer to others, even if no action is actually being taken. And if everyone defers to everyone else, nothing happens at all! This can create a very vicious cycle within an organization, as in the absence of clear statements of authority vested in specific individuals, many people will simply assume that “Someone else is taking care of that” or that “It’s someone else’s job to make that decision.” When we leave product planning meetings without clear action items, assigned to specific individuals who are tasked with making specific decisions or performing specific actions, we’re just asking for the bystander effect to rear its ugly head and for even our best-laid plans to go absolutely nowhere.The last thing to keep in mind is that in most organizations, and in most cases, what appears to be consensus isn’t really consensus at all. What it is, instead, is the wearing down of the rough edges, the oiling of the squeaky wheels, and the bending of the will of the people in the room. True consensus requires that those who disagree reach some form of assent; it requires that nobody in the room express their concerns or questions over what’s being discussed. It doesn't lead to good products or good feelings. The process of ensuring “consensus” in a decision by necessity means that some people aren’t being heard, even if they nod their head at the end of the meeting. And that leads to further issues down the line as they do express their feelings elsewhere and with other people, or act against the plans in one way or another after the “consensus” has been reached. More often that not, what people think is consensus isn’t even that, which causes more issues than simply delegating or authorizing others to make decisions and take action.

Use Influence to Build a “Bias for Action” Culture

So, how do we go about “fixing” the problems that exist in a committee-based organization? Fortunately, there are many options available to us that directly attack the dysfunctional behavior while still allowing the organization to adjust as a culture. Here are a few suggestions to get you started on building a culture biased toward action rather than toward contemplation.First, whenever there are meetings, make sure that they are short, focused on specific questions, and that there are specific action items noted down and managed after the meeting. A great Product Manager is also a great facilitator, and this is where it is perhaps most important. Create an agenda, ensure that the people present are actually required, focus the meeting on the important questions in front of them, and document the decisions and subsequent action items. Keeping teams focused on specific, tangible agenda items will limit the amount of cross-talk, tangents, and other diversions -- and focusing on actionable decisions and setting specific expectations will ensure that there is forward motion.jSecond, it often helps to get a little RACI (sorry, I couldn’t resist the pun!)...that is, to set up a matrix of areas of authority and expectations of responsibility. The RACI structure asks us to lay out specifically who is “Responsible”, “Accountable”, “Consulted”, and “Informed” across the functional areas and common decision points that we have within our organizations. This structure is important because ideally there is only one person or department within the organization who is “Responsible” and “Accountable” for decision points. There can be any number of teams who are “Consulted” and “Informed”, but the limitations on the first two functions is essential to building up a delegated structure that instills both authority and accountability for the designated areas.Finally, we want to try to change the focus on the organization from risk aversion and blaming to one that is outcome-based and focused on learning and remediation. We want people to make decisions and try new things, and we must embrace the fact that they will sometimes fail. But when failure happens, we don’t point fingers and assign blame -- instead, we discuss what we can learn from that failure, and what things we can do to keep the same failure from happening again. We perform root cause analysis to dig beyond the superficial and into the real, underlying reasons -- processes, tools, or planning are the most common causes, and our remediation has to start there. Only if or when we’ve addressed all of those possible causes should we start focusing on the people involved.

Conclusion

While it’s important as Product Managers to make sure that we have general alignment on the plans for the product and the company, we can’t (and shouldn’t) pretend that this means that we need to have complete consensus across the organization. We need to value and understand dissenting points of view and objections, since these are the ideas that lead us down the uncharted paths where innovation and change comes from. If we only make safe choices that everyone in the company agrees with, we’ll never grow and change -- and the companies that don’t restrict themselves to those safe choices will take off and bypass us entirely.