Why Product Management Is Easy
I track the term ‘product management’ on Twitter. You can see the results of that search term by checking out a handy tool called Tweet Scan. Essentially, whenever someone mentions the words “Product” and “Management” in a tweet, I get alerted on my cell phone by way of SMS.
I’m a nerd, but I find it interesting. And, yes - this turned in to a hella long post.
Recently, and you should see this if you look at the search results, I’ve noticed a couple of folks talk about how hard a job product management is. I wanted to make some points here about this, and hopefully put to rest reservations folks may be having about exploring the possibility of getting into the job, or maybe even continuing doing the job if they are already in the thick of it.
My take is: it’s not hard.
Now, I’m not a product manager in a big, massive company. I never have been, and if I were a betting man, I’d say I never will be. That being said, I do in fact recognize that there are differences in how product management is done at say, Microsoft, and how I’ve structured it in the past. This is just due to the nature of the size of the organization where the job is sitting.
So, keep that in mind. My take on things is really related back to 20-50 (maybe 100 or less) person organizations. Anything upwards of 10,000 or 20,000 person companies really boggles my mind. So, hopefully that’s clear.
I do in fact recall when I was first put into the role. It was exciting, but at the same time, really ridiculous. Not for any other reason than, I wasn’t working for a more senior product manager to kinda guide me a long and instruct me on what to do - I was in there on my own learning as I went. It turns out, this is ideal for me, but I recognize it’s certainly not everyone’s cup of tea.
This leads me to admission number 1: The job is damn near impossible when you first start. Actually, scratch that — it’s damn near impossible when you get 3-4 months in. This is because, at least from my experience, it takes people about that length of time to really wrap their heads around what it is they are supposed to be doing. And I believe this is where most would sink and maybe start believing, “this job is WAY too hard for me, or anyone, to really do.”
And that’s 100% true. The way the job can be defined, it is impossible for someone to excel at. If you think about needing to be “proficient in Sales, Marketing (specifically, messaging and positioning), have a strong technical knowledge, excellent project management skills, well-versed in strategic alliances, and have a good foundation in finance.” Yeah. That’s a little tricky.
Let me take some of the surprise out of this description - there is no one that is “highly proficient” or “expert” in all of these things. They just don’t exist. You will either get a “tech” person, or a “sales” guy / gal, a “marketer” or a “project nerd.” But all of those wrapped into a single individual? Yeah. Not so much.
Now, this is where people may start to get down on things. How could you possibly do a job where all of those things are important? Some may say, “this is exactly what I think it’s HARD.” OK, well hold on - I’m getting to why it’s not.
Yes. those things are important. However, in a position like this, delegating is absolutely critical. That’s why you will usually see the line about “leading without authority” associated to many product management job descriptions. Why? Well, I’ll use myself as an example.
1. Am I a marketing genius? Hellz no.
2. Am I a great software programmer? Ummm, far from it. I may know a little LISP and SQL here and there.
3. Am I great with numbers? If you asked my grade 11 accounting teacher, she would say, “HAHA. No.”
And so on.
But here’s the key - if you understand *conceptually* how these things work, and maybe more importantly, how they work together, you are doing the right thing. No one person can build a great organization - it takes teams of people to do that. So, let’s re-visit those questions above with some modifications to them.
1. Do I understand marketing and have great marketing people to work with? Yes.
2. Can I give flexible requirements and wireframes to the outstanding developers and watch them develop wicked code? Yes.
3. Can I ask the finance people I work with to help me track project budgets to make sure I don’t go wildly out of control? Yes.
At the end of the day, so long as I understand the critical nature of cohesive positioning and building brand equity and help play air traffic controller to make sure marketing can do it’s thing, I’ve won. I can completely let go and push. IE, “I can give you feedback and my thoughts on positioning this product, but I need you to write the words and deliver something cohesive.” If they don’t, that’s another issue entirely. But I think you get the idea.
OK, so that’s a big long “admission # 1″ type thing. Once you cross that functional expertise hump, admission number 2 is this: The answers are right in front of you. Sure your opinion will factor a lot into the initial product release / development / design - but use those around you to vet ideas and build some momentum (no “i” in “team,” etc…). Someone actually has to DO things, but gather feedback (at least internally if you don’t have users yet, and then put something out in to the World.
Guess what? You are going to get a lot of stuff wrong. But it’s not about right and wrong. It’s about common sense and building cohesive products. The answers are always there - you just have to know where to look and how to ask.
So, is product management hard? No. The trick is not being the best marketer, accountant, UI designer, developer, Sales person all rolled in to one. The trick is to make sure that features get built, marketing communicates them, support can answer questions, and Sales can sell.
All the job is is connecting dots and knowing where to look for the data you need to make decisions. Don’t get overwhelmed by all the noise.
Makes Me Wonder
There is a recent article up on Marketing Profs that I’d like to briefly discuss. Particularly, this quote:
The product manager is generally responsible for ensuring that a product gets created, tested, and shipped on schedule and that it meets the specifications. This function is primarily internally focused, bridging Marketing and Development. This person generally has excellent technical expertise but rarely has the marketing expertise needed to bring a product to market.
While I do fall into the “technically savvy” group, this is a complete disregard of what product management is, when done true to form. Aside from the fact that it requires far more than “marketing expertise” to bring a product to market. This may be a bastardization of titles, or a lack of understanding - but I’m not sure.
The key thing missing here is that it’s the PM’s responsibility to gather feedback, parse it, craft a roadmap and execute that roadmap. The thing angering me most here is saying, essentially, product manager’s are nothing more than development managers.
The second thing completely wrong is saying that a PM is only there to “bridge the gap between marketing and development.” What is that about? A real PM knows it’s their job to pivot between Sales, Engineering, Marketing, Services, Management, Support, etc….
Why is this the case? Because a real PM understands they can’t be perfect at everything, and that people need information, and that good ideas can come from anywhere. They know their strengths within these functional areas, and will ensure they understand each group, at least, conceptually.
So, let’s be clear: a real, fundamental product manager does much more than take what geeks say and turn it into something copywriters can understand and fluff up. Bringing products to market requires a complete cross-functional effort, and a product manager or a product marketing manager should never believe that they alone have the full set of expertise required to do it all.
My personal philosophy is that a product manager acts as the proxy to the market. A product marketing manager speaks to the market, while a product manager listens to it. And I’m not the only one that thinks this.
Pricing Strategy Tied to EOLs
EOLs (end of lifes) on product lines, especially multi-product portfolios, are a fact of life. So, how do you deal with pleasing customers of a product line when only 1 product from that line is being dropped.
You do exactly what Apple did yesterday with the iPhone.
This was great because, while they did make a couple of people angry, the leveraged a short-term refund policy for those that really did just buy iPhones yesterday, but they managed to smoke one product off the iPhone line.
But the big news isn’t about the EOL — it’s about the price drop. Could they have killed this one product off better? I don’t really think so.
So, clearly there were enough people willing to spend some bucks on the smaller iPhone, but the price reduction should be enough to not only allow those folks to buy the iPhone, but also spend a little bit more than they were going to originally.
I wonder if this applies to Web applications? It would probably be a little tricker to execute, but you could do it. If you had two streams of a subscription product and wanted to EOL one of them, you could totally drop the price of the bigger / badder stream to catch the customers that were either about to purchase the smaller one, or in the process of thinking about the smaller one.
But, the tricky part is, because the subscription isn’t tangible, do you get the same effect? Well, the upgrade would work the same. You keep the limited functionality of the lesser-price subscription stream around indefinitely, and offer users that just bought the cheaper one 30 days ago (for example) a free upgrade for 6 months or something.
Very cool stuff. Well-executed product marketing strategies right before our eyes.
Now, if I lost my mind and bought a “Vista-ready” PC, would I go for Vista flavor 1 or 8? Hmmmm….see, there are never-ending arguments to Apple vs. Microsoft. But the one that’s ultimate for me is one of slickness / sexiness and this iPhone EOL is case in point.
The product and strategy are so damn slick, that no one even really cares they are dropping a product and refunding a small group of customer base. At the end of the day, the customers are still investing in a very cool looking product, which is satisfying. OS X may not have the 1,00,000,000 features Visa versions 1-8 do, but damn it pretty much rocks the core fundamentals of an OS, and looks really good while doing it.
So, while the whole Apple EOL / pricing thing that just happened yesterday is a great lesson to learn from, the other one is, don’t ever discount keeping things simple, and the cool factor.
Growing Up in Process
I’ve been doing a lot of thinking lately. Most of it while in process either executing on tasks with which I am quite familiar, or performing new ones that I’ve only either done a few times before, or not at all.
The funny thing is, I’ve been immersed in Product Management for so long in my own mind, that even when doing something either a) a little differently based on a scenario or b) doing something for the first time in my career, it all feels quite natural.
It’s funny - when I first started out, much of my concern lied with things like, “what does this mean” and “how do I do that?” type stuff. But now, with all the fundamentals in place, it’s getting really exciting to see things play out, and really drive them forward.
One of the best examples of this is introducing stakeholder’s into the feedback process. We’ve been working very diligently on a set of product development projects. They are really fun, and frankly, taxing. Creating a full product from scratch is no easy task, and to do it on short timelines makes it even more difficult.
But, we are prevailing.
Now, getting ready to go live (different then a full-scale launch), it’s time to start circling back in and revving up the feedback cycles & loops for the product itself. And, I’ve been very pleased. While I can’t lay claim to being a complete expert in the process and procedures of gathering feedback, it’s one of those things that I do know how to do.
When you have a product you are proud of, looks sexy, works well, and isn’t 100% perfect (because they never are), it’s so fantastic to hear and see people interact with the thing and listen to what they have to say about it. I always remember reading somewhere, and I can’t express how true this is, that one of the top word’s in a product manager’s vocabulary is “why.”
Getting feedback from someone that says, “gee, your registration sucks” is only 1/2 the feedback. To know why they think it sucks is where you get into extracting value from feedback gathering. Because once you do that, you can leverage the information along with all of your other data, determine if there is in fact a problem with something (in this example, a registration process) and construct a requirement that suitably solves the pain.
Very nice & tidy. It doesn’t have to be long, drawn-out hours-long presentations. The tough part is approaching key people that will provide critical insights before you have a base of users that are really willing to give you a piece of their mind, because they are shelling out hard-earned money for the product.
Listen (no, really listen) to what folks have to say. When criticism or negatives come out, that’s what you want. Don’t jump to the defense of the product, because that just turns in to you jumping to your own defense.
Like anything, practice makes perfect, but before rolling out for the first time, really make sure that all key players involved are fully behind your choices and decisions as a product manager. They won’t agree 100% of time, but where’s the fun in that?
So long as you have the data to justify and back-up your calls while in the thick of the product development cycle will prove that you really do know what you’re doing, and quite honestly their instinct is misplaced & goes against the greater good.
Competitive Exploits
Our marketing team just put together at fantastic competitive analysis for some top products in a space we are going to be aggressively pursuing. The major thing I look for in a competitive analysis is how easy it is for me to extract exploits.
I need to be able to read through the analysis, no matter what the format is, and be able to say, “competitor A doesn’t do x, y, and z as well as we do” for each company in the block. There are a multitude of different ways more deeper analysis and strategic planning can be completed (read: SWOTs), but, for time-sensitive stuff where you want the data and it needs to make it easy to verify market data and allow you to find weaknesses in what’s already out there, that’s what rocks.
There isn’t a specific art to it either. In order to do it correctly and well, you must be intimately familiar with your not only the core competencies of your product, but also your company as a whole.
Really, all you want to do is jot down bullet points that are geared towards getting some cross-functional folks (namely product mgmt and marketing) on board with making sure the messaging to clear, and functionality is clear when applicable, to win over the existing user’s of product’s that are probably feeling the pain of using them.
How are you working to find out how your products can solve the pain of your user’s better than your competitors?
