Essential project management skills

How product managers can lead successful execution and hit project goals more reliably

👋 Hi, I'm Jaryd. Welcome to this weeks Slice— the free weekly newsletter about product, startups, growth and working with people.

If you’re not as subscriber already, join below. It’s free. 👇

If you enjoy this newsletter, and know someone else who also might, you can share it below👇

Share The Product Slice

Product managers hate being called project managers. However, a significant part of our job is exactly that – leading successful execution and working with teams to ensure project goals are achieved within given constraints.

It's an essential skills, and when done poorly, it becomes very clear because:

  • Releases and launches get delayed

  • Work gets duplicated, or has to be redone

  • People run out of work

  • Misalignment on priorities leading to distractions

  • People get confused and there are misunderstanding

  • Misaligned stakeholder expectations

Before divining into important project management skills, it's worth keeping in mind that no matter how finessed your skills are, with every project you work on – something will always not go exactly as planned. It might be a small issue, but it's inevitable. 

These practices just reduce the likelihood that they will, and reduce the impact  when they do.

- Create milestones

- Reduce dependencies

- Have regular team checkins

- Write effective status reports

- Make adjustments when necessary

- Be available and unblock people

- Retrospectives and process improvements

Let’s dive in.

Create milestones 

Milestones and checkpoints are what incremental product development looks like in practice – where you're breaking up your end vision, which is a larger and more complex product, into smaller blocks of work. 

Size and time. These are two major variables that increase the likelihood that something goes wrong. And when you're dealing with just one milestone you're minimizing both size and time, and what you need to stay focused on now becomes more narrow – making project management easier. 

Milestones are also a great way for you and the team to assess and actually see your progress towards a larger goal, and when something of value goes out to customers, it's good for team morale. 

Reduce dependencies

If you’re building a house – you need to have the walls before you can paint them. And you need to have a foundation in place before you can build the walls.

This means painting the walls is dependent on the walls being up, and the walls on the foundation.

Dependencies are the relationships between tasks that drive their order of operations. As a PM you have to manage and schedule parts of your project while keeping their sequences and requirements in mind – working to minimize the disruption caused by dependencies like other projects, functional steps, processes, external factors, resources, cross-teams and other people. 

There is nothing wrong with dependencies. The projects you work on don't happen in a vacuum,  there are always dependencies – however these dependencies that come up in an Agile processes are absolutely natural. They’re neither good nor bad, and in most cases they’re just an inevitability. 

What is good or bad, is how you manage them – and dependency management is a key project management skill of a PM. 

The more dependencies you have, the more complex a project becomes. If there are more moving parts that need to work together – there's more to be managed and more risk. 

Below are some helpful tips on dependency management:

  • Identify and visualize relationships between different steps. The best way to know what effects what, is to write it down and create a visual map that shows the relationships.

  • “Design out” unnecessary dependencies. Collaborate with cross-functional teams and effectively try to get rid of unnecessary steps.

  • Make a risk log to stay on top of possible impact.  There will always be necessary dependencies you can't cut back on. Once you know what they are, it's worth thinking about how complex certain steps are and what the chances are they will affect deliverability. If they are higher, factor that into your projects' timelines. This shouldn't take a lot of time and can even as simple as quick conversation with an engineering partner.

  • Have a contingency plan. Knowing the risks is great, but it's not enough. You have to have plan for handling a scenario when a risk becomes a reality – because it will. Good project risk management protects you from the mess of just reacting to problems, which can have bad ripple effects on other work, and helps you enter ‘damage control’ mode as soon as things start to go wrong.

  • Communicate with stakeholders. Make sure that your stakeholders are aware of, and understand, what the major dependencies and how each of them will affect the delivery of the project.

Regular check-ins

The people that you're working with on a project is what drives execution, and it can be easy for people to fall behind on their work. This can happen for many reasons:

  • There is more work than expected

  • The work is more complex and involved than planned for

  • They're blocked by someone/something

  • They're just stuck and not asking for help correctly

  • They've been pulled into other work

  • They're spending to much time perfecting something

  • They're not prioritizing this work over other obligations

  • They're not interested or motivated by the work

  • There's a work or personal issue you don't know about

The best way to keep things on track is to be synced with your teammates through regular checkins. These can be 1:1s, slack messages, or a weekly checkin with the project team. 

Checkins surface issues and help you figure out why things are taking longer than originally estimated. However, you should always approach issues with respect, empathy and consideration for people. It's so important to show that you're on the same team and want the same outcome, creating an open and safe space for concerns to be raise. 

Once you have some clarification around what's causing the issue, you can:

  • Help them prioritize their task list

  • Help reduce scope

  • Help them better understand the significance and impact this work will have

  • Suggest they speak to someone that can help them get unstuck (i.e your backend engineer can speak to a technical lead for guidance)

The format and frequency of these checkins depends on the people you're working with. Your teammates are adults and responsible for their work, and your job isn't to micromanage an engineer or designer. 

I've found that a 30 minute weekly checkin from when a project kicks-off, with the team involved, works really well as a baseline. These meetings should be with the core team, like the engineers involved, the QA engineer, designer and a tech lead.

In these weekly meetings, you want to go through the following with each person:

  • What task are being worked on now

  • What is being worked on next

  • Have they been blocked by anything

  • Do they expect to be blocked by anything

  • Does anything look like it will be different to the original/latest estimates

  • If they're confident initial timelines will be met, and if not, why

