What a product manager actually does, and five myths to drop

Ask five people what a product manager does, and you'll get five different answers. Some say they're just professional ticket fillers. Others picture a project manager with a fancier title. A few think the product manager (or PM for short) is whoever talks the loudest in the standup.

None of those is quite right. At Applifting, our PMs are the voice of the customer inside product development. Their job is to make sure what gets shipped is actually worth shipping. Below are five myths we hear all the time, and what the role really looks like.

Myth #1: A product manager is just a coordinator

Fact: A coordinator passes information between people. A PM figures out what will create the most value for your customers, and why, then puts a firm recommendation in front of you. In practice, that means being the person in the room who keeps asking: would the people we're building for actually want this?

That recommendation is the hard part. Most products fail not because of poor execution, but because the team built the wrong thing for the wrong people. Our PM's job is to keep that from happening: they talk to your future customers, weigh trade-offs, and prioritise work based on real data rather than gut feel. The final call on what ships is always yours as the product owner on the client side. You just get to make it with a real expert opinion already on the table.

Myth #2: A product manager does whatever the client asks

Fact: A good PM challenges the client when it matters.

When a client comes in with a wish list of 40 features, our PMs don't just nod and write tickets. They ask the uncomfortable questions: Who is this for? What problem does it solve? How will we know if it worked? These aren't questions every product team makes time for. Skipping them is also how most products end up solving a problem nobody actually had. 

Myth #3: A product manager only shows up once development starts

Fact: The PM is involved before the first line of code is written.

At Applifting, every product goes through three phases, and the PM is present in all of them.

• Strategy. Before anything is built, the PM gathers context from your team and works with our designer and solution architect to draft a development and release plan. Together, we define a first version that delivers the best value for the money. The goal is to get something real in front of users, and gather enough feedback to shape what comes next. This is also where we agree on priorities and define what success looks like.

• Discovery. This phase is about figuring out what to build. Customer interviews, market research, and prototypes. For larger projects, we run a five-day Design Sprint that takes us from the riskiest assumption on Monday to a tested prototype with real users by Friday.

• Delivery. Once development starts, the PM acts as a proxy product owner: the bridge between the client, the developers, and the designers. They keep the backlog clean, run planning meetings, and make sure each sprint moves the right needle.

If you want the fuller picture of who else is involved in those early phases, we wrote about the product trio separately.

Myth #4: Once the MVP launches, a product manager's job is done

Fact: Launch is the beginning, not the finish line.

A live product generates data. The PM pays attention to it. They collect feedback from real users, talk to support, and recommend what to build next. That's continuous discovery in practice: research keeps running for the life of the product, not just in a phase before development. The delivery and discovery loop repeats for as long as the product is on the market.

This is also why we prefer long-term partnerships. A PM who shipped your first version carries knowledge a new hire would take six months to learn: why a feature was cut, which users were the hardest to please, and what the next bet should be.

Myth #5: You can skip the product manager if your brief is clear

Fact: A clear brief is a great starting point. It isn't a substitute for someone whose full-time job is asking should we? instead of just can we?

Engineers are paid to solve the problem in front of them. Designers are paid to make it usable. Without a PM, nobody is paid to question whether it's the right problem to solve in the first place. That gap is where most product budgets quietly evaporate. We’ll go into the budget case in more detail in our next piece on five reasons your project needs a PM.

The product manager role, in short 

A product manager isn't a coordinator, a mini-CEO, or a Jira admin. They're the person responsible for the three things that decide whether a digital product succeeds: 

• It solves a real problem for users. 

• It gets built well by the team. 

• It keeps delivering value to the business after launch. 

If you're planning a new product and aren't sure where a PM fits in, or whether you need one at all, we're happy to talk it through. Send us a brief, and we'll show you how a PM would scope the first three months.