Product management is the job of making sure the team builds the right thing.
Nine years into doing this, across a supply-chain platform at Dell, a 20-person AI team at Pixis, and the data platform under InMobi’s ad exchange, that is the one sentence I would keep if I had to cut everything else. It is not the job of owning every decision. It is not the job of writing every requirement. It is not the job of being the loudest voice in the room.
That sentence sounds obvious until you watch how many new PMs get talked out of it in month one.
So that’s today’s post.
Today’s Post
The definition that actually holds up, in seven sections.
- Why “CEO of the product” misleads almost everyone who hears it
- The three pressures every real product call has to negotiate
- Why influence, not authority, is the entire job
- Why you are not a substitute for engineering or design, and not their boss either
- What the job looks like day to day, once you strip the highlight reel
- The gap between the quarterly strategy deck and the next two weeks
- What this track will, and will not, teach you
1. “CEO of the product” sounds flattering, and it misleads almost everyone
You have probably heard someone call product management “the CEO of the product.” It is a catchy line. It is also wrong in exactly the way that hurts new PMs.
A CEO has real authority: hiring, firing, budget, and legal accountability for the P&L. A PM has none of that on a normal team. Calling yourself CEO of the product does not hand you any of it. What it hands you is the temptation to act entitled the first time an engineer pushes back, and that is how you burn trust in week one.
The metaphor also nudges PMs toward the wrong behavior. It tells you to command, to decide alone, to treat engineering and design as an execution arm that carries out your calls. I have run teams where that pattern shipped fast and broke trust just as fast. The teams that hold together long term work the other way: the PM creates clarity, the group converges on the bet together, and the credit gets spread the way the work actually happened.
Drop the title fantasy. The next six sections are the real job.
2. The real job sits across three pressures that rarely agree
Every product call worth making lives at the intersection of three forces. You are not optimizing one of them. You are negotiating all three, in the same meeting, usually with incomplete information.
User value is whether the thing matters to a real person doing a real task. Not “users will love this” on a slide. Value shows up as behavior: adoption, retention, a support ticket that stops recurring, a task that used to take five clicks and now takes two.
Business viability is whether the organization can sustain the bet. At InMobi that means revenue and margin when money changes hands, but also strategic fit, compliance, and the sales motion a feature requires. A feature that customers love and quietly bankrupts the business is not a win. It is a slower-motion version of the same failure.
Technical feasibility is whether the team can build, operate, and evolve the thing with the stack it actually has, not the stack you wish it had. At Dell I watched a supply-chain feature look trivial on a whiteboard and take two quarters once the data pipeline underneath it showed up in the estimate. Feasibility is not engineering vetoing your idea. It is a cost you pay later if you ignore it now.
Picture a live version of this. A sales lead wants a highly specific export format because one enterprise account is asking for it. Customer interviews say reporting is “fine.” Support tickets show people manually rebuilding the same spreadsheet every week. Engineering says the clean fix is a new pipeline and two quarters of work, and a duct-tape version ships in three weeks but falls over under load.
User value points at “make reporting trustworthy.” Business viability points at “close the account” or “cut the support load.” Feasibility points at “patch now, rebuild the pipeline next.” Your job is not to pick whichever dimension wins you the argument in the room. It is to lay the tradeoff out honestly and drive a decision the org can actually live with, including the parts it will not get in the short term.
That is product judgment. It is not a scorecard you fill in. It is the discipline of holding three goals that disagree without pretending they have already been reconciled.
3. You have no formal authority, so influence is the entire job
You cannot hire or fire your design and engineering partners. That means your leadership has to be earned, every week, not assumed on day one. Four things earn it.
- Clarity: you can explain the problem, the bet, and what “good” looks like without hiding behind a framework’s jargon.
- Evidence: you show research, data, and customer quotes. Evidence rarely wins an argument outright. It raises the quality of the argument itself.
- Reliability: you follow through and document decisions, so nobody gets surprised by a commitment they never actually agreed to.
- Respect for craft: you treat design and engineering as peers with real expertise, not as a queue that executes your tickets.
Authority can force alignment in one meeting. Influence has to earn alignment, one decision at a time, and that is slower up front and far more durable afterward.
In practice you lead through shared artifacts. A crisp problem statement. A decision log. A prototype that makes an abstract debate concrete instead of theoretical. A metric definition that two teams actually use the same way instead of arguing past each other in the same review. My own rule on this site’s home page is unwritten means undecided, and that rule exists because the artifact is the only thing that survives past the meeting where it was made.
You also lead by who you put in the room. If only PMs talk to customers, the org ends up believing whichever anecdote matches PM bias that quarter. I run fifteen-plus customer interviews per launch, every launch, and I bring engineers and designers into a chunk of them on purpose. The moment someone on the build side watches a real onboarding session fail, they stop optimizing for elegant internals and start optimizing for the person on the other end of the screen.
4. You are not a substitute for engineering or design, and not their boss either
Modern product teams organize around a triad: product, design, engineering. You own outcomes and sequencing. You do not own pixels, and you do not own commits.
That distinction matters most when something breaks. If a launch fails, you should be able to explain the bet, the assumption behind it, and the signal that would have changed the plan, without reaching for “bad UX” or “engineering was slow” as the explanation. When a launch works, the same discipline runs the other way: you spotlight the design and engineering craft that made it work instead of absorbing the credit yourself.
Junior PMs fall into two traps here. The first is solutioneering: jumping straight to a feature and defending it as if personal taste were a strategy. The second is backlog policing: treating the ticket tracker as the product and optimizing velocity numbers that never connect back to an outcome.
The fix for both is the same. Anchor on the problem. Make success measurable before anyone writes a line of code. Let the experts in the room own their domain. Your leverage is connecting those domains into one coherent bet, not doing their jobs for them.
5. What the job looks like day to day is messier than the highlight reel
The polished version of this job is strategy workshops, a clean roadmap, and a narrative slide that lands well in the all-hands. The honest version looks like this:
- Turning a vague ask into a problem specific enough to research and scope.
- Saying “not yet” to a genuinely good idea because it would starve a better one.
- Writing the one document that keeps three teams from quietly building three versions of the same thing.
- Facilitating a decision when the data is incomplete, which is most decisions, most of the time.
- Untangling a disagreement between sales, marketing, legal, and the engineers actually building the thing.
- Protecting a quarter’s focus during the week everyone suddenly has an “urgent” exception.
You will spend real hours in meetings that feel unglamorous. That is not failure. It is the job, when the job is coordination under uncertainty.
You will also manage stakeholders with legitimate, conflicting incentives. Marketing wants a narrative. Finance wants margin. A salesperson is carrying a quota that closes at the end of the month. None of them is the villain. Your job is translating each of their pressures into constraints and opportunities the team can actually act on, without turning the roadmap into a vending machine that dispenses whatever was asked for loudest.
You will repeat yourself, a lot. The same strategy gets explained in a different room with a different vocabulary every week. That repetition is not wasted motion. It is how an organization actually absorbs a direction instead of just hearing it once and forgetting it by Friday.
6. The gap between the strategy deck and the next two weeks is where you earn your keep
A strategy deck is easy to applaud and hard to execute. The actual craft is stitching the vision to the next increment: what the team learns next, what it ships next, and what it finally stops pretending it will get to.
That means being comfortable saying, “we do not know yet, so here is the smallest experiment that buys us information.” It also means being willing to say, “we know enough, and further research here is procrastination.” Both sentences are correct in different weeks. The skill is knowing which week you are in.
Operate only at the quarterly level and the team drifts, because nobody is translating the vision into what ships this sprint. Operate only at the sprint level and the team optimizes locally, shipping fast in a direction nobody chose on purpose. Good PMs oscillate deliberately: anchor the quarter, clarify the sprint, and revisit the anchor the moment new evidence lands.
7. What this track will, and will not, teach you
This series is called Product Management Foundations for a reason. We will go deep on understanding users, discovering real problems, and prioritizing under pressure, because those three skills compound across every domain: B2B or B2C, hardware or software, a zero-to-one bet or a scale-stage business.
We will not pretend there is one playbook that works in every culture. We will not treat a framework as a magic spell that produces a good decision on its own. We will treat every framework in this track as shared language, useful for exposing a tradeoff and making a disagreement productive instead of personal.
By the end, you should be able to:
- Ground a decision in observed user behavior, not just a stated preference in an interview.
- Separate a real problem from its symptom before committing build time to it.
- Prioritize under pressure and explain your “no” in a way a stakeholder can respect even while disagreeing with it.
If you are early in your PM career, expect discomfort. You will sit inside ambiguity longer than feels comfortable. Your job is not to eliminate uncertainty. It is to reduce it cheaply and make the next step obvious for the team standing next to you.
If you are experienced already, you will still get something out of tightening the language you use with your partners. The basics are where execution actually breaks, almost every time.
Takeaways
Seven sections, one card. If you only take one line from this post, it is the one at the top: the job is making sure the team builds the right thing.
Final Words
You will not get a title that grants you authority, and you do not need one. What you need is a habit of naming the tradeoff honestly, earning trust through evidence instead of volume, and repeating the same direction in ten rooms until it sticks.
Pick one decision your team is stuck on this week. Write down where it actually sits across user value, business viability, and feasibility, and see if the disagreement gets smaller once it is on paper instead of in three different people’s heads.
Next up: how to understand users in a way that survives contact with reality, beyond a static persona slide and generic empathy language.
Cheers, Hoshank