Getting Things Done as a Product Manager

How to stay on top of your to-do list

In this article, I will share some tips for remaining organized, ensuring nothing slips through the cracks, and prioritizing the most important work.

Product managers are notoriously busy. Between discovery work, delivery work, stakeholder management, and collecting inputs and feedback from across the organization, it can be hard to keep track of everything you are supposed to do, while also having enough time to plan ahead and think about the future of the product.

Establish a leak-proof collection system

Task management starts with a leak-proof collection system. The collection system consists of a few “approved” collection points for tasks. Typically, these will include your email inbox and Slack, but could also include physical collection points like paper on your desk, or a notebook. What’s important is that these collection points can permanently hold incoming tasks until you have triaged them.

The mind is a popular but “unapproved” collection point (since it doesn’t satisfy the permanence requirement). When you think of something you need to do, write it down in one of the approved collection points.

Triage incoming tasks

The items in the collection points are then regularly triaged. To make it sound less fancy, this most often means “reading your emails and messages”.

Triaging means processing the items from the collection points into a single task list and your calendar. The single task list means you only have one place to look for what you need to do. The calendar is for time-bound activities.

The most important advice for triaging is to touch items only once. Every item should be either discarded, immediately acted on, or moved to task list or calendar. Items that take less than a couple of minutes should simply be immediately done (e.g., firing off a quick response). Anything bigger should first go to the task list so it can be prioritized appropriately.

Touching items only once means not marking things “unread” — instead, you can add a link to the item to your task list to come back later. The same goes for functionalities like “snoozing” emails or asking Slack to remind you of a message. The disadvantage of these features is that they will slow down future triage since they add items to triage, and that they are “hidden” task list items that remove transparency from your task prioritization.

I’ve found it most effective to start the day with triaging, and then repeating the process over the course of the day when I’m in between tasks. As a product manager, there is a fine balance to strike between being responsive (i.e. triaging often) and being able to get work done in an uninterrupted manner, so you may need to experiment with how frequently you triage incoming items.

Alright. Now we’ve got all tasks sorted into task list and calendar. Now we just execute, right? Not so fast…

Weekly review and planning

Even though collection points, triaging, and a single task list makes sure that no tasks get missed, product managers often simply have more to do than they can realistically get to. Therefore, some more planning and prioritization is required.

The most useful way that I have found for doing that is doing a weekly review and planning. I combine this with sending a weekly summary email, but the weekly review works without the email, too. The weekly review happens at the end of the week and has as its output the 3–5 top priorities for the next week.

How do you come up with these top priorities? Often it’s quite straight-forward: think of the next milestones to achieve for each of the projects or work streams you are working on. Another way to think about these priorities is to think about the various time horizons and project lifecycle phases: strategy, product discovery, execution. What do you want to achieve for each of those in the next week?

Once you have established these priorities, keep them close to your task list, so that you can use them to prioritize the tasks on the list.

The weekly review and planning is also a great opportunity to review your calendar. Product managers live in an awkward space between manager schedule and maker schedule. Often, the job demands quite a few meetings (with team, customers, leadership, stakeholders,…). On the other hand, product managers also need to do some actual work, like writing out product specs. Having the day disrupted with too many meetings can make it hard to get that work done without working overtime.

While weekly planning can’t completely avoid this (hint: work at a company with an async-first culture to reduce meetings!), it can certainly help deal with it.

Firstly, see if all meetings on your calendar need to happen and you need to be a part of them. Is it clear what each of the meetings is trying to achieve? If not, try to clarify it. If it is, are you absolutely required?

Secondly, try to see if you can batch meetings. A bunch of meetings back to back followed by working time is more effective than if meetings are scattered throughout the day. You might not be able to move all meetings, but perhaps you can move those that you can control between those you can’t. (My personal tip is to try and be the owner of as many of the meetings on your calendar as possible; I find that having the flexibility of being able to reschedule outweighs the initial time investment of being the one who schedules and sends the invite).

The last tip, particularly in organizations where you have to expect lots of last minute meeting invites, is to schedule blocks for uninterrupted deep work. This could be just general blocks you book in your calendar, or you could book time for specific priorities you have identified in your weekly planning (e.g., “write spec for feature XYZ”).

Daily planning and task prioritization

Once the priorities for the week have been established, on a day-to-day basis, you deliver on these priorities. Practically, if you have 3–5 priorities for the week, I would recommend trying to make substantial progress on at least one priority item per day (instead of trying to nudge them all along in parallel).

In terms of actually prioritizing tasks, the first principle is to secure your own projects before helping others. While it’s good to be helpful and demonstrate ownership even outside of your immediate area of responsibility, you will be judged on achieving your own and your team’s objectives first and foremost. So if you are falling behind with respect to what you are directly expected to do, you should push back against additional demands on your time.

