Lesson 1: What a product manager actually does
A product manager decides what gets built and why, without being anyone's boss. Learn the three questions the role answers and how it differs from project work.
Product management is often described as the CEO of a product, which is misleading. A product manager has no authority over the designers, engineers or marketers they work with. What they do have is responsibility for one outcome: that the product solves a real problem for real people, and that the business benefits when it does. By the end of this lesson you will be able to describe the job in plain words, tell it apart from the jobs beside it, walk through a real product problem the way a product manager would, and estimate in rupees why choosing the right thing to build matters more than building it quickly. You need no technical background. We will use a bill-payment app as the running example, with numbers you can change yourself.
The job in one sentence
A product manager is the person accountable for whether a product succeeds, who has to achieve that by influence, not by instruction. Everything else in this lesson is a consequence of that sentence.
"Accountable for whether the product succeeds" means that if people do not use it, or use it and still have their problem, or use it in a way that loses the company money, the product manager owns that result even though they did not write the code or draw the screens. "By influence, not by instruction" means that they get the result by making the problem clear, bringing evidence, and helping a group of people who report to other managers agree on what to do. The skill is less like giving orders and more like running a good meeting that keeps ending in a decision.
This is why the job is hard to explain at parties. A designer makes screens. An engineer makes software. A marketer makes campaigns. The product manager makes sure those three things add up to something a customer wants, and the evidence of their work is mostly the quality of the decisions other people were able to make.
Three questions the role answers
Every good product manager spends their week on three questions, whatever the company or the product.
1. Who is this for, and what is their problem? Not "what feature do we add" but "what is getting in the way for this person today". The person might be a customer paying a bill, a shopkeeper taking orders, or an operations team member approving loans. The problem is described from their side, in their words.
2. Is it worth solving now? There are always more ideas than time. Every request from a senior leader, a customer or an engineer is a claim on a limited team. The role is to pick the few that matter most and to say no, politely and with reasons, to the rest.
3. Did it work? After launch, did the problem actually get smaller? Shipping is not the finish line. A feature that nobody uses is a cost, not a result.
Notice that none of these says "write code" or "design screens". Others do that. The product manager makes sure they are all pointed at the same target, and then checks whether the target was hit.
It helps to see these as a loop and not a list. The answer to question three feeds question one: what you learn after launch changes your understanding of the person and their problem. Teams that treat the three questions as a one-way conveyor belt, from idea to launch, tend to ship a lot and learn little.
A week in a product manager's life
What does the job look like on a calendar? It varies a great deal between companies, but most weeks mix the same five kinds of activity. The split below is one reasonable picture for a product manager on a mid-sized consumer app, not a survey of how the profession spends its time.
Two things stand out. First, only a small slice is "planning", the part people imagine when they think of a strategist. Most of the week is conversation: with engineers about what exactly is being built and why, with designers about what the user will see, and with other teams about what depends on what. Second, talking with users and reading numbers together take up a good third of the week. A product manager who stops doing these two things drifts into building what the loudest person in the room asks for.
An everyday example: the bill-payment app
Imagine a bill-payment app in which many users abandon the screen where they enter an electricity account number. Management has noticed that fewer people complete payments than expected and wants something done.
Predict first: what would a good product manager do first, before asking engineers for any change? Pick one: (a) redesign the screen, (b) ask users why they stop, (c) look at the numbers on where they stop.
The strongest answer is (c) and then (b), in that order. The numbers show where the drop happens, and short conversations with users show why. Jumping to (a) risks redesigning a screen that was never the real problem. Perhaps people simply do not have the account number to hand when they open the app, and the fix is a way to look it up from a photo of their bill, or to remember it after the first payment. A redesigned screen would not help either of those.
Here is the kind of picture the numbers give. Suppose 20,000 people open the bill screen on a typical day. Of those, 62 per cent get as far as entering an account number, 80 per cent of those confirm the amount, and 90 per cent of those complete the payment.
The biggest drop, by far, is at the account-number step: 7,600 people leave there, against 2,480 at confirmation and 992 at payment. That tells the product manager where to look first. It does not yet say why. Fixing the right step is worth a lot more than fixing the wrong one, and you can see how much with the next simulator. Change the share of people who enter an account number, and the size of the improvement from the fix, and watch what happens to payments per day.
Try this experiment. First give the account-number step a gain of 10 points. Then set the account-number step to 95 per cent and instead lower the confirmation step to 60 per cent, which makes the confirmation step the big drop. Put the same 10 points on the account-number step again and see how little it adds. The same effort, on the wrong step, buys far less. This is what "is it worth solving now?" means in practice.
Choosing what to build costs more than people expect
The funnel shows that where you point the team matters. The second thing to understand is that building is expensive, and the cost of building the wrong thing is paid in full even though nobody ever uses it.
Take a modest feature: four engineers working for eight weeks. If an engineer costs a company about ₹40,000 a week in salary, overheads and tools (an illustrative figure, and the real number varies enormously), the feature costs 4 times 8 times ₹40,000, or ₹12.8 lakh, before any designer, tester or product manager time is counted. If there is only a fifty-fifty chance it solves the problem, you should expect to waste about half of that.
Now suppose you spend a little first, say ₹1 lakh on user interviews and a clickable prototype, and that this raises your confidence that you are building the right thing to 70 per cent. The expected waste falls, and the question is whether the saving is greater than what you spent. Try it with your own numbers.
At the starting numbers, building now means an expected waste of ₹6.4 lakh, while testing first brings it to ₹4.84 lakh including the ₹1 lakh spent. A saving of about ₹1.56 lakh. Now change the build to one engineer for two weeks, which costs ₹80,000, and the same ₹1 lakh test is no longer worth it. This is a useful instinct for product managers: the more a thing costs to build, the more it pays to learn first, and the cheaper it is to build, the more sense it makes to just build it and watch what happens.
Product manager, project manager and owner
The role is easy to confuse with its neighbours. A short comparison helps.
Role · Owns · Typical question · Success looks likeProduct manager · What gets built and whether it worked · Is this the right problem to solve now? · The problem got smaller and the business benefited
Project manager · Delivering a defined piece of work · Will this finish on time and on budget? · Work delivered as planned
Engineering manager · The engineers and how they work · Is the team healthy and shipping well? · A team that delivers and grows
Designer · How the product looks and feels to use · Can people use this without thinking? · Clear, usable screens and flows
Founder or owner · Everything, in a small company · What should this business do next? · A business that survives and grows
In smaller companies one person may cover several of these. The questions still help you separate which hat you are wearing in a given meeting. A founder deciding between two features is doing product management. The same founder checking whether the launch date will be met is doing project management.
Skills the job asks for
People arrive in product management from engineering, design, operations, consulting and sales. There is no single path, because the work calls on four skills, and different backgrounds supply different ones.
Judgement about problems. Seeing which problem matters most, and noticing when a request is a symptom of something else. This is built by talking to many users and looking at many sets of numbers.
Communication. Writing a one-page problem statement that an engineer, a designer and a sales head can all read and agree on. Explaining why something is not being built without making anyone feel ignored.
Analysis. Being comfortable with numbers: conversion rates, retention, how to tell a real change from random variation. You do not need to be a data scientist, but you do need to be able to ask good questions of one.
Craft knowledge. Enough understanding of how software is built, and how screens are designed, to have an honest conversation about trade-offs. A product manager who does not understand why a change is hard will either ask for the impossible or be misled by easy-sounding answers.
Notice what is not on the list: being the smartest person in the room, or having the final word. The role works when other people trust the product manager's judgement enough to follow it, and that trust is earned.
Working with engineers, designers and the business
A product manager sits in the middle of three groups with different pressures.
Engineers care about building things that work and can be maintained. They want clear problems, not vague wishes, and they want to be told why something matters. A good product manager brings the problem and the evidence, asks how hard different approaches would be, and listens when told that a request is far more expensive than it sounds.
Designers care about whether people can actually use the product. A good product manager shares what they know about users, asks for several options, and leaves the craft of the screens to the designer.
The business side, meaning sales, marketing, finance and operations, wants the product to deliver results that matter to them. They bring requests. A good product manager treats these as evidence of problems and not as instructions, and explains what will and will not be done, and when.
In all three relationships the pattern is the same. The product manager brings clarity about the problem, evidence for the decision, and a willingness to explain the "no".
Measuring whether it worked
The third question, did it work, deserves a closer look because it is where many teams fall short. A useful habit is to separate three kinds of measure.
An output is something the team made: features shipped, screens redesigned. It is easy to count and it says nothing about value.
An outcome is a change in what people do: more people completing a payment, fewer people calling support.
An impact is the effect on the business: more revenue, lower cost, more customers who stay.
In the bill-payment example, "we redesigned the account-number screen" is an output. "Conversion went from 44.6 per cent to 51.8 per cent" is an outcome (which you can check against the funnel above). "Payments per day rose by about 1,400" is the same thing in the form a finance team understands. The product manager's job is to define in advance which outcome would show the problem got smaller, so that after launch nobody argues about whether it worked.
Your first ninety days in the role
Someone who has just become a product manager of an existing product faces an odd problem: everyone expects decisions, and they do not yet know enough to make good ones. A sensible pattern for the first three months has three stages.
The first month is for listening. Meet the engineers, designers, support staff and sales people who touch the product, and ask each one the same questions: what do users complain about most, what is hardest to change, and what would you fix if you could fix one thing. Read the last few months of support tickets and app-store reviews. You are building a map of where the pain is, and of who knows what.
The second month is for numbers. Learn the product's main funnel, as in the bill-payment example, and find the two or three places where most people leave or most money is lost. Ask for the data to be shown to you in a form you can read, and ask what the numbers did over the last year, not just last week. Pair the numbers with five or six conversations with real users, so that you have a reason next to each drop.
The third month is for a first small decision. Choose one problem, write it as one sentence about a person, agree with the team what outcome would show it got smaller, and ship one modest change. The aim is not a big win. It is to complete the whole loop once, from problem to outcome, so that people see how you work and trust the next, bigger decision.
New product managers often skip straight to a roadmap of many features in the first week, because it feels like what the job requires. A roadmap built before the listening and the numbers is mostly a list of guesses with a confident tone.
Common mistakes
These are the patterns that most often trip up new product managers.
Starting with the solution. "We need a chatbot" is not a problem. Start with who is stuck and where.
Treating every request as a priority. A list of everything is a list of nothing. Say what you are not doing.
Asking users what to build. Users are expert witnesses to their own problems, not designers of the solution. Ask what they did last time and what went wrong.
Measuring outputs. Counting features shipped feels like progress and tells you nothing about whether anyone benefited.
Confusing the job with being the boss. You will not get things done by claiming authority you do not have. Bring evidence and explain your reasoning.
Skipping the question "did it work?" Without an outcome defined in advance, the story after launch is whatever people want it to be.
Spending months on something that could be tested in days. The cheaper a test, the sooner you should run it.
Key takeaways
A product manager is accountable for whether the product succeeds and gets there by influence, not authority.
The role answers three questions in a loop: who has what problem, is it worth solving now, and did it work.
Look at the numbers first to find where people get stuck, then talk to users to learn why.
The same effort aimed at the wrong step buys far less: choosing the problem matters more than polishing the solution.
The more a thing costs to build, the more it pays to test first. The cheaper it is, the more sense it makes to build and watch.
Project managers deliver work; product managers choose which work is worth delivering and check whether it paid off.
Separate outputs, outcomes and impact, and decide the outcome you will look for before you launch.
Check yourself
1. Why is "CEO of the product" a misleading description of a product manager?
They are accountable for the outcome but have no authority over the people doing the work, so they get results by influence.
2. A checkout screen loses most users at the address step. What do you do first, and why?
Look at the numbers to confirm where the drop is, then talk to users to learn why, before redesigning anything.
3. In the funnel simulator, why does the same 10-point improvement add far fewer payments when the account-number step is already at 95 per cent?
There is little left to gain at that step. The gain is limited by how many people are still leaving there.
4. What is the difference between an output and an outcome? Give one example of each.
An output is something the team made, such as a redesigned screen. An outcome is a change in behaviour, such as more completed payments.
5. A feature takes two engineers one week to build. Does it make sense to spend ₹1 lakh testing it first?
Probably not. At that build cost the test costs more than the waste it could save, so it is cheaper to build and watch.
Try this
Set aside about forty minutes and pick an app you use every day, such as a payments, food, travel or banking app.
1. Name one thing that annoys you or makes you stop. Write it as one sentence about the person, not a feature: "A new user cannot find X because Y".
2. Write down who else is likely to share the problem. Is it everyone, or a particular kind of user?
3. Guess where, on the screen or in the journey, people leave. Sketch a three-step funnel with made-up but plausible percentages, and put them into the funnel simulator above to see how many users each step might lose.
4. List three possible causes of the drop and, for each, one question you would ask a user to find out whether it is the real one.
5. Write one outcome you would look for to know a fix had worked, in numbers, such as "more people completing the step". Decide in advance what size of change would count as a success.
6. Estimate what it might cost to fix, in people and weeks, and use the testing simulator to decide whether you would test before building.
A good result is a one-page note a colleague could read in two minutes: the person, the problem in one sentence, where you think they get stuck, how you would check, and how you would know it worked.
Tags: Product Management PM basics Product strategy Careers Beginner