What Is a PM (Project Manager)? The Job and the Five Skills It Demands
Published:
Last Updated:
Category: Campaign Management, Marketing DX
Published:
Last Updated:
Category: Campaign Management, Marketing DX

Authors: Shusaku Yosa
PM is a job whose substance is hard to see. You are not making anything with your hands, and the output is not visible either. Yet projects with a PM and projects without one end quite differently. This article covers what a PM actually does, and the five skills the role demands.
PM stands for project manager, the role responsible for completing a project within the agreed schedule, budget, and quality. The job is not to carry out the work but to create the conditions in which the work gets finished.
There is a simple test. When a project fails, the person ultimately asked to explain is the PM. Someone else's work running late, or requirements changing partway through, all get treated in the end as falling within the PM's scope of control.
Several roles get abbreviated to PM, and which one is meant depends on context.
When PM appears in a job posting or an internal conversation, check first which one is meant. A project manager is there to deliver what has already been decided, by the deadline; a product manager is there to decide what should be built. The abilities required are quite different.
Since the work changes with the phase, looking at it phase by phase makes the shape of the role easier to grasp.
Settle what will be done, and what will not. Purpose, deliverables, budget, deadline, and who is involved. Ambiguity at this stage always surfaces as a problem later on.
Stating what is out of scope matters most here. Anything not written as "not included this time" comes back later in the form of "I assumed that was obviously part of it."
Identify the work, decide the order, and assign owners and deadlines. What the PM is judged on here is whether the plan is executable. A plan filled in by working backward from the delivery date starts falling apart in the first week of work.
Most of a PM's time goes here. But the role is not simply checking on progress. Finding the work that has stalled and removing the reason it has stalled is the job during execution.
The blockages are almost always the same kinds of thing: a decision has not come down, the necessary information is not available, another department has not responded. Most of these cannot be solved by the person doing the work, which is precisely why it means something for the PM to move.
Get through acceptance, hand over to the operations owner, and run a retrospective. It gets treated lightly, but a sloppy ending leaves a project trailing behind you. Disband without deciding who handles things afterward, and personal questions keep landing on whoever happened to do the work.
The skill that separates people most. A project always has undecided things lying around. "Make it easier to use." "As soon as possible." "Should be fine." Turning these into language someone can act on is the work.
Concretely, it means rewriting with a quantity, a target, a deadline, or a condition. "As soon as possible" becomes "by 5pm Friday this week"; "easier to use" becomes "the application completes within three clicks." Whether you can make that substitution decides how much rework the downstream work produces.
One caveat: you do not have to force a decision that cannot be made on the spot. Settling who decides it by when is progress enough.
Delays and problems do not travel upward on their own. To the person doing the work, reporting a delay looks like an act that lowers their own standing. The result is that you find out when it is already too late.
Changing how you ask changes the quality of what comes back. Ask "is it on track?" and you get "it's on track." Ask "what is still outstanding?" and "when do you expect to finish?" and facts come out.
More effective still is demonstrating, in practice, that you do not blame the person who reports a delay. React once by going after who was at fault, and every report after that will arrive later.
When the assumption that everything gets done collapses, deciding what to drop is the PM's job. Rearranging an order is something anyone can do; what is actually required is declaring that something will not happen this time.
When it becomes clear you will not make it, there are only three moves: shift the date, cut the scope, add resources. Presenting those three to the stakeholders and drawing out a decision on which to take is where the PM's role runs to. Taking it away with "we'll push hard and make it" is just deferring the decision.
A PM deals simultaneously with executives, the people doing the work, and outside partners, all of whom care about different things. The same fact needs to be conveyed at a different level of detail depending on the audience.
What executives need is whether the milestones will be met, and what requires a decision. They will not read a hundred-row task list. The team, conversely, needs the reasoning behind the priority order. Issue instructions with the reasoning stripped out and the work proceeds without conviction, and the quality drops.
With outside partners, spelling out your own side's work matters. Preparing copy, supplying assets, carrying out reviews. Proceed without writing these down and waiting time caused by your own side gets treated as the partner's delay, which damages the relationship.
Unglamorous, but it pays off in the later stages. What was decided, what changed, and why it changed. A project without these on record always loses time at the end to arguments about who said what.
Perfect minutes are unnecessary. The decision, the date, and who made it. Keeping just those three somewhere searchable is enough. When you push a deadline in particular, keeping the original date rather than deleting it lets you trace, in the retrospective, where and by how many days things slipped.
Not as a practical requirement. Certifications such as PMP exist and function as evidence of systematic knowledge. They can be valued in the job market or when bidding for large engagements, so their worth depends on your environment.
You do not need to be able to build it yourself, but you need enough understanding to question whether an estimate is reasonable. If you cannot ask why a task takes three days when you are told it does, the accuracy of the plan is left entirely to the person doing the work.
It depends less on headcount than on how many departments and outside parties are involved. If everyone sits in the same team, five or six people can run with the role held alongside other work. With three people, though, once other departments and vendors are in the mix, the coordination load rises and someone needs to hold the PM role explicitly.
Taking one small project from beginning to end is the shortest route. However small the scale, the sequence is the same: set the scope, build a plan, handle delays, and finish it. Experiencing the whole of something small teaches you more than owning one slice of something large.
None of these skills is something individual effort alone can sustain. In an environment where checking the situation means asking around every single time, even an excellent PM runs out of hours.
Once you are overseeing several campaigns in parallel in particular, a separate tracking sheet per project makes it impossible to see where the risk sits overall. Xtrategy manages campaign schedules alongside budget and KPIs on a single screen, so you can track progress across multiple campaigns at once.
PM skills are less a special talent than a collection of procedures. Make vague words concrete, change how you ask, decide and cut. All of them can be tried in today's meeting. Start by dropping "is it on track?" and asking "what is still outstanding?" instead.

A five-step method for mapping a business process, plus the three things that create key-person dependency, how to inter...

Two Japanese words are both read kotei and both mean something close to "process": 工程 and 行程. This guide explains the di...

How to make a project schedule readable, centred on the progress line. Covers the five steps for drawing it from the sta...