Time management is extremely important for PMs. You want to focus your energy on the activities that will have the highest leverage for your customers and team. Over my career (as a software product manager)I’ve wasted a ton of time doing things that felt high-leverage at the time, but didn’t produce lasting value. Below I’ve listed the top ten culprits …

1 . Setting up elaborate systems to collect, track and reply to customer feature requests. I very rarely see this produce value for either customers or teams. I’m not talking specific feedback and research, where you cast a focused net for something you are currently working on. And I’m not talking about lightweight feedback channels that you can query for background info, and even use to recruit customers for research. Rather, I’m talking about the pipe-dream that you’ll somehow open up the forum for feature requests, allow voting, and that this will somehow be helpful in roadmap prioritization. In the end, you just waste everyone’s time (including, most importantly, your customers)

. The volume of feedback just overwhelms the team’s ability to organize and act on the information.

2. Story Point Estimation. I firmly believe in cost of delay estimates. And, I also believe that economic decisions require some sense of the investment necessary for a particular effort. The standard argument behind story point estimation is that it “triggers the right conversations” or “helps us not overcommit” or “helps us stock our sprint.” I think those end-goals (those conversations) are possible without the mind-numbing ritual. There are “good” reasons to estimate, and then a whole host of dysfunctional reasons. Spend more time on the value/outcome side and less time worrying about the difference between one and three day stories and t-shirt sizes.

3. Roadmap fire-drill. I’m all for strategic thinking. I’m all for gathering data and describing some potential points on the horizon. Evolving your strategy should be a continuous activity. Unfortunately, that’s not how it works. Oh no … sales is feeling nervous about the current product and want a “roadmap” (translation, a list of things you will build that they will sell without promising, of course). Oh no … the CEO/founder is about to talk to the board and needs a “roadmap” (translation, all the sexy things that will attract their attention). Oh no … the CTO needs to staff up and make a yearly plan, so they want to know what you have in mind (e.g. need you to have a crystal ball). Here’s a better way. Always maintain a rolling 6 months, 12 months, and 2-year roadmap … not the features you’ll build, but the outcomes you’ll focus on. Don’t play defense. Play offense. Get people what they really need instead of outsourcing product strategy to the rest of the company.

4. Figuring out how to parallelize work and maximize work-in-progress. PMs spend an inordinate amount of time figuring out ways to eek out every minute of developer coding time. “If we reduce the scope of this story, can you take on this other story as well?” “While we wait for feedback on that story, can you start these other three stories?” You’re wasting your time. You are getting too far into the weeds, and if getting that far into the weeds is going to determine your product’s success, you’ve got other things to worry about. So what if someone spends an afternoon refactoring or working down some debt? Is that the end of the world? What you’ll eventually learn is that the more you micro-manage their work, the more the team will optimize around retaining their sanity while being micro-managed. They will create their slack whether you like it or not. Stop playing Tetris with your team.

5. Horse-trading and auctioning the team’s resources. “And 50% of our team will go to you, and 20% to you, and 15% each to these two other projects.” If you are finding yourself saying these things (or thinking these things), you’ll be fighting a big uphill battle for your product. It isn’t a product anymore! You are a project-shop. As a PM, imagine the world where the context and case you build would nullify all of this guessing. You’d make a case that would shut up all the guessing and requests, and people would say “damn, we’re excited for that … keep doing what you’re doing!” AND, you’d engage your team in that journey. I don’t think there is anything inherently wrong with a project-shop if you just call it out as such and call yourself a project manager.

6. Gathering information not applicable to your current initiative. This is similar to #1, but it should be called out. PMs participate in countless meetings that generate information that is simply not actionable in the near-term. We’re told to be “responsive” and to “connect” with different parts of our organization, but again we’re wasting our time and the time of our internal stakeholders. Evangelism and maintaining relationships is important. So the key is to keep it pertinent and guide the conversation to the here-and-now.

7. Communicating to customers through proxies. Whenever possible, you need to go to the source. It’s not that other people (e.g. sales, marketing, customer support) are wrong or don’t provide useful information. Rather you’ll never get to ask the important questions, and you will waste other people’s time trying to get that information. Better yet your team should be there with you on the call. Never hesitate to get on the phone and talk to a customer.

8. Figuring it out in a small group. God forbid the whole team attended a meeting and worked something out! No, instead we arrange “small meetings” to work things out. And then we decide on something, take it to the team, and only then realize that no one is on the same page. Sure, we may meet with a senior dev. And that might be “more efficient” and “less disruptive.” But how will your team ever get better at collaboration when things are a little messy? Again, we work too hard to keep things efficient and spend too little time investing in the resilience and overall performance of the team. Although I don’t think we do this consciously, I believe we try to keep ourselves relevant. These “important” small meetings achieve that.

9. Communicating status when the status hasn’t changed. This behavior is often beyond our control, but as PMs, we spent lots of time telling people how/why things are on track even when nothing has fundamentally changed. Worse yet, we spend far more time communicating status than actually communicating results and outcomes. If all you do is communicate status, then that is all people will expect out of you.

10. Guessing and premature convergence. Everyone is freaking out that they don’t have all the answers. You’re on the spot. What do you do … make shit up (consciously or unconsciously)

. We spend lots of time as PMs persuading people we have things figured out even when we don’t. That’s partially because they are risk averse. And that is partially because we create a conveyor belt of features and need to keep things rolling off the line. Instead of saying “hey, let’s get something in front of customers, and we can kill it if it doesn’t work” we say something like “ok, it looks like we all agree on the direction here, let’s ship it.” Consider how much time you invest keeping up the illusion that you know everything.