When it comes to choosing what to work on in a busy and highly-demanding position as a product manager at a technology company, it’s incredibly important to choose wisely. As I noted in my previous post detailing the types of wasteful choices many managers fall for, this choice can lead to either fruitful gains for the enterprise or terrible falls.
But if you stick to the basics and work hard at the main tasks you’re getting paid for, you will be successful.
Below are the things I think you should focus on, with instructions about how to do so.
This is obvious, but goes beyond the basics of value proposition, features and customers.
To start, think hard about how every step of your product actually works. 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, I believe, think about “understanding” their product solely from a basic technical familiarity standpoint. But you should also 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? Thinking about your holistic “product surface” this way can lead to new ways of envisioning how your product can deliver business value.
As just one example, one product I used to manage was focused mainly on marketing analysts. In our customer research, we realized many of our users were using the export feature to send report summaries to their managers and company leadership, but that those executives had a difficult time understanding what they were seeing without context. This led our product team to design a new “Executive Summary” report with a simple, one-click export feature that not only simplified the reports with better labeling, but also streamlined the exporting process itself. Guess what? It was a big hit. Not only did our users love the feature, but they reported their bosses began requesting similar reporting, making our product more central to their work.
Companies, particularly big ones, are the sum result of their processes. I would even go so far as to write that individual contributors matter less to most companies than the processes and systems they’re placed into and develop.
Think about the role of the product manager in its most direct sense — you have most exposure to the development process. So, ask yourself how you ideate, plan, scope, prioritize, build, deploy and service new updates or features. Another question to ask, is how to improve that process in terms of quality, speed, communication and value. While you may think this might be most of your development manager’s turf, it actually all impacts the product , which makes it your responsibility too.
Sales cadences are a similar example . Ask how Sales teams work with Marketing and Product to ramp up. For example, figure out which meetings are necessary, which aren’t, and which should be changed (and how). One more: think about how you review your own team processes and ensure you hear from the many voices of your team. This kind of change can be uncomfortable and, frankly, a pain in the ass — but growth always is and you have to do it to stay on top.
A good practice to get into to improve the process is a quarterly review of the standing meetings on your calendar. Ask yourself how many of these produce actionable results for you and other attendees and how many are simply for information-sharing. The latter, in fact, could potentially be better, and more efficiently done, in email or chat form. Proposing to nix unproductive uses of time like the latter can be a little awkward, but represent the growing pains of a company culture learning to make its processes more productive.
Telling the Brass What It Doesn’t Want to Hear
Yeah — this is not my favorite option, 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 product manager 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 product manager, 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.
One of the least pleasant, but most important, jobs of a product manager is to raise the alert when a planned feature or project’s delivery date slips. This inevitably happens with any product of any significance or longevity, and someone has to deliver the bad news to the folks who need to know, like the sales team or leadership. If you’re the Product Manager, then that someone is you. My advice: don’t avoid this. Grin and lean into the discomfort. By delivering this news forthrightly and with a plan to correct it, you can actually build trust with those other teams, who know that you can be counted on for reliable guidance.
Don’t Forget: Avoid Distractions and Focus
Look, as I noted in the last article, it’s not super realistic for any busy product manager to be able to dodge all distractions that head your way, all the time. But to the extent you can be more intentional in what you spend your precious time on, you will be more effective in your role. And effectiveness, as the cousin of efficiency, and success, will lead you to a more productive and happy career as a manager in the technology industry.