Work
As a PM, you’re responsible for the product’s success but don’t honestly manage any of the people building it. You scroll back, hoping for context, but all you find is a string of messages about Gantt charts, customer journeys, and the like.
Welcome to the land of confusing job titles, where Product Managers and Project Managers roam free, occasionally bumping into each other and wondering who, exactly, is supposed to be steering the ship.
A real-life PM identity crisis.
Let’s set the stage. A company, let’s call it “Widgetly”, has just kicked off a new initiative: an app that allows people to rate the quality of their local rain. (Because, honestly, Irish rain deserves a proper scoring system.) The CEO wants “a product that delights,” the CTO wants “no surprises,” and the Head of Marketing wants “a launch date before the next general election.” Enter our cast: a Product Manager (that’s me), a Project Manager (let’s call her Gráinne), a team of slightly sleep-deprived engineers, and a designer who’s allergic to meetings.
On day one, the confusion begins. I’m sketching out user personas when Gráinne pings me: “Can you update the project plan with your deliverables?” I stare at my screen, wondering if “deliverables” include my existential dread.
Who owns what?
(& why you should care... maybe).
Here’s where the fun starts. Product and Project Managers have “PM” in their titles, but the overlap often ends there. According to Product School, Product School are the ones who represent the customer, define the vision, and say “no” more than a toddler with a new-found sense of autonomy. They figure out what game the company is playing and how to keep score—not always in euros, sometimes in user delight or, in our case, how many people can tell the difference between drizzle and mist.
Project Managers, on the other hand, are the masters of the schedule. They own the “how” and “when”- the keepers of Gantt charts, the wranglers of timelines, and the people who know exactly how many days are left until the next milestone (and aren’t afraid to remind you daily). Their job is to ensure the team is on track, the deadlines are met, and the chaos is at least colour-coded.
| Product Manager | Project Manager |
|---|---|
| Owns the “why” and “what” | Owns the “how” and “when” |
| Defines vision, strategy, and customer needs | Plans schedules, resources, and delivery |
| Prioritises features and says “no” a lot | Tracks progress and says “are we done yet?” a lot |
| Works with design, engineering, marketing | Works with everyone to keep things moving |
| Measures success by customer impact | Measures success by project completion |
If you’re still confused, you’re not alone. Even seasoned professionals admit the lines can blur, especially in smaller companies where one person might wear both hats plus a jaunty scarf labelled “random other tasks as assigned”.
Working through the fog.
Back at Widgetly, the confusion reaches its peak during a planning meeting. I’m trying to explain why our MVP (Minimum Viable Product, not Most Valuable Player, though I’d argue I’m both) should focus on “rain type detection” instead of “real-time umbrella delivery.” Gráinne, meanwhile, is gently nudging the conversation back to the timeline: “That’s great, but will it be ready by March?” The engineers quietly debate whether “horizontal rain” is a valid weather event.
We try a workshop to clarify roles. We stick Post-its on a whiteboard: “Customer research = Product,” “Timeline = Project,” “Feature prioritisation = Product,” “Risk management = Project.” By the end, the board looks like a Jackson Pollock painting, but we agree on one thing: If something goes wrong, it’s probably both our fault.
We experiment with tools. I create a Jira board for user stories; Gráinne sets up a Trello board for tasks. We try to keep our lanes separate, but occasionally, I sneak over to her board to add a “remind team to hydrate” card. She retaliates by adding a “finalise rain algorithm” deadline to mine. It’s a delicate dance, like two people trying to waltz while one insists on doing the Macarena.
There’s friction, sure. Sometimes, I wish Gráinne would stop asking about deadlines and let me dream up new features. Sometimes, she wishes I’d stop dreaming and just write the spec. But we also learn to appreciate each other’s strengths. She keeps us honest about what’s possible. I keep us honest about what’s valuable.
Why you should care (or not).
Here’s the punchline: Most people outside tech don’t care about the difference. Your customers just want a product that works. Your CEO just wants results. But inside the team, clarity matters. When you know who owns the “why” and who owns the “when,” you can avoid the dreaded “too many cooks” scenario, where everyone’s stirring the pot and nobody’s tasting the soup.
The best teams I’ve worked with don’t obsess over titles. They obsess over outcomes. They talk, they argue and they experiment. They laugh at their confusion and get on with the job. If you’re lucky, you’ll find a Siobhán who keeps you grounded, and you’ll keep her inspired.
What we learned (& what we didn’t).
Widgetly shipped a rain-rating app. It wasn’t perfect, but it made people smile—and a few even learned the difference between “soft day” and “lashing.” I knew my job wasn’t to have all the answers but to ask the right questions. Gráinne learned that a missed deadline is sometimes worth it if the product is better for it. In the great PM identity crisis, we both realised that the only real loser is the person who refuses to laugh at the absurdity of it all.
So next time someone asks, “Who’s the PM on this?” smile, offer them a cup of tea, and say, “Depends who you ask.” Then, get back to work. The rain won’t rate itself.
TAGS:
Keep Reading
ALL POSTS
