I recently started to work with the product guild at a well-known company that is about to go public. In our sessions, they raise the challenges that they are facing in their day-to-day job and get my advice so that they can bring their product leadership to the next level.

One of the first topics that came up (it always does) is time management. We are so busy that we don’t have time to raise the bar and do the important things that we all know we need to do. I sent the team to watch my time management lecture (if you don’t speak Hebrew or prefer reading there is an English summary here).

At the next session, one of the product managers said that he watched the lecture and started implementing the advice I gave there, but when he started managing his calendar he saw that about 70% of his time is already booked with regular, recurring meetings every week. Challenging indeed! It leaves no buffers for the unexpected and no time to do “real” work, which is usually the name for work that we need to do on our own, as opposed to just sitting in meetings and helping others make progress. This question developed into a long, in-depth discussion on time management for product managers. I gathered the best advice here for you.

Nothing Happens If You Skip a Meeting Here and There

Take a look at your calendar. Not on the following 2 weeks, but later, when all you have there are your recurring meetings. Now check for each and every one of them, are they necessary? Most likely the answer will be yes, but are they necessary at the cadence that they are at? And at the length that they are currently at?

When I was at eBay and managed a large product team, I used to meet with each of my PMs for an hour every week. It was aligned with my management style – I wanted to make sure that I am there for my people and can help them with whatever they needed. At some point, however, this became too much. When I looked at my calendar as I suggested above, about 30% of the time was dedicated to 1:1 meetings that occur on a regular basis (with my team or my colleagues). These 1:1 meetings were all generally important, but as with everything else in life, 80% of their value could be achieved with 20% of the effort. In my case, I decided to cut it in half: instead of meeting with each of my team members for an hour every week, we moved to 30 minutes, and 1:1s that happened with colleagues were reduced to lower frequency (every other week up to once a month, depending on the function and the dependency level between us). To make sure they still get what they need, I created other mechanisms, like weekly emails with all relevant progress and plan updates. 

The same is true for larger meetings as well. For example, when I was still working with a scrum team, I would skip the daily scrum meetings occasionally. I tried to make sure I attend them at least 2-3 times a week to keep the sync going, but if I missed a single meeting nothing happened. 

Last but not least – when someone asks to schedule a meeting with you (and assuming both the meeting is needed and you are needed there), instead of looking for the nearest time to have it, stop to think if you can afford to have it at this time. It is not just about whether or not you can find the time in your calendar, because your “real work” time doesn’t necessarily appear there (although that’s my recommendation). Think if you can deal with it this week. Is it aligned with what you are trying to accomplish? If not, can you do it on top of the other things you need to do? 

Try to make your default scheduling option a few days away or next week. If people need you sooner than that, they will say so. But in the many cases they won’t, you will have some breathing room in your calendar, to get to what you really want and need to do.

Feeding the R&D Beast Is a Joint Effort

When I was a young development team lead, my boss explained to me that my #1 priority should be to make sure the team always has work to do. Having a developer sitting and waiting for work is generally a bad idea, and it was up to me as their manager to make sure that it doesn’t happen.

As product leaders, we want to make sure that not only all the developers have work to do, but that it’s the right work to do – both in terms of prioritization of features and in terms of the specifications themselves.

Doing that when working for example with two large scrum teams that work in 2-week sprints is a lot of work. It means that you as the product manager either become the bottleneck or work only on that 90% of your time, and we know that this is not what you really want.

Many product managers don’t count themselves when they think about the team’s velocity. It is almost given that the team will move as fast as the developers can go. But the product manager is part of the team as well, and it doesn’t make sense to assume that they will serve whatever the developers need on time simply to not cause a delay. Don’t get me wrong, when it works it’s great, but if you are indeed the bottleneck, don’t assume that this is your problem to solve on your own. This is the team’s problem.

Once you view it this way, there is a variety of solutions. Here are a few:

Deliver less detailed requirements to the development team, and let them engage in the conversation and further definition of the feature. You can help them make the right decisions by educating them on how you view things and focus your preparation on the context and goals that are fully your responsibility.

Another option is to create a mix between functional and technical improvements, assuming the technical improvements require less of your guidance. For example, let them work on technical debt or bug fixes if you are not ready with the next feature for them. It is not necessarily the ideal prioritization, but it is a realistic one, that still makes good use of their time.

You can appoint someone from the team to help you. If they aspire to become product managers, this can work well for everyone. This way you will be able to focus on the work that matters most, and let that person take some of the load off of you.

These are just examples. The most important thing is to remember that you are part of the team, and your capacity is limited just as much as theirs. It doesn’t really help if you work just on that to be able to deliver your part on time. Not only will you burn yourself down really quick, but you will also not be able to get the real product work that makes sure that they continue working on the right things, at the highest level.

You win as a team and you lose as a team. Make yourself part of the team and let others help you.