Now, I’m no expert in product management. But let’s be honest, if we sat around and waited for me to write only on things at which I am expert, we’d all be in for a long, cold wait. So, all of that aside, I do know a number of good product managers. I’m even luckier to know a couple of exemplary product managers.
And because of that, I’ve gleaned–at a very high level–some insight on product management. I mean, I’ve spent a lot (a lot) of time sitting in product management meetings and listening. My primary contribution to product management meetings?
- Meeting #1: “When are we scheduled to launch? What’s the date?”
- Meeting #2-#999999: “Does that affect the launch date? Is the launch date slipping?”
Yes, vital component. That’s me.
But it’s good. Because when I keep my trap shut, I actually listen, so I’ve managed to pick up a few things here and there.
And here’s where the worm begins to turn.
So, the other day, I’m staring off into space, thinking about product management, and this occurs to me: Everything is a product management problem.
Let me outline some of the high points:
- Time line / Road map / Life cycle. Every product has one. The really good ones detail the life of the product, from conception through demise. On it, you can see every upgrade, every feature, every release, every date. Everything that will happen to that product. This is the plan. For the entire product. Everything that happens occurs here so that it can be seen in the context of the product life.
- Trade offs. This is the product manager’s preeminent skill. Everything in product management is a series of trade offs. When is that resource available to build that functionality? Regardless of when that functionality is built, when do we release it? What does the market want? What does the company want? What do we do to incorporate this last minute requirement? How do we retool based on the usability tests? Everything is a balancing act for the product manager. You can’t do everything at once. And you can’t do everything before launch. It’s a constant game of ready, fire, aim. What is attainable versus what is necessary.
- Resource management. Once locked, loaded, and focused on target, how do we manage the resources at our disposal? Are we going to wedge in some additional functionality while we have engineering cycles? Are we going to bring in outside help to get us through this rough patch? Can we rely on a single engineer to bring everything to fruition? What if that person falls ill during QA? How much do I have to spend to get this done? Can I buy time?
- Translation. The product manager is a Rosetta stone of sorts. Sitting somewhere between the business aspects of having a product and the labor required to bring that product to fruition. In high-tech, as an example, engineers don’t generally want to hear about the business reasons behind feature #479. They want to know the spec and they want to know what technology is at their disposal to create the feature to spec. Conversely, the CEO generally couldn’t really care less if you’ve created an AJAX implementation or used C#. S/he wants to know if the customer will be jumping for joy or throwing up all over it.
So taking those high-level points, shouldn’t we all be product managers?
I mean, couldn’t your career use some product management? A time line? A life cycle? An attainable list of features and functions to be launched at specific intervals? What does version 3.5 of your career include? Is it Windows and MacOS compatible? Where are your feature/function gaps that could move your career forward or doom it to inadequacy? What features do you want versus what functions does the business want? What happens when a competitor enters the market?
How’s your usability?
Think about it.