Topic 1 — What is a PM?

Goal: Understand what a Product Manager really does — and doesn't do.

Lesson 1.1 — What the team is actually waiting for

It's Maya's first Monday as a product manager at Lumi, a twelve-person startup that makes a personal budgeting app. She sits down expecting to be handed a list of things to build. Instead, three people walk over with three completely different ideas, and they're all looking at her to decide which one happens.

So she didn't get a to-do list. She got the harder question: which of these should the team spend the next two weeks on?

That question is the whole job. A product manager has one core responsibility, and it's this: make sure the team builds the right thing. Not the most things. Not the fanciest things. The few things that solve a real problem for real users in a way that also helps the business stay alive.

Picture Lumi as a kitchen. The engineers and the designer are talented chefs who can cook almost anything you name. Maya's job is to figure out what the guests actually want tonight, make sure the kitchen has what it needs, and decide what goes out first. A kitchen full of brilliant chefs cooking dishes nobody ordered is just an expensive way to go out of business.

The catch is that "the right thing" is almost never obvious. Users can't always tell you what they want. The business has goals that tug in their own direction. And the team could build a hundred plausible things. Maya's value is the thinking that narrows a hundred maybes down to the two or three that matter most this month, then making sure those get built instead of whatever is loudest in the room.

Lesson 1.2 — The three questions every idea has to survive

Back to Maya's three ideas. How does she actually choose?

She runs each one through three questions, and a good idea has to answer yes to all three. Miss one, and it falls apart.

• Is it valuable? Will users actually want it, and does it help Lumi grow, earn, or keep customers? This is Maya's home turf, the question she owns more than anyone.
• Is it usable? Can an ordinary person figure it out without a manual? This one she works out mostly with Priya, the designer.
• Is it feasible? Can the team actually build it with the time, people, and technology they have right now? This one she works out mostly with Sam, the senior engineer.

An idea can sail through one question and sink on another. Something can be deeply wanted but impossible to build this quarter. Something can be beautifully built and used by no one. Maya's skill is finding the ideas that clear all three bars, and catching early when one is quietly failing.

She doesn't need to out-design Priya or out-code Sam to do this. She needs to keep asking the three questions and pull the right person in to answer each one.

Valuable, usable, feasible. Drop one and you don't have a product, you have a problem.

Lesson 1.3 — The triangle, and the three jobs that aren't yours

By Wednesday, Maya can feel a pattern in her week. Dan from sales wants the feature shipped now, because a deal depends on it. Sam wants two more weeks to build it properly. Priya wants it simpler so users don't get lost. Three smart people, three directions, all reasonable.

This is the PM triangle, and it's the cleanest picture of the role. Maya sits in the middle of three forces: Business, Technology, and User Experience (UX). They almost always pull against each other. Her job is to decide where the team lands, then explain that decision clearly enough that everyone gets behind it, including the two people who didn't get their way.

Sitting in the middle leads to a lot of confusion about what a PM is. So it's worth being blunt about what Maya is not.

• She is not the boss of the engineers. She has no authority over Sam or anyone else building the product. She can't order a single line of code written.
• She is not a timeline manager. Tracking schedules and deadlines is closer to a Project Manager (Topic 2). Maya owns what gets built and why, and scheduling is a small slice of that.
• She is not the designer or the engineer. She doesn't draw the screens or write the code. She makes sure the right screens get drawn and the right code gets written.

The shorthand: a PM owns the what and the why. The how belongs to the people doing the work.

Lesson 1.4 — How she gets anything done with no power

So if Maya can't give orders, and half the people on her team are more senior than she is, how does anything actually happen?

The answer is influence, and it's the skill that defines the whole role. Maya moves a room of talented people in one direction without a shred of formal power.

It starts with clarity. She gets crystal clear on the goal and the reason behind it, so people want to head that way instead of being told to. Then comes preparation: she shows up carrying data, real user evidence, and a couple of thought-through options, rather than just an opinion. The rest is trust, built slowly, so that when she says "this is the one," people give her the benefit of the doubt.

Sam is the test case. He's skeptical and busy and won't budge on opinion alone. But bring him a clear "why" backed by evidence, and he moves. Maya never had to pull rank, because she never had any to pull.

This idea runs through the entire job, and Topic 12 digs into it properly. For now, the thing to hold onto is that a PM leads through clarity and trust, not power. Which is good news if you're coming from another field: these are human skills you build, not a title someone has to grant you.

Lesson 1.5 — What a Tuesday actually looks like

If you pictured a PM hunched over a screen building things all day, Maya's calendar would surprise you.

A real day at Lumi runs roughly like this:

• Morning standup. A fifteen-minute check-in with the team: what's done, what's next, what's blocked. Quick, every day, no chairs needed.
• Users and data. She watches a few people use the app, or digs into whether last week's change actually helped, or sits with the numbers to understand a problem.
• Writing and deciding. Updating the roadmap, drafting a short spec for an upcoming feature, or settling a "should we build A or B?" question on paper.
• A lot of conversations. With Priya, Sam, Dan, marketing, support, and leadership, keeping everyone pointed at the same thing for the same reason.

What you won't find anywhere on that day is a long, quiet stretch of Maya building the product herself. The work is decisions and communication, start to finish. If you like variety, talking to people, and being the one who connects the dots, that's a very good sign about this job.

Worked example — The Monday that earns the role

Now back to those three ideas waiting at Maya's desk, because this is where the whole topic pays off.

Dan from sales says a big potential customer will sign if Lumi adds an Excel export button. Two engineers are itching to rebuild the app's slow loading screen. And the CEO just read an article about AI and wants an "AI assistant" added to the product. One team, three demands, and Maya can't do all three.

Instead of saying yes to whoever pushed hardest, she runs each through the three questions.

The AI assistant sounds thrilling, but she has no evidence anyone actually wants it (valuable? unclear), and it's an enormous build (feasible? not this quarter). The Excel export is small to build (feasible? yes) and it's tied to a real customer and real revenue (valuable? yes). She doesn't take that on faith, though. She checks it isn't one person's whim by finding three other users who asked for the same thing. The loading-screen fix is real, but when she looks at the data, it only affects a tiny handful of users.

So Maya decides: ship the Excel export now, schedule the loading fix for later, and run a quick user-research spike on the AI idea before anyone commits to it. Then she walks back to Dan, the engineers, and the CEO and explains the reasoning to each, so everyone feels heard even though only one of them got their wish today.

That's the job in a single morning. Not building everything. Choosing the right thing, and bringing everyone along.