Hang in there little Product Manager
Please note — This article has hypothetical examples and names. They aren’t reflective of my current company (Headspace) or companies that I have worked in the past. The title of the post doesn’t suggest condescension but is inspired by the song “Hang On Little Tomato” by Pink Martini. Originally published on LinkedIn.
Some of you have asked me in the last few months about “What are the soft skills a Product Manager (PM) should have?” This is a topic very dear to me because I have changed a lot of jobs and I have observed how different companies and individuals see this role. In its core this role is very interesting and satisfying — you are responsible for bringing a product to the user that they like while you meet the company’s business objectives without burning bridges (relationships with people in your team and your company). However, since you don’t have any direct reports (if you are an individual contributor) you have to do all these with this magical term we crafted called “influence”. And in the end, the accolades of success go to the team and if it fails, some criticisms go toward you. Before we forget, unlike an engineer who checks in their code every day and a designer who produces great designs, your gratification is delayed (till the product, your baby, is released). I don’t want to start a pity party; I want to acknowledge the peculiarity of this function and the challenges you face every day. Your life is hard and exciting and this post can help you develop some of the oft unspoken skills that you need to sharpen over time. Side note: 10 years ago, I devoted my a lot of time learning the technical skills but I realized throughout the years that having technical skills are only good if you have soft skills to bring your work into fruition. These skills may sound trivial and may occur to you that you may already have them; think again!
Successful PMs (who build great products and healthy teams) do two important things very well — provide focus to their teams — figure out the right things to do within the right amount of time and create alignment within the team and company — who are the right people to talk to? Are these goals the right ones for the company/team? To achieve this, I believe that a PM should possess two categories of skills –
- Technical skills so that you can build the product and use a repeatable and measurable process to that end. Broadly the technical skills can be classified as (a) Product Sense (Vision) — with past research, data, knowledge and assimilation of experience, a PM should be able to intuitively break down a big product problem into small “solvable” chunks through research and analysis and thereby provide their team clear pathways for solutions (b) Execution and Operations — product planning skills such as setting goals and key results, building a backlog and a roadmap; root cause analysis of a bug or an issue; creating right processes for team(s) to have the right focus and alignment.
- People/Leadership skills so that you can get people — team members, stakeholders and partners rally behind your plans and progress. These skills are the connective tissues that bring in product sense and execution skills to the forefront and without which, no matter how well versed you are in the first two skills, you will find it hard to navigate the company and bring a product to the market.
The balance between People Skills and Technical Skills vary based on your role and what/who you work with. Here’s a framework by former Spotify colleagues (Daisy Pilbrow and Javier Ubillos) built to assess where you are.
I may write an article about Technical Skills later. The scope of this article is the Y axis — people/leadership skills. But, before we talk about specific soft skills of a PM, it’s important to acknowledge that there are people skills needed to work with people and some soft skills such as “Resilience” for your own personal growth. We will discuss both.
Skills for working with teams and people
At the heart of collaboration, building a shared understanding with people or the ability to help them come to a decision is super important. It’s a big challenge in a cross functional team as team members come from different parts of the organization and they have different personalities. Your goal is to harness all ideas and thoughts, connect them to your goals and make a decision which is beneficial to your users and your business however in that process, create an environment where everyone can participate, feel valued and have a sense of ownership in that decision. To help your team, you need to provide them with critical information such as priority, objectives, technical feasibility, strategic input, constraints, enablers etc. No matter what information is required, you should be prepared to dole this information out as soon as possible. It’s a super hard thing to do and you’d need a lot of technical skills to do this. However, a few people skills will help you a lot. The four main categories of skills to help you are (a) Communication and Framing (b) Facilitating conversations (c) Building Trust and (d) Motivating. Let’s go through some of these and more in detail:
Communication and Framing
It is very important for PMs to communicate their plans/results/requests through various mediums such as keynote speech, product demo, planning meetings, product documents or even launch announcements. However, equally important is how you frame your communication based on your audience. Presenting an objective, a problem or even a solution to a group of people requires a technique called Framing. Employees want to see how their work is connected to the success of the users and the business. As PMs you should be very clear about the “why” behind a problem that we are trying to solve. A couple of techniques and things to keep in mind that can help –
- Situation, Action and Result (SAR) — it’s a technique used to narrate a story. A story can be about a user or it could be about a particular situation you encountered. Needless to say, it can also help you frame your response for a behavioral question that you may answer in your job interview. Start with the context and the current situation or challenge, then talk about what you did or what action you took and then talk about the result. It’s simple and powerful.
- Framing — Framing a statement influences the choices someone make on how to process the statement and thereby act on it. In order for your coworkers to get what you are saying or do what you want them to do, you have to frame your communication or request. Sometimes you start a brainstorming session and midway you realize that the team moved to tangential tracks; you then need to re-frame your challenge. Basic thumb rule of framing is to first understand your audience, their motivations and their style of communication and then frame your communication based on your understanding of the audience and how might your communication or request have some benefit for them. Sometimes understanding the implications of your communication/request way ahead in time is helpful as well.
- Pyramid principle — when a busy executive asks you a question you should first lead with the answer (the what), then summarize your findings supporting your arguments (the why) by building a pyramid of ideas and reasoning (starting with the answer, then drill into the next level — that way it’s easy for you to build up an idea and support it with the reasons and evidences) and then order each group supporting ideas by clustering or arranging them based on whether they are a sequences of events or hierarchical/structural or even degree of importance. I know that this may sound very scientific and not spontaneous. Use this for executives and for that big presentation. If you are prepared, you can dig deeper when you are asked to support evidences for each of your arguments and sub-arguments. This is a good summary.
“Anything else we could do?” and asking, “What do you think?” These are oft asked questions in the daily life of a PM. Sometimes we ask hard questions too. A lot of times PMs need to bring different stakeholders within the company and even partners/users together to come up with a solution. There will be a lot of challenges. Some examples are — Product “Visioning and Roadmapping” exercise, Team Inception (starting a new team) meeting, Stand ups, Backlog Grooming, User Research, Clarifying roles of team members. When you don’t have the luxury of an Agile Coach in your team, you have to be this person as your job is to get things done :) Facilitating Conversations is as much a science as it is an art. Art because you need to understand people — their skills/abilities, their willingness and motivations etc. and know who are the right people to get involved and how you can help bring the best in them. It is Science because to do a great facilitation, you need to bring some structure — have an objective, ground rules and constraints. Lucky us! Sociologists around the world has developed great techniques and I highly encourage you to read Gamestorming. It’s important to know that diverse perspectives are very important however it’s hard to get those perspectives when discussion get hijacked by strong personalities. It’s your responsibility to look for those signs and ask folks who haven’t participated in the conversation — “What do you think?” — it’s a very powerful question. In addition to getting another opinion, you’d also demonstrate that you care about everyone’s opinions in the room. These subtle things help you earn trust which is our next topic.
Building Trust and Earning Respect
Trust and respect are implicit reasons why teams or people work/for with you. Even if you have great technical skills, if someone doesn’t trust you or even respect you, it’s hard for you to excite them to work on a project. There are two types of trust — cognitive trust and affective trust. Cognitive trust is trusting someone’s abilities (technical) to do a job and show results and affective trust is trusting someone’s intents and judgments as a person. We will discuss the latter here. Some of these skills and behaviors can help you in building trust and earning respect.
- Get to know your team — Before you jump in to work in a new team or a new member, a fair amount of forming and norming happens. It’s easy to get lost in superficial bowling games and sprint planning right away. But if you really are curious who your team mate is and how to harness their energy, you have to know their motivators and things that demotivates them. I would generally do a personal mapping exercise and a project/team inception exercise to kick this off. The personal mapping exercise builds affective trust (by learning about the personal and getting to know them) and the inception exercise builds a shared understanding of what your team is trying to accomplish. And of course feel free to socialize with your team outside of office hours.
- Honesty — This is one of the biggest problem to tackle. As a PM you would be privy to a lot of important information — some are good news and some are bad. You have to use your discretion a lot in divulging such information to your coworkers and your team. At the same time, you are also accountable to be transparent and honest with them. I would suggest speaking with your manager on things you can talk about and things you can’t. If you feel that people are sensing some ambiguity in your plans or your communication, don’t let them brew in that confusion as this leads to rumor mills and that creates an unhealthy work environment. My advice is to come clean and state the ambiguous things up front but with a path to resolution. For e.g. “Here are the things I have no information and I can’t help you or myself. However, I will try and get this information by XYZ date. Is that ok?” More often people forget that date but remember that you have been kind enough to empathize with their confusion or lack of understanding.
- Vulnerability — Being vulnerable and talking about your failures, mistakes and deficiencies actually instill more confidence in your team than doubting your abilities. Vulnerability makes you more human and people relate to that. The best way of displaying this is in context and with sincerity; however being able to demonstrate that you have learned key lessons from those failures will make you stand out as a leader.
- Listening — It’s important to know and understand people, issues and ideas. It can be overwhelming at times but being patient and listening to people at work can lead to great collaboration and problem solving. It can also help build affective trust among co-workers.
- Coaching — Coaching is very different from teaching and mentoring. You don’t tell anyone what to do. They find that solutions themselves. What do you do then? Listening — active listening means you are not just listening to their words but understanding what they are trying to imply. You may have to probe more and ask difficult questions for e.g. Why do you think so? Why is it not the other way around? Have you tried to see their perspective? What can you do about it? What else have you tried? These questions are not rhetoric. You don’t ask “Have you tried this method?” — this is more mentoring or giving advice. Coaching is powerful — if you make it a practice to coach your cross functional team, they will in turn apply similar methods to resolve issues on their own.
- Clarify roles and responsibilities — when you join a new team or a new member joins, it’s super important to discuss how you can work with them and what to expect of each other. If we have worked in another company, we bring our own baggage and we tend to say “In XYZ company, I did this and worked really well so let’s start doing it here”. The things — they didn’t work with you in that company. Hence, you need to step back and clarify your role and their’s at the onset. RACI (Responsible, Accountable, Consulted and Informed) matrix is good for a cross functional/departmental project however within a team of engineers with some homogeneity we need to go a bit granular. Similarly when there are three leads in a team — Product Manager, Engineering Manager/Lead and Design Lead, it’s good to clarify your roles at a deeper level when you don’t have clear idea on where you stop and the other starts. For e.g. If you are a PM in a highly technical team, there are certain perceived overlaps of your role with technical lead or a technical project manager. Atlasssian published an exercise which basically looks at what you think your role is and how it maps to what others think.
- Blameless Post-Mortem and Psychological safety — although the entire organization’s culture isn’t your responsibility, yet it’s your responsibility as a part of the team leader (along with design and tech leads) to have a healthy and performing team. Don’t single out a person in your team in a public forum if there is an issue — do a 1:1 with them first. If there is an issue for e.g. the app is crashing etc., first focus on fixing it and then follow up with a blameless post-mortem which singles out issues, actions and points of failure vs. people. Etsy’s essay on this topic is really amazing. If you want to have your team give your real feedback, you need to build a safe zone for them to discuss things either with you or with the team — which means (a) use your discretion to share the information and how it is going to affect them, (b) things that are discussed in retrospectives should be only made available to executives as themes vs. specific comments by a person “whatever is spoken in this room stays in this room”!
Motivating Team Members
More than motivation, there is a high chance you’d demotivate a team member. A long lasting motivation comes from within and is intrinsic. However, we are going to talk about ways you can spark these motivations from within.
- Big picture and sense of purpose — This is a topic for another article however, if you can explain how someone’s efforts leads up to the team mission and thereby rolls up under company mission, there is highly likely that the team member will find a sense of purpose. The “why” behind the “what” is always important.
- Ownership — Accountability for a task or a project is a good starting point however there needs to have a sense of psychological ownership which is defined as a feeling that you own something (and not legally own it). “This is my project”or “This is my company.” It comes with you giving them autonomy and having trust in their work and their solutions.
- Appreciation and Recognition — Many PMs appreciate and give due kudos to team members. However, mechanics like bonus.ly or even kuddos systems sometimes falls short when the material benefits wears off and the team mate is seeking “real” validation as opposed to superficial ones. A few ground rules when you show appreciation to someone at work: (a) Appreciate someone and ask how they did the work — this will not establish that the work was great but also highlights the person doing the work and the decisions they made (b) Show them how their contribution and work benefitted the company and the larger context — it’s a great reinforcement for someone who is junior or doesn’t understand the value and significance of their work (c) Acknowledge the personal cost behind the work — we all make compromises and it’s a great practice to call that out (d) Don’t show appreciation but appreciate — I would rather bring an engineer who came up with a great solution to a meeting with executives vs. just saying thank you in stand-ups or team updates. Find out motivators and reward them when your team mates do a great job.
Skills for personal growth
These skills help PMs to be prepared for any situation so that we respond them in a way which helps build trust and earn respect from co-workers and stakeholders and in the long run helps you be an effective PM. These skills will help you as a person in the long run whether you are at home or at work.
In most companies — big or small, hyper growth or stagnant — there will be moments when your team or you may not have clear direction or focus, get recognition or be appreciated. Things may seem awry and chaotic and you feel super demotivated. If these weren’t enough reasons to feel distraught, think about situation when a coworker or even your boss hasn’t been nice to you. We all have at some point felt some or all of it. The best PMs have the ability to see below these temporary setbacks and think big and into the future. Resilience means not just bouncing back from a tough situation; it also means to gather courage to stand against all odds and be effective in changing the unfavorable situation. Since we have to be the connective tissue between different organizations such as engineering, design, research, sales etc. we have to be mindful of our responsibilities towards them and their stress. A lot of time we may be tempted to share some of our own frustrations; however if these frustrations turn into negativity and chronic complaining, it affects team morale. I would advise that you should definitely share your concerns in the right forum (one that can affect change) and with suggestions or ideas to fix the problem.
Conviction and Taking Risks
Make decisions. There maybe times when you feel that nothing is moving in any direction let alone the right direction. And it’s easy to be lost in those moments. I would advise having your own point of view on the situation at hand. You should be able to answer “How would I do it?” I have noticed PMs getting a lot of visibility and accolades for making decisions at times when there were no one making them. You need to have the conviction in you. You can validate your thoughts with your peers and give them due credit. In similar vein, you’d have to say “NO” to a lot of requests coming to you and your team. You’d need to have reasons and convincing ones to say no. Over a period of time, you’d need to build frameworks (even if you don’t have all the information you need) to build up conviction.
Debugging Issues and Problem Solving
Debugging technical bugs can be hard and so is debugging general issues. PMs are very good at finding out or helping find out root causes for issues. We should apply this to any problems or challenges we face in our job and even in our personal life. A few tools that can help you:
- 5 Whys — Go deep into figuring out the reason behind an issue. After asking yourself or the experts 5 times the question “Why” we can truly find out the actual reason or the root cause of the problem.
- Root Cause Analysis — Similar to 5 whys, RCA or Root Cause Analysis is an old but proven technique (mostly attributed to Sakichi Toyoda) to find out the origin of a problem removing which can eliminate possibility of further occurrence of the issue. This will not only help you work on issues with a product but will also help you with figuring out issues with teams, processes and organization.
- Problem Solving — When you have a big and hairy problem, it’s important to figure out all options (collectively exclusive) and classify them as mutually exclusive categories (so that you can eliminate the ones that don’t make sense). This technique MECE helps PMs not just vet options but also helps them communicate to executives succinctly.
Being in the Shadows
Not taking credit for something you had done is hard. More so because PMs don’t get to have personal gratification of their work everyday. It comes in cycles — releases or sometimes not in a long time. For your own motivation, you’d have to think about other ideals — how your work is changing the world, your users and customers and above all the career opportunities you have as a PM can’t be defined. Sometimes when my own family doesn’t know my role and what I do, I feel a bit frustrated and I make an effort to define it for them. But then again, I remind myself how my day-to-day work contributes to the larger mission of the company I work for. A big skill you need to develop is to feel comfortable with this notion and let your team shine before yourself. Your selfless drive won’t be unnoticed.
Lastly, a big part of your job is to deal with unpleasant situations and sometimes unpleasant people. Instead of complaining or escalating, try and mitigate people issues as much as possible yourself first. Start with having a 1:1 with the person and have the “crucial conversation”. This method doesn’t emphasize your issue with the person but rather with their behavior. Start with the context and observations (where, what and when that behavior was observed) and then talk about your feelings. It’s important to let them know why it matters to your or even the team and what can be done to avoid it or make the situation better next time. “When I saw you say ABC, I felt XYZ. It matters a lot to me and the team because ….. In the future if we do ….. then we can avoid this”. This is very hard but once you get into the habit of doing this and practice inside and outside of the office, it will come to you naturally. Make sure that you empathize with the person, conduct in a safe environment, separate facts from observations and come up with a plan together.
A lot of what I wrote is hard and you can’t develop these skills or display these behaviors in one day. You’d need to practice so that these come naturally to you. Don’t feign them. Lastly, it may occur to you that some of these skills are best suited for technical leads or agile coaches or even project managers. However, your team is your best asset and if someone doesn’t have these skills, you’d need to use them when needed.