Q&A: How should product managers prioritize their time?
Time management is a constant struggle for any
product manager.
The biggest challenge is balancing two very different modes of thinking – the need to execute and the need to think strategically, at the same time. It’s about making sure you’re taking care of the here and now, while still maintaining the long term vision of a product.
We were recently asked how product managers divide their time at Intercom, so we sat down to discuss everything from how we plan our daily goals, to where a product manager’s responsibilities begin and end.
The gravitational forces of product management
You have to fight for the time to plant seeds in your head, which will germinate and grow over time
Brian: If you’re working in a company like Intercom who ship frequently, one of the biggest challenges for a product manager is to escape the gravitational pull towards execution. This pull is a good thing, it’s a sign of a healthy company – it means you’re getting things out the door. But it also means your focus is likely on today and the next couple weeks.
It’s important for any product manager to be able to balance that gravitational pull with strategic thinking. What have you learned recently that should factor into your 6 month roadmap? Have you had time to think what tectonic shifts are happening in your product’s landscape, to think out towards the next few years?
If your team is in constant execution mode, putting some forcing functions in place are a good way of creating time for strategic thinking. But if you put a block of two hours in your calendar every week for “strategic thinking”, it’s just not going to work.
That time will inevitably get eaten up by execution; there will always be some task that feels critical and essential to do now. A commitment to another person to discuss strategy is a much better forcing function.
We have standing weekly meetings with our researchers and our analysts to ensure we’re getting thinking about and pulling in all the critical inputs. These meetings are good opportunities to frame: “Are we asking the right questions? Are we asking big enough questions?”.
Daily and weekly goals are also important to help us prioritize. The volume of stuff that comes into a PM, added to the gravitational pull of seemingly meaningful distractions, makes it essential to have your weekly and daily goals. To put it bluntly – what’s the stuff I’m willing to ignore to get this done today.
Finally, I think it’s important to make time for tasks that have no immediate payoff. You have to fight for the time to plant seeds in your head, which will germinate and grow over time. So things like research, talking to customers etc. Solving the most immediate problems usually feels rewarding, but it won’t lay the best foundations for your future thinking.
Colin: What really helps me prioritize different types of work are the rhythms and cycles we have embedded in our work. As Brian said, daily and weekly goals are great for prioritizing tasks when you’re in execution mode, when there are tasks that need to be done quickly.
But in the last few months we’ve introduced a six week cycle into our engineering team which I’ve found an extremely useful time frame to actually fit in all the activities that a PM needs to take on.
It’s a longer cycle, but a more considerate one. It gives you a good rhythm to plan more strategic tasks. You can devote chunks of time to think deeply about your long term plan in the six week cycle.
Keeping the door open
Brian: The other huge challenge for a PM is figuring out what distractions can be ignored versus what looks like a distraction but is actually something you should really jump on.
A PM’s job is often a hostile environment for all types of incoming requests.
There’s no science to that. It’s about building that ability to say no, while at the same time having the flexibility to say, “Hang on, my plan for tomorrow is totally wrong. I need to focus on this new thing that’s only just come across my desk.”
That’s a really hard thing to do, but the PM’s job is not one to shut the door and say, “Here’s my week. This is what I’m doing all week.” The PM’s job is to be reasonably open to what’s going on around them.
A big part of keeping the door open is being open and available for impromptu chats. Those unplanned chats while getting a coffee in the canteen can be incredibly valuable. Sure, some of them are throwaway chit chat, but I’ve consistently been surprised at how frequently they are valuable. A part of the PM’s job is to be visible.
Colin: When we were building our composer, people talked about it as something that had to operate in a hostile environment. It’s an environment that has to handle all types of input – you write in it, cut, paste, and copy text, etc.
I feel like a PM’s job is like that – a hostile environment for all types of incoming requests. They can come from anywhere and you can be sure they’re all going to come in at one point or another. It’s about figuring out what one is important to deal with, while still making sure you’re making some progress towards the goals you’re setting yourself.
Something we have used successfully is having three tasks each day to get done, or three objectives each week to achieve. At the start of each day I will allot time specifically to get those done first and then fill the smaller tasks around it. It’s like when you put the big stones in first when you’re filling a container, and let the little ones fall in around it.
Being deliberate vs being reactive
Colin: What I’ve learned from being the only product manager to Intercom, to a team of 10+ product managers, is that you really need to try to bake some structure into your day.
Earlier in my PM career, I definitely prioritized the urgent but ultimately less important tasks. By continually adding a little bit more structure to my day, I can accomplish the more important but not necessarily urgent tasks as well.
Brian: It comes to a question – are you being deliberate or are you being reactive? It’s so easy to be reactive because it easily justifies itself as important. You need to be deliberate enough to say, “Even though I know this incoming stuff is important, I’m going to say no, because I know I need to focus on the other stuff.” If the more strategic and longer term view continues to suffer, then ultimately it will be worse for the team.
Being deliberate also means being realistic in your daily and weekly goals. The constant temptation is to make a long list of shit to do and choose five or ten items to do, not one or three. That’s still hard for me. I still have to restrict my goals for the day.
Colin: I think it’s crucial to understand how the PM role fits into your particular organization, to better understand what you should prioritize. For example, if it’s a design mature organization, you might be doing no wireframing. But if there’s no designer you might be the primary person looking after design, so obviously you’ll need to spend time there. Figuring out how the PM role fit to your organization is going to help you figure out what’s the pieces you need to prioritize.
Brian: Yeah, I think the PM role very much feels like: “What does your team need, what does your company need?” In the earliest stages of your company, that usually means everything. QA, a little bit of design, some research and some product management stuff thrown in.
Then as your company grows and gets bigger you can actually focus on what’s seemingly core PM stuff. But from my perspective, and from yours as well Colin, you do what’s needed, not what theoretically a PM should be doing.
Colin: I think it’s also worth spending time defining that, and being in agreement with the company or your boss, to say: “These are the seven things I’m going to concentrate on, and the others may not get done.” Otherwise stuff will come at you all the time. That design is not right, or this technical specification doesn’t make sense etc.
Our own definition has changed for us over the years. Early on, Intercom hired design orientated PM’s, and we tended to get too involved in the design stage.
Over the past few years, we’ve created clearer responsibilities. For example the product manager is responsible for the problem definition, and the designer is ultimately responsible for solution definition. You’re very much involved in the solution definition stage, but the areas of ownership are much more clearly defined.
