Lessons Learned in Product Management

Editor’s note: This is a guest post from Rick Samona on lessons learned as a product manager at Microsoft.

My background is such that I am able to straddle the fence between development and business. I got my MBA in Marketing and my MS in Computer Engineering and I have worked in both capacities in the past, although over the past several years, I have focused on building strong Marketing and Product Management teams. I often get asked “What is a Product Manager?”

Let me first summarize what a Product Manager should be. To boil it down to it simplest level, a Product Manager has 2 roles – i) Outbound: Communicating the product and the vision out to the customers and ii) Inbound: Feeding customer and market insight into the development teams to better the product, build a new product, acquire a new product, or kill the product.

Microsoft is historically a culture where the developers build it and the marketers sell it. In other words, it is almost all Outbound. There has been a much needed transformation over the past few years, or should I say an attempt at a transformation, to have the business folks help feed into the development planning cycle. After all, the marketers are closer to the customer than the dev folks in most cases, and when they aren’t, they shouldn’t call themselves marketers. Since I speak both languages, I have been able to drive much of this change in the products I have been responsible for, but it hasn’t been without challenges. Oftentimes, what incents a developer may not incent a marketer, and it’s important to know what levers to pull when trying to drive progress. There are a few fundamentals and best practices that are critical towards shaping software from a marketers perspective –

Be a genuine person: This is not a skill that can be taught, and it’s not a skill that is specific to being a good product manager. In order to work well with others, the first and foremost important thing is to be genuine and establish a relationship with that person. When I worked with the developers on the .NET team, I didn’t walk into meetings and start talking business off the bat. I got to know them as people first, not developers. And it wasn’t like I was twiddling my thumbs and saying “Moohaha, I convinced them I care about them.” No, it is just about being a genuine person. This sounds like common sense, but it is so overlooked. I recall a new manager coming into my office for an intro once, and he started rattling off business objectives. I shifted the gears of the conversation because I wanted to know more about him as a person first, not him as a business leader.

Establish credibility: You can establish credibility in many ways. One way is by using the product. It would be pretty hard for a Product Manager in SharePoint to go fight for a new feature if she doesn’t first know how SharePoint really works. Another way to establish credibility is by immersing yourselves in the issues the developers face, and ask how you can help them. Also, have regular meetings with the developers; don’t just wait until you need something and then ask for it. At Microsoft, this is particularly important because devs typically stay longer in role than marketers. As a result, when a Product Manager asks for a new feature, many developers will ignore that ask because the reality is that the Product Manager probably won’t even be in the same group to see it ship.

Know the customer: It is incredibly important to know the customer and live and breathe their challenges. The best way to do this is not to read a market research study from the safety of your office, but to get out there and visit them. Once I flew to Colombia to meet a customer and hear about their challenges. I’ll tell you, the best way to hear about a customers’ challenges and continue shape software as a marketer is to visit the customer in person.

Leverage the voice of the customer: I remember fighting for some security features when I was in the Server and Tools Business Group. The developers weren’t convinced we needed them. I tried convincing them in every way possible, but nothing seemed to work. Then it dawned on me – why don’t it have the customers tell the dev team they need these features? This did 2 things – i) the customer had credibility since they use these products day-in and day-out ii) it’s not just me saying that we need a feature – it’s 25 developers in the community who are speaking on behalf of hundreds of thousands of their peers. In my case, I set up some LiveMeetings with the developers at Microsoft and the Microsoft MVPs – influentials in the community that are plugged into our customers. The MVPs voiced their opinions, and ultimately, the features were added.

Being a great marketer and shaping software is not rocket science – it is actually harder in some ways. I bet you weren’t expecting that, huh? At least with rocket science, it’s a science by definition. Marketing, business, product management, and shaping software is more of an art. e != mc^2 at all times, but hey, that’s what makes it fun.

Rick, thanks for the insights!
Really good stuff. It only proves once again Weinberg’s second law of consulting – “No matter how it looks at first, it’s always a people problem.”
We are all consultants and we are all “consultees”.
I loved “Establish credibility” the most. Here in MCS it is no different – we have our biz folks and consultants.
What you described in your post is 100% applicable here in the field
Thanks for sharing

this post tell about Product Manager has 2 roles – i) Outbound: Communicating the product and the vision out to the customers and ii) Inbound: Feeding customer and market insight into the development teams to better the product, build a new product, acquire a new product, or kill the product.

The term “Voice of the Customer” is used too many times to refer to either market research in general or to the specific features or solutions that a customer desires. More properly, the Voice of the Customer is the statement of the customer’s wants and needs, not a specific solution to those needs. Building a product that customers will want to buy means transforming those needs into product specifications. You don’t want a product designed by your customers, you want a product inspired by your customers. That means thinking about wants and needs in a different way. For example, see the excellent article by Gerry Katz from the PDMA’s Visions Magazine (http://www.ams-inc.com/pdf/VisionsMar08Katz.pdf).