Understand what a Product Manager really does — and doesn't do.
Goal: Understand what a Product Manager really does — and doesn't do.
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.
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.
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.
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.
The shorthand: a PM owns the what and the why. The how belongs to the people doing the work.
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.
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:
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.
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.
Pick an app you use a lot, and think of one feature you'd love to add. Now put it through Maya's three questions in two or three sentences. Why would it be valuable, for users and for the business behind the app? Would it be usable for someone opening the app for the first time? And do you think it's feasible to actually build? Watch how fast those three lenses turn a vague "wouldn't it be cool if…" into something that sounds like a real product decision.
Preparing your quiz…