On any given day in my job, I probably work on three or four broadly-defined “projects.” I know that this isn’t optimal. The mantra of productivity is “focus,” and yet very few of us actually do that. The reality is that, particularly as product managers, we don’t get to pick when fires need putting out, requests need comebacks, and due dates roll around. So we necessarily jump from task to task. No where is this more true than for PMs in big enterprise software companies.
Don’t worry — this isn’t another reminder about the power of saying “No.” (Though that is incredibly important. Go ahead and decline that meeting!) Rather, it’s about where, in my view, enterprise PMs see the best return on their time spent. Time is your most precious resource, after all — and yet it’s the one most widely squandered, too.
One problem with Product Management as a business function is that it’s very easy to attribute to it basically all functions of a business. (“What isn’t product management’s responsibility?”) This can be (sort of) true for little companies, but I think it’s usually a cop-out. Allotting these tasks to properly dedicated people is a key aspect to successfully scaling a small business into a larger one — or making sure a big firm (like ours) fires on all cylinders.
Here are the top four things I see Product Managers waste their time on.
Obsessing over your market and competition. Every good PM knows his or her market and competition very well. But lots of firms heavily over-index on energy spent on competitive intel. PM and Sales needs competitive information to position the product and sell, but every hour you spend ruminating over your competitor’s latest white paper is an hour you didn’t spend improving your product. If pressed, I’d aim for a 1:5 ratio between this and improving my process (see below).
Your Marketing. I’ve done product marketing, and been a PM where we had tremendous marketing support, as well when it was piss-poor. The results are stark. Done correctly, product and brand marketing can be a force-multiplier-booster-pack for you. Done poorly (or not at all), it’s like riding a bicycle while towing a 747. Yet product marketing can’t be the PM’s job. I find that folks often underestimate how big a job good product marketing can be, and when you ask the PM team to do it in addition to managing the product, you get halfsies results on both. (Which means neither is really done right.)
Sales. If you’ve read my other stuff on enterprise product management, you know that I strongly believe that sales is everyone’s job. But, okay — it’s more some people’s job than others. How much time enterprise PMs spend helping sales could be a whole blog post unto itself, but I typically see two good uses of PMs’ time here: sales training and “pragmatic” client visits gathering input. In certain cases with high-value opportunities, PMs can be useful in closing deals; but they might not be, too. You usually don’t really know (and neither does the seller). Yet the pressure to hit numbers and close deals can be tremendous, and can draw PMs out on the road more than is really necessary.
Meetings. We’ve all heard the business-y cliche below, right?
Okay, yes. But it’s true! This is famously hard for big companies to control, and unfortunately it exploits a key human frailty — our aversion to seeming rude. Well, my advice is — be rude! Okay — don’t actually be rude, but decline meetings and leave them early when you’re not getting or adding any more value. Not all of us can do this all the time, of course. (I’m not declining any meetings with my boss, or her boss, etc.) But what meetings you take, stay or participate in is ultimately a choice you make with your limited working time. It’s no one’s job but yours to make it count.
The stuff that floats to the top of our priority lists are often the squeakiest wheels, like these four. This is just a natural feature of our psychology, but it’s not always the stuff that really helps us add value.
By contrast, here are the three things almost any PM should spend more of their time focusing on.
The Product. This is obvious, but goes beyond the basics of value prop, features and customers. How does every step of your product actually work? If it’s a solution sale, how does one component relate to the others? What kind of product or platform ecosystem does it exist in, and how well do you understand those other parts? (This can get really complex, particularly for those of us in enterprise software.) Too many PMs think about “understanding” their product solely from a basic technical familiarity standpoint. Think about your “product” from a more holistic angle, encompassing your brand, company interactions, implementation and service standpoint too. Don’t just think about how your user experiences the product — how about his/her colleagues? Their boss? Their direct reports? This can lead in a lot of interesting directions.
Your Process. Companies, particularly big ones, are the sum result of their processes. I would even go so far as to say that individual contributors matter less to most companies than the processes and systems they’re placed into (and develop). As a PM, you have most direct exposure to the development process. How do you ideate, plan, scope, prioritize, build, deploy and service new updates or features? How do you improve that process in terms of quality, speed, communication and value? This might be your development manager’s turf, but it all impacts the product — making it your responsibility too. Sales cadences are a similar example — how does Sales work with Marketing and Product to ramp up? Which meetings are necessary, which aren’t, and which should be changed (and how)? How do you review your own team processes and ensure you hear from the many voices on your team? This kind of change can be uncomfortable and, frankly, a pain in the ass — but growth always is.
Telling the brass what it doesn’t want to hear. Yeah — not my favorite, either. This one sucks. But when features slip, or don’t work yet, or integrations turn out to be hairier than expected, everyone is going to look to the PM to carry that message to the higher-ups. Your development manager needs you to have her or his back when s/he delivers a message like that. Similarly, when you’re reviewing business plans or sales goals, the PM, as the one whose eyes should be on more parts of the business than most, needs to be the one to raise flags first and early. In that way, this goes hand-in-hand with the previous point — if the processes are wrong, then the PM should say so. Getting a reputation as being a sourpuss isn’t as big a deal if you also are known as being a truth-teller who doesn’t shovel B.S. around.