There has been a lot written about how to be a great product person. The skills for being a product leader are different. Here are some of the things I’ve tried to do in my time as a product leader. (Many of these skills apply to leadership in general.)
- Represent product in leadership meetings. Any organization will have many competing priorities. This includes business strategy, customer needs, marketing campaigns and financial situation. All of these contribute to what the organization needs from the product organization. It’s your job to listen to these competing needs and provide direction to the rest of the organization to ensure that the expectations from executive leadership are realistic.
- Go beyond buzzwords. The CEO wants AI in the product? Sounds sexy. But what does that actually mean? Delve into the details. If the CEO wants something that can’t be built with today’s technology, it’s the product leader’s job to say that.
- Clearly communicate priorities. Once priorities are decided, it’s up to you to make sure that everyone on your team knows what they are and how they fall into the schedule and affect the roadmap. Priorities can and will change and the changes need to be communicated quickly to the team, with direction on what other work needs to be delayed or canceled.
- Empower people. “Empowerment” is a buzzword too often used in job descriptions, with little to back it up. As a product leader, you can’t make all the product decisions yourself — there are way too many. If you do, you will fail at the other aspects of your job such as working with company executives on overall strategy.
Let product managers make decisions. Many decisions often have little consequence to the overall success of the product. Is the right timeout for a login 1 day or 3 weeks? In most cases, you won’t know until you try it. Clearly, the right answer isn’t 10 seconds or 10 months. The goal is to build it in such a way that you can change it later.
Be prepared to step up into the weeds when something critical comes up, but don’t stay there. I’ve had to do QA when time was tight and we needed to get things out. That should be the exception. You’re being paid way too much for that.
- Make decisions quickly. Inevitably, there will be disagreement among the members of the product team or between product and design. When these come about, it’s your job to make a decision. It’s better to resolve these quickly with the knowledge that most decisions are reversible once you have more knowledge on how customers respond. Don’t let decisions drag out with weeks or months.
- Elevate the skills of your team. Every team member will have strengths and weaknesses. Help your team members up their game. I’ve spent a lot of time teaching teammates on elements of product design, how to do customer research and how to communicate, among many other things. Some of this had been in the form of classes for the team, others have been in writings. (You can also find a lot of my writings on product management and customer experience on this blog.)
- Congratulate in public, criticize in private. You’ll have successes and failure. Celebrate the successes in public so that the team can share in the joy and excitement. When things go wrong, don’t criticize or berate people in pubic. Things will fail; that’s the nature of launching products. Failure is great, if you learn from it.
Embrace risk taking. If people are afraid of taking risks because they fear public flogging, your products may end up being too saccharine.
- Hire great product people. If your company is growing, you’ll need to hire more. As important as skills are, fit is more important. You can teach someone how to do market research; it’s much harder to convince them to care.
There are different types of roles in product organizations. Some are more structured and repetitive. Some require creativity. Put the wrong person in the wrong role and they will be unhappy and unproductive.
- Say “No.” This is probably the most underrated. Humans generally want to make others happy. Product leadership requires balancing every aspect of the organization. It’s easy to string people along, but it’s a bad idea. It’s better to clearly say no. It’s not possible with the schedule. The technology doesn’t exist. You’d need to spend a lot of money on AWS. Whatever the reason, put it out there. If someone doesn’t accept your “no,” then take it to the executive team for a resolution. You’ll get more done faster and are less likely to burn relationships.
These are, of course, general guidelines. You need to be aware of the specifics of your situation. If you’re in a highly regulated industry, it may have serious consequences if you fail; it’s the product leader’s job to understand that.