Protect Your Time

Having been in the product management game for a quarter century now, I have one piece of advice to share: PROTECT YOUR TIME.

Seriously, you live and die by your calendar, and once you lose control of that, you are basically screwed. I am sure you know people who live in meetings, who complain about back-to-back-to-back meetings, but many of these people are what we refer to as “People Managers”. That is, their “value” to the organization is that they oversee a team who they are responsible for to deliver results that align to business or strategic objectives. In fact, as a people manager, you are that glue between lofty organizational goals and your team’s day to day that delivers against those goals.

Or, more simply, your key job is keeping the team aligned, on track, and motivated, handling any exceptions, and managing up that your team is delivering the goods. Regardless of how much you complain about meetings, they really are a significant part of your remit.

But, as a product manager, you most likely do not have a staff, and thus an hour in meetings, is an hour you are not doing discovery, documentation, strategic alignment, or anything else that leadership expects out of you.

Thus, it behooves you to protect your calendar.

But how?

I mean, the product manager in most organizations is the go-to person for many groups, sales will want the PM to help with difficult deals, marketing needs help to create messaging, engineering needs well defined requirements, or a backlog for development that is fresh, relevant and properly prioritized, Finance will be looking for forecast and performance data - well, you get the idea. In a healthy organization, the product manager is a one stop shop, and the first port of call when some executive gets an itch that needs to be scratched (with data).

And that means that your time will be partitioned up, quantized, and stuffed to capacity, leaving little time to get into a cadence to deliver on what your day job requires.

Thank you for reading The Product Bistro. This post is public so feel free to share it.

Time Blocks

The first tip is to drop some blockers on to your calendar. May I suggest adding 90 minutes for lunch as the first step. Early, late, whatever, just drop it as a recurring appointment and try to stick to it. If people are ignoring it, set it to the “Out of Office” status. Believe me, this helps.

Then pick an afternoon or morning that is mostly free week to week and block it. 2 hours minimum1. Treat this as sacrosanct. This is the time to turn off your Slack, your email, and hide your phone. If you are in an office that day, book a conference room. Get away from your desk.

If you can get away with having two or more of these on your calendar every week, you’re in good shape.

Identify a ‘Meeting Light’ Day

It is becoming more common that companies or groups within a company will designate a day that they encourage the staff to not schedule meetings unless it is urgent. This usually means that no regularly scheduled or standing meetings on the calendar. If you are lucky enough to work in this situation, rock on Garth.

But even if there isn’t a policy of this, you can build it. Use your blocking skills, and learn to say “No” to meetings that you really don’t need to be at.

I get that it is difficult at times to say no. But, if I didn’t say no to many of the meeting requests that I receive, I would need to clone myself at least 2 times to attend them  all.

Just say No

While I am not a fan of the former first lady, one thing I can agree with Nancy Reagan on is that just saying “No” can be empowering.

Product Managers are looped in on way too many things, and many of our first instincts are to just keep piling on. Perhaps when you are new in role, you can just keep on accepting these stray things, be it meetings, or tactical items, but what you are really doing is setting expectations that you will be able to scale indefinitely.

This reminds me of an analogy I heard a while back. We were interviewing a candidate for our director of engineering position, and the candidate formerly worked for our chief competitor. Our product was built to run on Windows (the NT 4.0 version) and theirs was based on HPUX, a Unix operating system. In the manner of our discussion we got to comparable performance between the two systems, and the pros and cons. The candidate uttered something that sticks with me to this day.

Our system, based on Windows, when it got to a certain level of resource loading, would just toss in the towel, and throw a blue scree of death once memory got to some ridiculously low level free, forcing the user to restart and rethink their use.

But their system, based on Unix, would just get incrementally slower and slower, using paged memory to disk (and if you remember when 8 megabytes of main RAM was luxurious, you probably are an Old Fart(tm)) to handle overutilization, and suddenly the load was pegged at .99 and if you are familiar with Unix or Linux, that is not a very good place to be. So it would just get really sloooooooooooooooow.

And users hated that, hence why our “failing” and requiring the user to start again was a winning feature against our competitor.

But in a way, that is like Product Management. If you behave like a Unix system, grinding to a glacial paced crawl when overloaded, you are going to go crazy, burn out, and quit to run a Yoga Studio in some college town in the mid-west.

But, if you pull the BSOD equivalent, you will - against your instincts - be training your peers and colleagues that there is a limit, and that they need to respect that limit.

The bonus is that you will be in a healthy place.

Burnout is real, it is bad, protect yourself.