Throughout my many years as a Product Manager, and through many conversations with fellow Product Managers, I’ve come to notice certain patterns of dysfunction emerge within companies that make everyone’s job harder.  Many of these dysfunctions exist due to cultural patterns within the company, and are things that have developed over time — often they begin through necessity or simply as a matter of getting things done, but eventually develop into anti-patterns that prevent the company or its products from being the best that they can be.

The good news about these dysfunctions is that they’re all capable of being corrected for — provided that (1) you’re willing and able to identify them, and (2) people in the company can recognize the negative repercussions and are interested in adjusting their behavior appropriately.  As Product Managers, we’re often the most centrally impacted by these dysfunctions, and we’re often best positioned to lead others away from them through our influence and customer focus.  In this article, I’m going to discuss some of the dysfunctions I’ve seen and propose some possible ways to approach and correct for them.

Preface (or, Don’t Be Insulted!)

Before I dive into the dysfunctional cultures and their attributes and remedies, I want to note that these types of cultures only become dysfunctional at their extremes.  There’s nothing wrong with having an engineering-focused culture, nor a sales-focused culture, nor a hands-on CEO — until those behaviors and those patterns get in the way of the company’s (and the product’s) continued success.  Thus, the below comments reflect situations where the culture and its patterns have become dysfunctional, where the anti-patterns supported by the culture have replaced the positive patterns of customer-centric design and strategic planning.  If you see some but not all of these behaviors, that could be a warning that the company is tilting toward an extreme — which, fortunately, is the easiest time to even the keel and rebalance things.

The Engineering-Driven Culture

Extremely popular among start-ups and Silicon Valley giants, the engineering-driven culture is one that focuses on the technology and the people who build it, sometimes to the exclusion (or at least apprehension) of those who moderate the business side of the equation.  Engineering-driven cultures like to promote themselves as flexible, vibrant, results-oriented cultures that thrive on solving problems in new and interesting ways.

Some common dysfunctional attributes of these cultures include:

• Tendency to focus on new technology for the sake of the technology, not the user.
• Strong bias against “NBH” (Not Built Here) solutions; tendency to reinvent the wheel.
• Expects highly quantifiable data from the business; makes decisions internally on instinct.
• Skepticism of information provided by “the business” especially where objective data is lacking.

These dysfunctions tend to demonstrate themselves in products that are technically interesting and compelling, but which users have trouble approaching or that solve problems that the users don’t actually find to be valuable (or solve them in a way that the user doesn’t understand).  The primary fault of these organizations is the value of technology over the user — and the belief on the part of the engineering staff that they “know better” than the user or the business.

To tackle the dysfunctions of this kind of culture, it helps significantly to have members of the Product Management team who are technically-inclined themselves — but who maintains contact with and direct relationships with the customers and the market.  The PM needs to establish that bridge between the engineers and the customer, and the best way to challenge many of these assumptions is to simply provide user testing and validation opportunities as early as possible, with as many users as possible.  The direct and observable results of these test are indisputable, and position the PM as the conduit between users and technology — and provide the needed check on the technology focus that these companies over-invest themselves in.

Direct user feedback is the key to alleviating many dysfunctions of an engineering-driven culture; instilling curiosity, respect, and interest in the user are the goals.

The Sales-Driven Culture

On the other side of the spectrum from an engineering-driven culture is a sales-driven culture, wherein the primary driver of product design, development, and implementation is not the fancy gadgets and hip new technology, but rather the Almighty Dollar.  While it’s entirely true that products and companies need to make money, the sales-driven culture sacrifices all else at the shrine of the Almighty Dollar – support is seen as a cost center, user experience testing just delays delivery of key features, and engineering is seen as a system of order taking and delivery, not valuable problem solvers.

Some of the common dysfunctions of sales-driven cultures include:

• Strong focus on the “now” needs and less consistent execution against a future vision.
• Constant stream of one-off and “custom” work that’s “needed” to close deals or seal renewals.
• Imbalanced view of customers where “whales” become more important than everyone else.
• Focus on reducing time-to-market and overall support costs to the exclusion of indirect value.

When you’re in such a culture, you’ll often see no discernible product strategy, vision, or reliable roadmap — rather, there’s a lot of randomization and uncertainty about what’s next or what’s most important to work on.  You’ll also see an outsized reliance on and focus on the big “whales” of the customer community — often to the entire exclusion of support or consideration of those with less skin in the game, and less money flowing to the company.  These environments tend to be tense, as people are in a constant state of ensuring that the next deal closes and that the next renewal is signed, over any kind of market-driven or customer-driven prioritization or strategic direction.

