Stuff Product Managers Should Do, But Don't (and vice versa)

Let's start off by adding some things to your to-do list....

Four Things you SHOULD do, but probably don't:

1. Understand the product financials. Make a little spreadsheet of how your product makes money. How many new customers do you need to get to $1M of revenue, $10M, $100M? What about customer churn? The retention rate? The customer acquisition cost? Calculate the predicted monthly recurring revenue. How do different price points affect your forecasts?

2. Talk to people in your target market who are not (yet) looking for the solution to the problem you solve. These people are not customers yet. They are not even prospects yet. You probably have to dig these people up yourself without the help of Sales, and setting up interviews with them is a pain in the butt. But talking to them is the ONLY way you will REALLY understand your target market, the type of product that would really take help them and sell itself, and how to reach them. If none of them are really motivated to solve the problem your product helps with, then you need to know that.

3. Analyze your competition. If you can, try using their application yourself. It will help you understand where you are strong in comparison and where you are weak. And one day, if an engineer tells you that a proposed feature is technically impossible, but you see that feature in your competitor's product, you'll have a stronger argument.

4. Obsolescence Planning. Objectively consider whether you should kill your product because it is not, and will not, meet business objectives. It is so rarely considered because product managers feel like parents to their beloved products, and murder is unthinkable. But it must be done, to let you and the rest of the team go on to higher value projects.

Three Things you should (probably) NOT do, but might:

1. Fuss about colors, fonts, logos -- get someone with some actual taste, such as a Visual Designer, to do that. (Remember, you're the guy/gal who has exactly two fashionable outfits).

2. Write code -- Trust me on this, for every month you are in Product Management, your ability to write code degrades by two months. Within short order, you'll be at negative 4 months. And then you'll need an actual qualified software engineer to undo the damage you incurred.

3. Argue about code names for products or releases. For some reason, I have seen people get into massive, time-consuming debates about CODE NAMES -- probably because it is something about the product that is easy for everyone in the company to understand (even the receptionist and the CEO).

Just pick something boring. Boring, non-offensive,and can't be taken as a negative statement about the product or the customer. Remember, customers and prospects WILL hear most likely hear these names.

And, for the record, "The Gimp" and "Frankenstein" were actual code names at companies I've worked for. And, yes, it caused problems. I also worked on releases named after motorcycle brands (i.e. Ducati, Ninja, Gold Wing, etc.). That proved awkward when our sales team (unsuccessfully) pitched Harley Davidson. Similarly former colleague worked on release named "Skittles", which was awkward when their customer, Nestle, found out.