These meetings help keep the team aligned, address any open questions, and often quick decisions get made that help people get unblocked. If you identify a larger issue with someone in particular, have a separate 1:1 conversation with them and go from there. 

Writing effective status reports

Status reports are your tool for communicating the state and impact of the work you and your team(s) are doing to your manager, and other people. If you're doing great work, this is the place to share that. If things are going wrong, get ahead of it by proactively letting the right people. 

The goal is to keep stakeholders in the loop and aligned around what's going on at ground level for your projects, like what the teams are working on, how are you progressing, and does it look like you are hitting your timelines. 

They answer the questions people will be asking before they actually ask them, so you’ll get considerably fewer questions about project status because you’re already ahead of the game. This gives people more confidence and trust in your execution abilities. 

Different stakeholders will have preferences for these reports – like how often they want them, what level of detail they're looking for, and how you share it with them (i.e a conversation, an email, a doc, a deck). The purpose of a report is to be read - so the best thing to do is just ask people upfront how they want these. After sharing a few with with them, ask for feedback. 

Here's a handy framework for writing effective status reports.

  • Project name. 

  • Current objective. What is the focus area right now? What are you aiming to achieve?

  • Status. Is the project On track / Delayed / At risk?

  • Progress. What recent updates and wins are there? What has shipped? Doesn't have to just be code. Credit your team and other people here where possible.

  • Plans. What's coming up in the near term?

  • Problems. Are there any current/upcoming issues or roadblocks? How will you resolve them?

  • Decision/Assistance. Have any decisions been made? And there any open decisions that need to be made?

Make adjustments when necessary

You should expect things to go wrong and take longer than originally estimated for. When your team falls behind schedule and your project timelines are at risk of being pushed out – you have three high-level options. 

  • Reduce your scope. This is usually the best option as long as you're not cutting essential parts of the project that will affect the usability and success of the release. If there are elements that can be cut and moved to the next milestone, pull this lever. Cutting scope means less work, less pressure on the team, less time to test, and should help keep you to your target dates.

  • Add more people to the team. If you can't cut scope, or that isn't enough, you have the option of bringing in more resources to the project. This involves going to leadership or an engineering manager, where you'll have make case for moving additional people in to help deliver on time. This is definitely a valid option if the project is high-priority, so don't shy away from this just because you have to argue for it. When doing this, be prepared to talk to why engineers should move from what they are doing to this project. More people means a higher cost of project, so this does have implications on the return on investment (ROI). 

  • Change the launch date. If none of the options above help or are not available to you, one last lever is moving the launch date. Be cautious with this option though, because the longer it takes to release a project the higher the direct cost (again, affecting ROI), increased opportunity cost (the team not doing other work), and a longer time until people can start using the product you built.

Whatever option you choose, make sure you document the decision and communicate it to the right people. You want to avoid a situation where you cut a feature out but failed to mention that to marketing, who've been preparing around that being in the launch. 

Be available and unblock people

As the PM, you're the subject matter expert and the source of truth for the project. 

Let's say an engineer is working on a high-priority bug ticket that came their way, however they have a question about what the expected behavior actually is before they can fix it correctly. They send you a message to help. Until you answer, they are blocked and  aren't able to do the work and fix the problem. 

The longer it takes you to reply to your team, the longer people are held up and can't get their work done. This not only frustrates people, but it can effect timelines if it happens often. 

You're going to always have a lot going on and and often will be in more meetings than the rest of your team, but actively put in effort to respond as quick as you can, particularly to questions from engineers, designers and QA. 

Retrospectives & process improvement

The importance and impact of a good team process can't be overstated. And the impact processes have on team execution multiples as the company and team size grows.

As you become more senior on the team, you want to be looking for ways to improve how fast and efficiently your team executes. To drive process improvement, there are four high-level phases.

  • Identify opportunities. Here you're assessing how well your current processes are performing. This isn't something you can do by yourself and requires getting feedback from people on the team. Project retrospectives are probably one of the best places to start, where you can find out from your team what they thought went well, what didn't, and areas of improvement. 

    You're looking for things that causes blockages, misunderstandings, frustrations, and delays – and then understanding the root issue of why those issues happened. 

  • Pick processes you want to add or change. Once you've found areas of improvement and have a recommendation around adding to an existing process, or even introducing something new, bring it to your relevant product leader and engineering manager. Their feedback will be extremely valuable, and you need their buy-in. 

  • Test them. After getting approval for the change, you want to test it before rolling it out to the wider team or company. Pick your next project, and make sure to clearly communicate to the project team what the new process is and why it's being implemented.

  • Implement them. If the process works as expected and you get positive results and feedback – it's probably worth keeping and rolling out to the rest of the team. When this happens, make sure there is documentation for the process change, you've documented the decision, and you tell everyone who's affected by the change.

While processes are very important and actively improving on them is a good thing, you want to be cautious of creating too much process, or changing things too quickly. 

Too much process can kill your ability to move quickly and makes getting things done harder, and changing things too quickly can frustrate your team. 

Have any thoughts, questions or feedback? 👇

Leave a comment

Every week, I write about product, startups, growth, working with people, and anything else that I’ve found helps me have a happier and more meaningful career in product management

If you’re not as subscriber already, join below. It’s free. 👇

If you enjoy this newsletter, and know someone else who also might, you can share it below👇

Share The Product Slice