Sales-driven cultures are hard to tackle from a Product Management perspective — often because the structure of the organization is one that’s focused on near-term success over long-term strategy.  But, a savvy PM can use that to their advantage.  First, it’s important to start putting specific, quantifiable goals on the product efforts that you’re making, and to place accountability on those who are making requests of you.  If the sales team is saying that they need X feature to deliver some whale of a deal — ask them to commit something to that, make it uncomfortable for them if the feature’s delivered and the deal isn’t.  Second, start collecting hard market data and user data about your product — how is it really perceived in the market as a whole, not just what you’re hearing from your sales team.  Calculate the total revenue contribution of those smaller customers, and when something comes up focused on a single whale, you’ve got valuable data that you can counter those asks with — if something helps one customer worth $100,000/year, is it more important than something that helps 50 customers with an overall contribution of $200,000/year?  Make it clear that the company is making choices that focus on single large customers and not on a generally applicable and addressable market.

The key to adjusting an overly sales-focused organization is by collecting data on all of your clients and all of your market to counter the inevitable focus on the big whales — would you rather have 5% of the big whales or 50% of the total market?

The Consensus-Driven Culture

One of the single most frustrating circumstances that any Product Manager can find themselves thrust into is the Consensus-Driven culture.  In these cultures, nothing can be done without everyone agreeing to it, and the resultant head-nodding and unholy bargains struck do nothing but hamper the company’s (and the product’s) ability to actually solve valuable problems for the market.  These companies waste time, effort, and money in long, drawn-out meetings and focus on delivering the least-controversial solution that makes the most people inside the company happy.

Common attributes of a consensus-driven culture include:

• Inability to create a vision or direction without 100% agreement from all stakeholders.
• Constant stream of meetings to “confirm” decisions that have already been made.
• Strong push to suppress dissenting opinions and those who challenge assumptions.
• Systematized methods for prioritization and decision-making that remove personal accountability.

These cultures can appear great on the outside — stakeholders nod their heads in agreement, there’s not a lot of backbiting or infighting that happens, and meetings (although long) tend to not be terribly controversial.  But what’s lacking in them is the fire that drives innovation — constructive conflict.  People are so terribly focused on making sure that everyone’s on board and that nobody’s left out, that they wind up making terrible sacrifices all in the name of comity.  Nothing new or exciting is proposed, because it’s inevitable that someone will shoot it down, and scorecards and spreadsheets wind up being the tie-breakers because it’s something objective and measurable — with no personal accountability to anyone involved.

Tackling these cultures is risky — because the only way to do so is to challenge the fundamental cultural agreement that is the foundation of the dysfunction.  The PM needs to be the one proposing innovative and disagreeable (though respectful) things — they need to challenge people to speak up and to be vocal when something is important to them.  They need to rock the boat and make some people uncomfortable — but to provide them with a soft cushion to land on in the end.  A PM in this situation needs to find something unconventional but entirely reliable on which to hang their hat and try something new.  They need to demonstrate that it’s okay to disagree, so long as the end goal of everyone involved is a better product and a happier customer.

Tackling a consensus-driven culture requires that you focus on the very thing that makes them dysfunctional — to find something unconventional but predictably successful to plant your flag and show that not everyone needs to nod their heads.

The Hands-On CEO/COO

As another example of something on the opposite spectrum, we go from consensus-driven cultures to those reflecting the interests and desires of one person – the CEO/COO.  While it’s entirely true, especially in startups, that the CEO or COO of the company is the “idea person” and the one who is almost always largely responsible for the success of the company, there comes a time when it’s best for that person to bow out of the day-to-day execution of their company and to trust the people whom they’ve hired to do their jobs properly, successfully, and in furtherance of the vision that the CEO or CO instills for the future.

When looking at a situation where there’s a CEO/COO who’s too “hands on”, you might find:

• Pressure to “do it now” regardless of opportunity costs.
• Culture that pressures projects to remain “green” regardless of actual risk or status.
• Fear of failure drives people more than a willingness to take risks.
• The product reflects the interests and desires of the CEO/COO and not of users or customers.

These particular dysfunctions are a little harder to discern than some of the others — particularly if you have a founder CEO, who are typically more hands-on simply by virtue of founding the company and growing it to the stage it’s at.  However, there definitely comes a point where the constant micromanagement and invasive reviews and commentary become more problematic than they are productive.  Founder CEOs often have very particular views about what the market is, who the users are, and how the product should work — ideas that are usually their own and completely unvetted with the real world, which may have changed significantly since they founded the company.

Fortunately, the Hands-On CEO dysfunction tends to be one of the easier ones to attempt to counteract, because the intent is entirely one of benevolence.  The CEO wants the product to succeed, because it’s their baby — they started it, they grew it, and they’re greatly invested in it (both in spirit and money).  Thus, the best way to manage them is either (1) redirect them to areas that are more valuable and directly beneficial for them — vision, strategy, and financing; or (2) implement user validation steps in between ideation and execution, for everyone.  You can’t treat the CEO differently just because of their micromanagement — rather you’ve got an opportunity to instill in the entire company the value of user and market validation.

Tackling the issues caused by a hands-on CEO requires a little of finesse and a lot of refocusing on the user and the market; fortunately, the CEO is strongly vested in delivering the most valuable and functional product for the market.