Friday, March 27, 2009

What do you do?

A lot of times, folks ask me what I do for a living...whenever I say product management, the first thing I hear back is either "What is that?" or "So do you like being a project manager?"

Product management is sort of difficult to define to those outside of the corporate world. I always explain it to folks by saying that a product managers job is to understand the market and work with the team to define a strategy and plan to ensure product success. Sometimes you find that product management reports into marketing, into a technology, or as a stand alone business group.

I also find myself explaining the differences between program, project, and product management to folks. I know I've oversimplified it, but here's my quick and dirty explanation:
  • Project - Works to determine when the feature will be released.
  • Product - Works to determine what features are important and what the feature is. In some companies the product manger has P&L responsibility.
  • Program - Across project resource allocation and project coordination. This function can manage one or more project managers for a particular account or product.
Anyways, that enough for today on that little pet peeve :)

Monday, March 23, 2009

Black and White

Earlier in my career I was sort of a black and white type of guy...as I now know, the world is filled with a lot of shades of gray. You'll often have conflict between scope and deadlines or between quality and deadlines, etc where the answer isn't always black and white. As a project manager and product manager I've learned that understanding, quantifying, and minimizing risk through communication with the team is essential. There are two things that have helped me in guiding successful teams and I thought I'd share with you:
  • Listening - This cannot be overstated. Even if you disagree with the perspective or opinion, acknowledgment of that opinion goes a long way to building a team consensus. When you listen you might actually learn something.
  • Be prepared - I have a rule that I work to be prepared for meetings. Being prepared allows you to actually know what you are talking about and you can't lead a team if the team doesn't believe you know what you are saying. Take the extra time to prepare for meetings, review the agenda, talk to the key players. Knowledge is very helpful in decision making :)

Monday, March 9, 2009

Pricing - The difficulties

If you have ever worked at a small company interested in becoming more profitable, you've surely faced the difficulties of pricing your product. Many product manager typically fall into the trap of pricing by taking the product's cost to deploy (including a corporate overhead) and adding a markup. There are several reasons why this type of pricing is typically the easiest to rely on:

  1. It's the easiest to determine since costs can easily be determined.
  2. It requires the least amount of effort. See Reason #1
  3. It's supposed to lead to profitability

While this may work, it is clearly not the most ideal way to price your product. There are also a lot of factors in pricing such as goals (market share vs. profitability) and also your product's strength in the market.

Tuesday, March 3, 2009

The Roadmap Responsibility

At one point in my career I worked at a start up technology company who was really interested in getting that next sale, that next logo that they can put in their sales pitches and investor presentations. So of course the product managers scurry revising and creating their roadmaps and putting dates and milestones, etc. It's easy to put together a roadmap, as product managers we know the market, the customers, and the competition. What's hard is to put together a credible roadmap.

We have all seen roadmaps that we look back on a year later and just wonder "What happened to all of those plans and ideas?" It was likely because we didn't get real buy in and commitment. When that happens the road map just becomes a slide that some product manager created. There is no sense of true partnership or responsibility on the part of the team for delivery.

So here are a couple of tips that I have found helpful:
  1. If you don't have buy in from the whole team, don't put dates or even quarters in your roadmap. When the sales team shows this roadmap they are going to get asked "When will you release feature ABC?". The answer is simple, this is a plan and we are working planning the release of that feature and we will let you know as soon as we have feature ABC committed for delivery. Be honest and truthful with clients, it will pay off.
  2. Create the intial draft of the roadmap with everyone's input. It's easy for a product manager to go off and do all of this research and present a road map to the team. A better way to do that is to go to engineering and ask them for what improvements do they want to see. Perhaps there are infrastructure improvements that can make the support teams work a lot easier. Maybe some internal tools to debug issues to lower the cost of customer service. There are a lot of ideas, include everyone!
  3. Make sure you have a product development process that provides clarity and transparency into how resources are being allocated and how the roadmap will get implemented. As a product manager you will get graded on what gets implemented, not what you define or want.

Just some initial thoughts on such a difficult subject. Obviously there is more to it than just this blog post, but these are helpful lessons I've learned.