Say "no" to "denial of service" scheduling
As product managers, we can get pulled in multiple directions by stakeholders who aren't even aware of each other. Our central role and broad accountabilities may lead us to believe that we need to be involved in all aspects of the product, business, functional and technical. I learned the hard way that the inability to regularly perform "brutal triage" on requests for your time can unleash a chain of events that undermines your credibility quickly and disastrously. A few tips:- You can't be involved in everything. Having someone else, even from another organizational function like engineering, represent you, even at customer-facing meetings, may help others develop and allow you to focus on more critical immediate priorities.
- Look at your schedule every day and mark-up the meetings/activities that are strategic in nature. If you're not doing something strategic almost every day, there's a good chance you've been sucked into an operational death march at the expense of what your core competency should be: defining and driving product strategy.
- Be prepared to show clearly the opportunity costs involved when you have to resolve scheduling conflicts. Most of us have honed a similar skill when it comes to adding scope to a release ("OK. Now let's discuss what drops out.")
- Keep track weekly of roughly how much time you spend on key initiatives and make sure your investment is commensurate with their importance.
Say "no" to other professionals who expect you to do their jobs
Lots of lip service is paid to product managers' standing up and doing whatever's necessary to ensure product success, including doing marketing, support, sales or whatever else is required in a given situation. While these heroics may indeed be necessary from time to time, given the workload of all the product managers I know, consistently picking up the slack left by other disciplines is a recipe for disaster. Much better is to clearly articulate what you expect from these people and organizations and work with these other functions and their leadership to secure the necessary commitments. If these negotiations don't bear fruit, be prepared to articulate the impact of this work's not being done. In this unfortunate case, prioritize the gaps and do what is reasonable to fill them, never forgetting that neglecting your core duties to compensate for lack of organizational interest or investment is yet another (typically even more painful way) way to fail.Say "no" to forgoing your life for your job
This one obviously isn't specific to product managers (perhaps the others aren't either). One thought that helps keep my priorities straight with respect to work/life balance is the realization that my grandkids won't care a bit about the projects I delivered during my career. Truth be told, there's a really good chance that I won't either! How much of yourself you give to your job and how much you give to the rest of your life is, over time, a decision.
What do you think? What other "dimensions of no" can you think of?
See my site for more information on my consulting and training services.
Thanks for a timely reminder, Greg.
ReplyDeleteAt the risk of over-simplification, I am of the view that most of it stems from our inability to see that we are constantly multi-tasking and consequently, switching contexts. And multi-tasking has been conclusively proven via several studies to be counter-productive to the pursuit of goals. So, I guess the key is to be conscious and constantly urge oneself "Do not multitask. Let me give my best to the current work at hand". This will be my personal takeaway for 2016.
Coming to the topic of Saying No, I have come across in my experience that signing up a large paying customer early in the product cycle (such as an early adopter) most often leads the original product strategy astray, due to resource commitments assigned to the customer, who is most likely interested in solving their specific problem (suiting their specific context). Though it is a very, very tough call to say No (especially at the early stage and if you are a small company with limited resources), I would say that in the larger interests of the wider market (for the solution that your product will ultimately provide), the Product Owner should be able to say No for such deals.