Effective Product Management
As a VP at VMware of product management, I spend a lot of time talking to teams about what the product management discipline should look like. Every step of the product management journey has been a delight for me — from individual contributor to managing a team of well over one hundred product managers. I have tried to capture some of what has worked for me and what I have seen work well here.
The Zen of product management
Product management’s primary allegiance is to the business. In most simple terms the engineering team owns the process of building the technology. The product management team ensures that what is built generates a sustainable business for our shareholders. We can and must love our customers, we can and must seek out alliances within and outside the company that drive success, we can and must make the environment we work in delightful for those around us, but we only get to do all this if the work is grounded in strong business fundamentals. Product management starts and ends with understanding business objectives and mapping day-to-day efforts into those business outcomes.
There is a widely held view (certainly in Silicon Valley) that ‘product managers are the CEOs of their business’. There is some truth to this that at the end of the day the product manager owns the business outcome and must demonstrate a high level of accountability to the business, but that mindset can be detrimental to the success of product managers in large organizations. What we are building is complex, has many facets, and needs to fit together elegantly. That is almost impossible to accomplish unless there is a body of people working to understand how the whole system ties together, focusing on the intersection of the parts, and ensuring that the various pieces we build are complementary, not internally competitive. Beyond that, product managers don’t have the empowerment that CEO’s have. It is a role of influence rather than direct authority. Great product managers lead, they don’t necessarily ‘manage’ in the traditional sense.
Ultimately the truly great product manager ensures that everyone in their organization feels connected to the business, and shares an equal level of urgency and commitment to the customer’s needs. It is their job to represent the people that aren’t in the room. The level of productivity of an engineering team that feels empowered to help real people, understands why they are building what they are building, and ultimately has enough context to make informed tradeoffs is disproportionately higher than teams that are just ‘burning down backlogs’. Great product managers light up the teams they work on. They are excellent story tellers, they help people see things before they are real, and connect teams in a visceral way to the problems at hand.
“If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.”
― Antoine de Saint-Exupéry
Key virtues
This section is dedicated to talking about some of the key attributes of great product managers. It is critical though that as we evaluate talent coming into the organization we don’t look at this as a ‘check all the boxes’ approach. Product managers come in a lot of different shapes and sizes and perform a lot of different functions within the organization. Someone that covers all the bases but doesn’t have super powers isn’t going to be as successful as someone that has overwhelming strengths in a few areas, can pinch hit in others, but also knows how to get support for things they are not good at. When I look back on my career, there are a lot of boxes below that I didn’t check, but recognize that I would have been more successful had I been able to do those things.
Business centricity
The first allegiance of product management is to the business. At the end of the day the job is to create customer delight, and turn that delight into revenue. Asking the question ‘how is that going to make us money’ is critical. Understanding that this isn’t always a direct line; there are things we will do to improve our brand in the community, unlock new customers that can be sold commercial products later, etc. It is also important that the product management team deeply understands the business fundamentals. It isn’t just about what you build, it is about how much it is going to cost to operate and maintain, how you are going to take it to market, how it is going to be competitively positioned. Product management must effectively act as the bridge to the business. Understanding sales, understanding financial implications — not just focusing on top line, but bottom line also. Product management must balance risk/reward decisions and see the role of their product through the lens of the broader portfolio; sometimes you run high risk/high reward experiments and they don’t work out. Knowing when something isn’t aligned with the business needs is a critical virtue.
Technical versatility
If you are reading this you likely work in a technology group and product managers are going to need to understand the product itself, be able to have in-depth conversations with customers about the technology, internalize the relative merits of competitor’s technology. This isn’t a developer role, and if you find yourself arguing about the algorithmic complexity of a solution you are probably playing the game at the wrong level. You should not however shy away from the technology itself. You don’t have to self-identify as an engineer, but you do need to be able to understand engineering practices and the technical landscape. Not getting the tech is like being a barista that doesn’t drink coffee. You may still be able to do the job, but having an appreciation for the product will make a world of difference. Ask yourself when the last time you installed and used the technology you represent. If you haven’t tried, you probably aren’t doing your job right. If you discover you can’t, make sure you spend a lot of time with people who can.
Customer empathy
There is nothing more powerful in the day-to-day job of a product manager as being able to effectively channel the customer and ensure that during the hundreds of large and small decisions that are made in product development, each decision is setting the team on a path to delight the right customers. It is also important to be brutally self aware that not everyone out there with money is a prospective customer. There is a big difference between a prospective user, and a prospective buyer. You need to serve them both — address the buyer’s business needs to get your foot in the door, and delight the user to expand use of your product. Knowledge is power and the customer controls your team’s future. Know them deeply, understand their lives and make sure that what is produced by your team will make them successful tomorrow and 5 years from now. It is also important to separate the customer and buyer in your mind. Also beware survivor bias. The customers you have are not necessarily the customers you need, and focusing on the squeaky wheel may preclude you from serving the needs of many.
Collaboration
No team is an island. So often a local optima for the team will not result in a global optima for the business. Seeing the team’s contributions to the broader business, and having the innate ability to help other teams understand the importance to customers of programs you are driving, and reciprocally being willing to adopt their programs when needed is important. Looking at the internal world as a zero-sum-game is the antithesis of this. The minute a team thinks that they ‘win’ if another team ‘loses’ everyone is in trouble. There are a few key elements to successful collaboration: (1) building trust, (2) communicating expectations clearly through contract and continuously through updates, (3) honoring the trust others place in your team by ensuring that their needs are properly being prioritized and deliverables met.
Storytelling and Communications
Every product manager is a leader, and every good leader has to be a story teller. Being able to create a sense of potential and create a sense of what is possible before it exists is a critical part of the product management discipline. Being able to create a sense of something before it is real makes a world of difference.
While outbound is important, perhaps the most important part of this is inward facing. Getting engineers to fully understand the customer problem that is being solved, understanding enough of the business imperatives to create urgency and ultimately being able to make better day-to-day decisions that support the business.
Perhaps the hardest problem in managing an engineering project at scale is the complexity of coordinating contributions across a number of different areas. This is fundamentally different from story telling, this is about managing the flow of information, not vision. There is no practical way to build a complex system at scale where some level of dependency management isn’t required. The “fog of war” is the enemy. The art is managing signal-to-noise ratios. Over-communicating just adds to the fog of war. Under-communicating does the same. This means thinking through things like “this decision was made, who needs to know about it?” or, “my team is struggling with this, who needs to know so I can get them help?” Constantly seeing the team through the lens of the bigger machine, and working hard every day to manage the flow of information into and out of the team is an important part of the job.
Courage, positivity and relentlessness
Success isn’t easy. Were it, everyone would be doing it. The evolution of any project will take it through some challenging moments. The willingness to persevere in the face of adversity marks the difference between a product manager that will create great outcomes and one that will simply drift with where the wind blows the team. There are three things that teams really need from product managers: (1) courage, (2) positivity and (3) relentlessness. Courage is looking at what data you have, working with collaborators to form a decision, and having the fortitude to ensure that the decision sticks. Making enlightened bets and personally accepting the downside when bets don’t work out. Courage is about holding the line on what you aren’t doing. Saying yes to customers is easy, saying no is really, really hard. Positivity is critical. This isn’t about being Polly Anna and the team cheerleader. This is about focusing on the opportunity and casting the challenges as things that can be overcome. It is about removing heat when everyone else is adding it. Relentlessness is obvious. This is the willingness to run uphill into a headwind for as long as it takes to get to the place the team needs to be. It is about living in a 3 steps forward, 2 steps back world and being ready to take the 3 steps forward every time the opportunity arises, even knowing you may end up only 1 step forward from where you started.
Discipline
There is tedious, repetitious work in every job. Every job has a grind quotient. Take the time to get things in order so you don’t waste time trying to find them tomorrow. Carve out time to stay on top of the things that your team needs you to do that you perhaps don’t enjoy. It doesn’t matter how brilliant you are, if you can’t be relied on by your team to do the things they are trusting you to do, things will fall apart in short order. It is also important to be incredibly disciplined about priorities, for yourself and for your team.
Things I have seen work well.
Knowledge is your primary currency
The heart of product management is influence without authority. At the end of the day you won’t be writing the code, and as you succeed in your role you will be less involved in the day-to-day decisions. Building up a strong base of knowledge is critical to success. Understanding the customer, the competitive landscape, what other teams are doing and how they can help your team, etc. Building your knowledge will establish a currency with your engineering team. The starting point to having real influence is in showing that you can make accurate data-driven decisions on a day-to-day basis and you have access to information that the team values.
Know when you are spinning your wheels, get help
There are a lot of situations where a team is asked to do something that they cannot accomplish for a variety of reasons. There are a lot of situations where a decision needs to be made that cannot be effectively driven at the sub-team level. Nobody is perfect and it is unreasonable to expect people to be perfect. Often as not the earlier a situation that requires additional support for a successful outcome is identified, the lower the cost of delivering and accepting that support will be. It isn’t a failure to ask for help. It is the management team’s responsibility to create an environment in which their teams can succeed. Focus on a balanced perspective here (manage the signal-to-noise ratio), but ask for help when you need it.
Embrace kind directness
Kindness is a powerful virtue and it makes the world and workplace a better place to be. It isn’t kind to hold back information people need for fear of hurting their feelings. That is just setting them up for failure. Directness is also powerful in that it creates more efficient systems if necessary information is flowing. Taking to extremes can however create an environment that is stressful and toxic. It is an important balancing act. Directness that is legitimately intended to help is vital. Delivery matters, it has to be kindly done. The book Radical Candor covers this deeply, the directness works when you care about the person.
Adopt a shared fate mindset
There is no ‘us and them’ between product and engineering leadership. It is one team. You don’t succeed if your engineering team doesn’t succeed, and vice versa. Your strategy might be impeccable, but if it isn’t paired with effective execution you are dead in the water. It is important to not only recognize that you cannot succeed without the goodwill of engineering, but also that if they are executing against priorities that are not aligned with business needs you are not going to succeed and you will need to do something about it.
Adopt a learning mindset
The engineering organization has to be a learning machine. Building in the ability to run experiments, learn constantly from the little ‘failures’ you hit along the way and be absolutely relentless about improvement is key. It is about ensuring that the team tomorrow is a little bit better at its job than it was today. Celebrate the little bumps as learning opportunities. Build a focus on finding mistakes as early as possible. The longer something wrong lingers, the more expensive it will be to fix in the long run.
See the bigger machine
In a large organization your product is a part of a broader set of capabilities that are often marketed and sold together. It is critical not just to see what your team is working on, but understand how your product fits into the macro story for customers. Focus on the bigger story and understand not only on what problems you are solving directly, but also on the problems you might create through inconsistency, etc. The mark of a truly great product manager is being willing to cut their own product if they don’t see it fitting into the bigger story that the business needs to succeed.
Anti-Patterns that cause problems.
“That is beneath me”
Ego is a useless emotion; it creates no value. Nothing is beneath a product manager. If user-facing docs need to be written, write the docs and take pride in the act. But also get a plan in place so that someone who is better equipped to do the job is hired to take it over for you. Your allegiance is to the success of the product. Write the docs once to save the launch, but don’t make that your job.
Wallpapering over organizational gaps
This is the flip side of the first point. If you find that you are spending your life writing user docs, you aren’t doing what the team really needs you to do. If you are arguing about the algorithmic complexity of an implementation with your engineers, something has gone seriously wrong in your world. Assuming you are right you are hiding a problem in the organization from people that need to address it. If you find yourself stuck tactically in a role that doesn’t map your job description, you need to get out of that job quickly. Get a plan in place and sometimes you have to let things break a bit to get the organization to work. Exercise good judgement to let broken things fail when they need to so the org can learn and grow. Don’t get into a steady state job where you are wallpapering over problems in the structure.
Disagree then dig in
I have never been a fan of disagree and commit. I believe in disagree and commit, with a commitment to re-examine the decision when more data is available. Frame it consciously as an experiment. The most pathological outcome is superficially agreeing, but then finding ways to avoid the commitment. This kills teams. Go all in on a decision, and if you disagree, treat it as an experiment and organizational learning opportunity, but don’t try to bias the experiment to get what you feel should have been the right thing in the beginning.
The passive aggressive PM/eng death spiral
The most perfect PRD is useless if it isn’t read by anyone on the engineering team. It is critical to realize that it doesn’t matter how dialed in you are, how well you empathize with customers, at the end of the day you don’t write code, the engineers do. If you are not connected with and providing influence to your engineering team, something has gone wrong and you should reach out to your management to get help. Classic signs of this are asking for features that should be quick and getting estimates from the team that push them out past the heat death of the universe. If you aren’t aligned, get aligned or get help.
Being Mary Poppins to engineering
Product management isn’t an execution function. It is a strategy and business function. Your job isn’t to create a warm and comfortable world for the engineering team; it isn’t your job to insulate them from the realities of the outside world. Quite the opposite. Make sure that the engineering team understands the key challenges that customers face with the product, and ultimately are equipped to deliver the product the customers need. Engineers aren’t big babies. They should be able to run their own standups, understand and synthesize customers needs, and make smart choices. The key thing here is healthy tension and mutual respect.
Saying yes to everything
In many ways your product will be defined more by the things that you say no to than the things that you say yes to. It is critical to be practical about what can be accomplished, and to call your shot. It is easy to say ‘of course, eventually we will do that’ than it is to say ‘that is an important capability/market, but it isn’t a problem we are looking to address with this product’. Be bold, but also be focused and pragmatic. Be data driven and have the backup necessary behind your decisions. Do the work and be able to demonstrate how your decisions are fact-based.