I attended a panel with senior engineers and designers discussing the best and worst PM they’ve worked with. Top reason to land on the worst PM category: Product Manager was a slave to the timeline.
I don’t want others to perceive you like that. So, here are a few things about managing timelines that I’ve learned over time, which I hope will help you.
- Establish shared goals. People can only fake it for so long. Working on something they aren’t bought into or signed up for is eventually going to crush their motivation and get them to, willingly or unwillingly, spoil the fun (and timeline) for everyone else.
- Make sure everyone is involved in scoping out the solution. A common mistake I see is PMs defining the UX and coming over to the design team for mocks. The designer should be involved in the problem definition. Same with your engineering team, involve them early and get their input often.
- If their heart ain’t in it, find a way in. If you notice throughout steps 1 and 2 that someone is just really not into it, not interested or excited about the work, this is were you become more of a psychologist/coach/mentor. You should meet with that person and figure out what it is that drives them. What do they care about. Also, what is happening in their lives? Then get creative about how you structure your project to give that person opportunities to work on things that are truly motivating to them. No amount of deadlines will motivate a broken (unmotivated) heart, work on that first.
- Understand their true priorities. This is related to #3, but more specifically about work priorities. Your peers may be overcommitted between your initiative, other PMs asks, their managers ask, execs, responding to user/customer complaints, etc. It may simply be that your project is a low priority for them and they, although really interested in working on it, aren’t able to make time for it. If this is the case, it is an opportunity to work across teams to ensure everyone is aligned on priorities and resources. You may just find that your initiative is not a high-level priority for the organization given what else is going on and, if that’s the case, you can adjust your plans accordingly.
- Never set or pressure a timeline for someone else. The most often mistake I witness is handing over a list of requirements and a deadline that must be met due to some external factor (client requirement, product launch event, etc.) This puts undue pressure on the team to skimp on process to meet the timeline. They will try to “make it work” by considering only the most optimistic path, but the most optimistic path is also the least likely to happen. Instead, give folks a chance to really think through all that’s required to deliver what you as a team are proposing (NOTE: team proposing, not PM asking for) and give you realistic timelines. If the timelines are too long, work with them to reduce the scope.
- The person doing the work should be the one giving the timeline estimates. I think that’s worth repeating, the person doing the work should provide the effort and timeline estimates. Not their boss, their friend, or their mom. Have them sit down and think through what it will take and encourage them to consider what may make them deliver more slowly than they imagine, and have them factor that into their estimate.
- Add buffer, lots of buffer. Someone is going to get sick, or have an emergency, or go through a productivity slump. Or some other critical task or issue may come up that will take away some of their time. Factor those possibilities into your timeline. This is the step where the boss/manager can help a lot. In my experience, while junior team members tend to give optimistic timelines that are too “best case scenario” and tend to miss them, more senior engineers on the team can help adjust expectations based on their experience.
How much buffer? When I worked directly with a team of junior engineers I had a rule of thumb to double the time estimate I got from many engineers. Double. Most of the time, that worked out to be about right. - Understand that timelines may change. How you react to the news of “X is going to be delayed” matters, a lot. You can get stressed and transfer that tension to the team, look unhappy, etc. Or, you can smile and ask the team to problem solve with you. “Oh, that’s unfortunate. Let me know what is causing the delay to see how I can help.”
Maybe you can drop requirements, reduce the scope, etc. Or maybe you can’t and it’s simply a matter of acknowledging that everyone is doing their best and these things happen. If so, accepting this with a cheerful, or at least neutral, demeanor is the best you can do for team morale. Take ownership of working with other impacted teams by communicating the delay and being the face of the team. This will help the team and pay dividends in the long term.
If you are doing all of the above and you’re still constantly struggling to meet timelines, then your peers may simply need new management/help. I’ve seen an engineering team transform from never meeting a deadline to meeting most of their deadlines by having a new engineering manager join the team. The new engineering team took pride on honoring commitments and brought that discipline to the team.
That may be what you need, but first try the stuff above and see if it helps.
Note: originally posted as a Quora answer to the question As a product manager, how do you make your team respect the deadlines? This answer got over 80,000 views on Quora and over 240 upvotes, likely making it my second most read writing to date.
Last Updated on January 22, 2023 by Omar Eduardo