With that out of the way, there will still be several tasks that you could be doing at any given point in time. In addition, for most of the tasks on your list, there are various ways in which you could get them done, from the minimum level of work you could do to a very thorough and diligent version. There isn’t one all-encompassing way to decide which task to tackle when and with how much effort, but here are a few tools for thinking about task priorities.

The most well-known way is probably the Eisenhower matrix, in which each tasks is categorized in a 2x2 matrix of urgency and importance:

• High-urgency, high-importance tasks get done right away
• Low-urgency, high-importance tasks get scheduled or addressed once everything in the first category is done
• High-urgency, low-importance tasks get delegated if possible (i.e. find someone for whom this task is of higher importance)
• Low-urgency, low-importance tasks get deleted

With respect to thinking about what to do yourself and what to ask others, it’s also worth thinking about your capability and energy. Capability means how good you are at doing the task, and how good someone else would be. If you can do the task a lot better than anyone else, that’s a reason to do it yourself, whereas tasks that someone else can do a lot better you should delegate more often. Another dimension is energy (or enjoyment, fun): do you enjoy doing the task? Does it give you energy or does it cost you energy? To maintain motivation, it is important to maximize the amount of time spent on tasks giving you energy. That can sometimes mean spending some extra time on tasks that you shouldn’t otherwise prioritize highly, just because they refill your tank. You just shouldn’t overdo that and not get to the crucial but energy-draining tasks.

Another version to think about prioritizing tasks is cost of delay. Cost of delay is usually associated with project planning, but it can work for individual tasks as well. Try to consider what the implications are of delaying a task — often these will not be financial costs but they could be project delays, additional effort to be invested later, organizational capital that needs to be spent, etc.

Similarly, you can think of the critical path for your projects. The critical path is the sequence of dependent activities that determines the overall duration of the project. Delaying activities on the critical path delays the overall project. Delaying activities not on the critical path does not (unless they become delayed so much that they become part of the critical path). Therefore, critical path tasks should be prioritized over other tasks. In reality, that’s often pretty intuitive: providing feedback to an engineer who is waiting for a clarification from product is higher priority than writing a detailed ticket that’s going to be sitting in the backlog for a while, because the engineer is blocked and won’t be able to make progress, but delaying the ticket-writing isn’t blocking any progress.

One other way of thinking about tasks and their priority is the LNO framework. The LNO framework categorizes tasks into one of three categories:

• Leverage tasks multiply your impact (10x); these tasks should be done excellently at times when your energy is highest. Examples include strategic and concept work and ensuring team alignment (anything that your inputs and decisions move large parts of the organization).
• Neutral tasks deliver incremental impact (1x); for these tasks you should do a strictly good job (but no better) at times when you have an average amount of energy. Examples include writing detailed tickets, putting the finishing touches on specs, testing and reviewing, etc.
• Overhead tasks are the necessary evils and distractions (<1x impact); for these tasks you should try to do them with as little effort as possible, actively trying to do a bad job. Examples of these include box-ticking processes, status updates, expense reports, etc.

And that’s it! It might sound like a lot, and prioritization is often more of an art than a science, so what’s most important is to be deliberate, get many reps, and improve over time.

Useful expansions of the task list

There are a few useful expansions of the task list that I have found to work well:

“Done” list: Instead of ticking off / removing items from the list, I move them to the “Done” list. At the end of the week, the “Done” list helps me reflect on what I have done that week — then I clear it.

“Follow up” list: Often, you have tasks where you are waiting to hear back from someone. For example, you might have sent a document out for review, you might have asked a question that you need an answer for, or you might have delegated a task and need to check in on the completion. These are all tasks, but not tasks you can just prioritize and “do”. In order to not clog up your main task list, you can create a separate list just for those follow-up items, and then review it once a day or so.

“Backlog”: There are some items that aren’t concrete tasks right now, but things that you would like to eventually do. For these, I keep a separate backlog, and review that infrequently (e.g., weekly) to see if any of them should be put on the list for the coming week.

Putting this into practice

As a last point, I just wanted to share how I actually put this into action. I use Trello to manage my tasks, and I have a board with 5 lists: Backlog, Weekly priorities, This week, Follow-up, Done. The “Weekly priorities” list doesn’t contain tasks, it contains cards with my 3–5 priorities for that week, just so that I can always refer back to them.

I hope this was useful. Happy task managing and executing!

Note: some of the practices described in this article resemble the GTD methodology. Interestingly, I have never followed the methodology. It is only in the research for this article that I realized how similar some of the practices I have landed on through trial and error and advice I’ve been given are to the ideas of GTD.

I hope you found this article useful. If you did, feel free to follow me on Twitter where I share thoughts and articles on product management and leadership.