You’re Not Helping
Most of my writing is aimed at the product organization, and in helping that organization evolve to where it needs to be to truly serve the needs of the company. I have also written about how the leaders of the company can help facilitate this. This article, however, is aimed at those leaders that are not actually helping, even though their intentions are typically good.
So here are what I would list as the top 10 behaviors in which leaders aren’t actually helping:
1. Drive-by Management. Also known as “swoop and poop.” This is the typically extremely busy leader that drops in occasionally (every few days or weeks) and does a harried brain-dump of all the ideas or frustrations he’s saved up since the last time he came by. The issue here isn’t so much the frequency of interaction, it’s the nature of the interaction. It’s typically very one-way and demoralizing. Instead, try changing the nature of your interaction to discuss what the team has learned since the last visit, what experiments have you tried and what are you intending to try next.
2. Micro-Managing. This is a tough one for so many product leaders, as they typically really do want their teams to step up and they want to empower them, but the leader may not feel the team is ready or able to step up. Unfortunately, this quickly becomes self-fulfilling, as a micro-managed team quickly becomes disempowered and comes to the conclusion they should just wait for instructions. My view is that you need to make sure you have people in your product organization you can entrust, and then you need to empower them and hold them accountable. The alternative just doesn’t scale and doesn’t yield the type of motivation necessary for sustained product efforts.
3. Customer Control. Some leaders think that they must control all access to the customers and prospects, either because they feel that’s their job, or because they don’t trust the product people not to say something inappropriate, or that the product people should stay with the team working on building the product. However, unless the product team can establish itself as the experts on the customer, the products will never be where they need to be. And if you really can’t trust the product team to know how to behave in front of customers, then you need to get people there that you can trust. Or send your product managers to “Charm School.”
4. Bright Shiny Thing. It is normal for those of us that love this industry and technology to frequently get excited about new opportunities and new technologies, but we’ve all seen the leader that changes his mind every few weeks on what the “next big thing” is going to be. As the leader, you do have some silver bullets to be used when a truly big opportunity does come along, but you only have a few, because once you’ve done that too many times, it’s like the boy that cried wolf. The team learns to not really pay much attention because they know you’ll change your mind again in a few weeks.
5. Last Customer Visited. A problem commonly associated with Drive-by Management and Customer Control, is the leader that completely guard rails after each customer visit. They get called into a customer that is having big issues, and then they come back and want to change everything based on that customer’s issues, which lasts until the next time this happens. In my experience, this is most commonly a problem when the leader only visits customers occasionally rather than frequently, and is a bigger problem at enterprise companies.
6. Confused Business Strategy. Very often the product team is thrashing because they either don’t understand the business strategy because it hasn’t been clearly articulated, or because the business strategy keeps changing on them. A business strategy typically has a profound effect on the product, so clarity around this is one of the key responsibilities of the leadership. The head of product may need to help the leaders to articulate this strategy, but the leaders must own it.
7. Acquisitions without Product Due Diligence. Leaders often get very excited about potential acquisitions, and they know they must do financial due diligence, but often they forget the product due diligence. Everyone in our industry knows how low the success rate is of mergers and acquisitions, yet it’s amazing to me how few are willing to do a post-mortem as to what they could have done differently to have achieved a better outcome. You can go a long ways towards helping by including product (and technology) due diligence.
8. Confusing Risk Aversion with Risk Mitigation. When companies are just starting out this is usually not so much of a problem because you don’t have much to lose, and you’re all just doing everything you can to find that product/market fit. However, once some measure of success has been achieved, it’s normal for the organization to move into the mode of trying to protect what they have rather than continuing to move aggressively forward. Risk aversion is when you’re scared to take the risks you need to in order to move forward. However, it’s the job of the product organization to mitigate those risks so that you can continue to experiment and learn without putting the existing business at risk.
9. Engineers and Sales People. There are a surprising number of leaders out there that still believe deep down that the only people that really matter are engineers (to write the code) and sales people (to sell the product), and the rest of the organization is essentially overhead. Old beliefs die hard. However, even if this is what you believe, by all means don’t ever say so out loud. You will demoralize the team and likely lose the very people that your company depends on for its future.
10. Demonstrating You Care. As my friend Danny Shader says, the organization cares about what the leader cares about. If the leader doesn’t demonstrate every day that he cares about your customers and your product, then the organization won’t either. Do something every day to demonstrate this caring.
I want to thank a product manager that I know for his suggestion of this topic and the title. I’m not naming him here just in case his CEO sees this article 😉
