|You old softy...|
As a preface to this, I was asked recently about how I had come up with a solution to a problem and I started explaining my thought process and the rationale behind my recommendations. Much of my explanation was around the use of insight and experience to dissuade or direct the conversation to a mutually beneficial conclusion, somehow getting my way (which I considered the best solution) rather than what the client was specifically asking to be done. I was asked "How do I learn how to do that?" This led me into thinking about soft skills and how they can impact a project and the success of the product manager. It seems a lot of hiring managers put great emphasis into experience and degrees and yes, these can go a long way towards your career goals, as does training (for instance, I'd recommend to any aspiring product manager to take the CSPO course). The more environments, the more applications, the more businesses you've had the fortune of working with and within, the better you'll be able to use those experiences and apply them to product management. However that is only part of the story. I think the traits best explored for improvement have to do with soft skills that really amount to a single concept - that's how well you develop relationships. In general I'm referring to the tool kit everyone carries around and uses whether you are aware of it or not, that enables you to be effective to and with those around you. I'll break these down into several categories: communication, empathy, context, data, shared ideas and goals, passion, and trust.
In nearly all product management job listings there's a common element that's generally wrapped up in a couple of lines that have to do with effective communication. As a product management professional, our job is really to delight the customer or consumer with what we are building - this applies to software, hardware or just about anything else. The first soft skill that is essential to being good at our job, is having the ability to translate what we hear, develop an understanding, and be able to retell what you have heard in your own words. This, combined with thoughtful conversation that includes back-and-forth questioning, leads to a shared understanding and allows you to further relate your understanding effectively to those on your team responsible for executing the objective, in my case, great and usable application software. From a high level, we call these requirements and some of the artifacts may turn into SOWs, functional requirements, epics and user stories - whatever works for your group. Everything begins with conversation and some type of validation process to develop a shared understanding, which you will do multiple times through the life of a project, whether small or large. In regards to communication, I believe it's more important to develop the skill of listening rather than speaking - it's difficult to understand what's being said if you spend all your time talking. The follow-up skill is to ask good questions. I like the adage, "There are no stupid questions" - you should take this to heart and make no assumptions. If you are constantly fielding questions from development and having to pass them along to a business contact for clarification, then you have probably not asked enough questions at project inception, nor do you fully understand the project. It's OK for this to happen if you have little context (like in the very beginning or if you are new to product management), however it's part of your job to have this context beforehand so you can anticipate those questions. More on this later.
The next soft skill to develop is empathy. A fairly generic description is to place yourself in the shoes of those asking for the feature or those experiencing the problem. Until you fully understand what is being experienced, it's really difficult to create a good solution. I think in general we in software development spend too much time coming up with the next new, cool feature and not enough time understanding what is useful or needed. We tend to take for granted those that are using the software we create on a day-to-day basis - the proof is all around us - how many times have you heard of some application releasing something that's held in so little regard it seriously impacts the company negatively? Sometimes we try to make things too complicated and this kills adoption. Other times we just plain miss the mark by providing something that no one really cares about. We need to use empathy to understand how our products are used and to access how important features are to our users. This will help us in developing good behavior-driven design in our products and we need to be able to provide this as context to our teams. Empathy also is very important when interacting with our team members. You need to understand what they are doing to some extent, or more importantly you need to be able to detect when someone is frustrated, either with a task or in trying to execute against their understanding of a user story or requirement. Have you ever had a story fail over to the next sprint over-and-over, greatly exceeding the original point estimate? Have you tried to empathize with those executing the story to attempt an understanding of why the story isn't done, or do you start complaining? It's through empathy that we become better understanding, and consequently, better at delivery.
I'll go on to context next, as I've already mentioned it in the two preceding soft skills on my list. Understanding how to use context is important as it provides the environment from which you will become the most successful. So how is this a soft skill? I think we take for granted when writing requirements how important context is to your team members. Often when I get a question like "why do they need this?" or "what are they trying to accomplish" it identifies a contextual problem - your team should already understand where a user story or requirement is going prior to the start of coding. To become skillful with context, a product manager needs to fully understand why the requirement exists. To understand why it exists, one needs to comprehend what problem or opportunity is being solved. Just as a good book needs a setting to establish the framework of a story, a good requirement needs context to fill in the gaps so there is a common understanding of what underlies the requirement. As a soft skill, to be effective the product manager needs to both understand the context and relate it meaningly to the team. It's this latter bit that identifies the execution of context as a skill and it's something that's often missing when working with a team. To me, being able to use affinity to something that's already been built, or using common analogies to illustrate concepts is very important. These may be supplemented with process diagrams but for me, white boards are essential to both describe the action, provide context and to answer questions - they're also a great way to identify gaps or issues.
How is data a soft skill? It's not in itself, rather it's a reference that needs to be recognized as important for many reasons. For those of you who have read my blog or other posts, you'll know I harp on data all the time, and for a reason. As a soft skill, you must recognize the importance of data, develop methods of acquiring it; and engender skills to interpret, refine, filter and express that data into a useful outcome. What I like the best about data is that if you know and understand it, you will be able to influence everything. As a tool, data is more of a crowbar that allows you to intersect with existing efforts, interject new thinking when needed and break heads as a last resort. Noting wins an argument faster and more completely than having the data on hand to support your position. If you're ever done any debating, you'll know that having quotable references provides huge advantages and can deter long and heated arguments - the same goes with having data on hand and some analysis on how it impacts your projects. If you live by the need to have data for your decisions prior to pitching them, this tool can take you a long way in executing your product vision successfully.
Which brings us to the next soft skill, being able to foster an environment of shared ideas and goals. You might think of this as teamwork, but I don't consider teamwork a soft skill so much as how a good product manager provides insight to contribute to the ideal team. So from my perspective, teamwork itself isn't a soft skill, but rather having an ability to instill a common goal in the team so everyone is working towards the same outcome. Many of the artifacts around scrum are there to get the team working together within a sprint - what the product manager can bring to the table is an alignment from overall corporate goals, to business unit goals, to team goals and finally to sprint and release goals. The good product manager constantly reinforces those goals throughout the process and helps to redirect the team's thinking to achieving those goals throughout the development process. If you've ever worked in a very efficient team, you'll know what I'm referring to here - it's often displayed when someone on the team asks the question "How does this fit into the overall effort?" or "This seams contrary to the drive for revenue" or something similar. The question itself isn't as important to what it implies - that someone is thinking about how everything fits together instead of blindly coding specifically what is being asked to be built. Once again, there are no stupid questions...
It seems we all want passion in our lives - I think as a soft skill it's more about how that passion is expressed and how it communicates to others on the team and to your customers. At the deepest level, as a product manager you should be passionate about what you are doing - if you're not, then why are you doing it? I think many would disqualify passion as a soft skill, and I'm sure all of us have encountered people who were so passionate that they were actually detrimental to a project. The quality or soft skill we want to develop is to make use of that passion to reinforce the team, the project, and in general use it to focus and influence all participants into aligning into a common goal - success and enthusiasm in creating great products! Just as we use the other soft skills as parts of the product management tool kit, passion can be used to either bludgeon or enhance a team. As such it's both a sledgehammer and a micro-screwdriver (but typically it's the former and not the latter). The difficult part is learning when to let the passion out-of-the-bag and when to save it for later - for instance, using it at the wrong time can lead to confusion and accusations of "emotional problems" (nothing like being accused of bipolar disorder!) - instead I think we should use that passion as a general enthusiasm of the project and team; and save real outburst for when they can be the most effective. We also must be very careful not to get carried away and allow it to have the opposite effect (what happens when it's used inappropriately).
The final soft skill and perhaps it's more an outcome of all the rest than a skill itself, is trust. Everything that we do as product management professionals leads to building relationships. To have good relationships, each party needs to trust the other. I often hear about transparency, communication, face-to-face meetings, etc to improve the design and build process, but really all of these are vehicles for the same thing - building trust. It's much easier to empathize with team members on a project when you have met them personally. When you have the trust of your business, your customers and your team, there's very little you can't accomplish. It's even possible to come in on time and under budget! So how do you get this trust and how can it be leveraged? if you think back to how I began with the idea of relationships, it's something that's difficult to quantify, but we all tend to have some idea about how well things are going. When things are going extremely well, the trust level tends to be very high. The opposite it true when things are going poorly. When you are questioned regarding a product decision, it's usually because there is no trust or that trust is in question. This becomes a culmination of all the other soft skills - when you use all other tools effectively trust is enhanced. And also the opposite is true - if you fall short on one or more of these soft skills, if you have already developed a high degree of trust, then much of that lack is forgiven.
That's about it for me - understand I'm not saying that these are the only qualities or soft tools that we need to be successful, I'm sure there are many more. These are just those that I've thought about during the last 30 minutes or so.