After three years in Process Engineering I took a risk and moved to Product Management. I had experience as a customer of my new company, and I was in a role where understanding the needs of those customers was important.
It wasn't as easy as I thought. Unlike engineering, I had to put more effort into communicating with various groups to understand what they wanted and why. I needed to turn those ideas into products but not in the way which I was used to. As an engineer I focused on how; in product management I had to focus on why.
All of this required new communication skills to be effective. Having a technical background allowed me to speak the engineering language but did not help me convey customer experiences to the development teams. Through a lot of trial and error, I've identified five specific lessons in communication that have helped me in my transition to Product Management.
#1. Communicate so you cannot be misunderstood
A 2013 Forbes article, "Successful Business Communication: It Starts at the Beginning," described the objective of communication as the following:
"Don't communicate to be understood; rather, communicate so as not to be misunderstood."
With product management, I was not used to the amount of coordination and alignment involved in product decisions. I quickly found out how easy it is to be misinterpreted when seeking agreement from different business units.
Spend time to develop a cohesive story around your data to help your audience understand your message. Engineers are data driven; if they don't understand something they tend to ask for more information. Providing raw data can be misleading without proper context. If you keep the message simple and supported, you can prevent people from needed to interpret what you are saying. Your audience will appreciate it when they can understand you the first time.
#2. Understand what you want out of the conversation
Before asking for feedback from your coworkers or customers, make sure you have a clear idea of what you want to get out of the conversation. If you don't, you risk getting off topic or leaving with your questions unanswered. I've made this mistake on many cold calls, (and even worse, emails) where I assumed the other person had the same background knowledge as I did, and it can be very painful to go back for further clarification. When you start with a clear objective in mind, you can prepare accordingly resulting in much less headache for everyone.
#3. Prepare a 'Cubicle Pitch'
Google defines an elevator pitch as:
"A brief, persuasive speech that you use to spark interest in what your organization does... A good elevator pitch should last no longer than a short elevator ride of 20 to 30 seconds."
How many times have we had to do the same thing in cubicle-land? It can be very useful to plan the same type of 'Cubicle Pitch' for when you are introducing yourself to new people you need to work with. You will need a clear understanding of what it is you want, how much time it will take (perhaps setting aside some time to collaborate is necessary), and how they can help. The objective is to demonstrate that you are respectful of the other person's time. It is good to prepare beforehand so that you've done the work of collecting your thoughts at your own desk and not theirs.
#4. Recognize that what you hear may not be what they meant
If you ask someone to make you a pizza in NY and ask the same thing in Chicago you are going to get two very different types of food. When talking to customers, coworkers and management it's important to realize that what our brains process might be very different than what the other person intended to communicate. To avoid this, provide detailed context before asking for an answer.
If I ask a customer what they have purchased from us in the past year and if they are satisfied, I am going to get a very concrete answer. For example, they might say, "Yes. We have purchased 10 machines."
With that, I might go back to my team and say, "Customer X was satisfied with the 10 machines they received from us in 2014. We are well positioned with that customer."
If, on the other hand, I had said, "Mr. Customer, I see that you have purchased equipment from us in 2014, why did you select us as your supplier for that application?" They might say something along the lines of, "Yes, we selected your equipment to meet our technology requirements, but your competitor had better productivity." To which we can quickly follow up to get more information.
The two responses to very similar questions will result in very different actions. It is important to formulate your questions with context to avoid having to clarify what the other person meant by his or her response.
#5. Transform your message into something actionable
Knowledge is only useful if you plan on doing something with it. In any role, the goal is not to take the information you've collected and hand it to the team to interpret, the goal is to gather and interpret the information so the team can act on it. If you throw data at people, they will use their different experiences to decide what needs to be done. The goal of communication with data is to give teams guidance on how they can complete a task, meet an objective, or solve a problem based on what you've concluded from your data. Transform your message into something that is actionable.
In the end
My experiences are based on one specific role, but the skills I described are universal. Most of this is intended to save time and prevent frustration in a global, collaborative work environment. Taking time to understand your communication strengths will help you be more efficient, achieve your objectives and build trust within your organization.
Terry Powell is a Product Manager supporting new service product development at Lam Research Corporation. Prior to Lam, Terry worked at IBM as a Process Engineer supporting Wet Etch and Clean for BEOL manufacturing. Terry holds a BS in Engineering from Binghamton University in New York.