# What Product Managers Actually Do: Beyond the Job Description > Where the hours actually go in an ordinary week, why the role exists at all, and the part nobody warns you about: most of the job is deciding what not to build. Author: Abdul Hannan Shaikh, senior technical PM at APIMatic. Published: 16 November 2025 Topic: PM craft Reading time: 10 min read Canonical: https://soch.ahshaikh.com/blog/what-product-managers-actually-do/ --- Someone at a dinner party asks what you do. "I'm a product manager," you say. They pause. "So... like a project manager?" You start to explain, realize it's complicated, and default to "I help build products people use." They nod politely, still unclear. I've had that conversation more than once. If you have too, you already know the problem: product management is one of the most misunderstood roles in tech. Even people inside tech companies struggle to say what PMs actually do. The job descriptions don't help. They're vague collections of responsibilities that could apply to half the company. "Define product vision." "Work cross-functionally." "Drive execution." None of it tells you what you'll spend Tuesday doing. ## The core responsibility: bridging gaps Here's the clearest way I've found to explain it. Product managers sit where business viability and technical feasibility meet, and the third thing standing in that room is whether a user wants the result at all. Your job is to find the answer that holds on all three at once, then get a team to build it. Everyone around you is answering a different one of those questions: - Business stakeholders care about revenue, growth, market position. - Engineers care about architecture, technical debt, whether the thing scales. - Designers care about the user experience and the interaction patterns underneath it. - Users care about their problem going away without friction. Those four lists conflict more often than they agree. Somebody has to take all of them seriously and still make a call the team can build against. That's you. You're often described as the "CEO of the product," which sounds empowering but is misleading. You're not the CEO of anything. No direct reports, no budget. Whatever formal power you have is thin. What you do have is responsibility: you're accountable for whether the product succeeds, and you have no lever except influence. ## What a day actually looks like Let me walk you through a fairly typical Tuesday, because the abstraction doesn't capture the texture of the work. I don't know a PM whose Tuesday looks much different. Morning starts with user feedback from the latest release. Three bugs keep coming up. One is cosmetic, one causes minor friction, one blocks a critical workflow for a small and very vocal set of users. That needs triaging before anything else. While you're triaging, the rest of the day arrives: - Marketing wants you in a meeting on Q4 positioning. - Engineering has flagged a technical limitation affecting a feature you already promised to sales. - Your designer has booked time to review mockups for next sprint. - A customer success manager has a client threatening to churn over a missing feature. You're the central node for product information and product decisions, which is why all of it lands on you at the same time. By 10 AM you've made a dozen micro-decisions: which bug gets prioritized, whether the mockup review can slip, how to tell sales about the technical limitation, whether the positioning meeting needs you in the room at all. Midday you're in user research, watching someone struggle with your onboarding flow. They're confused at a step you were sure was obvious. You take notes and resist the urge to interrupt and explain. This is the good stuff: unfiltered evidence about whether your assumptions match reality. Afterwards you go to the analytics to find out whether this person is unusual. They aren't. Now you have a prioritization decision you didn't have this morning. Afternoon is alignment. A planning meeting with engineering, walking through user stories for next sprint, and an engineer raises technical debt that's slowing the team down. They want a sprint to refactor. You agree with them, and you also have committed deliverables for a partnership deal. Short-term business pressure against long-term technical health, and neither side of that is wrong. You're not writing the code or closing the deal. You're the one who has to make a call everyone can move forward from. Late afternoon is writing. Specifications for a feature that doesn't exist yet. Context for a decision you made last week that engineering needs on paper. A memo explaining why a stakeholder's pet project just got deprioritized. Slack messages unblocking three different people. A roadmap update reflecting what changed today. Writing is the invisible half of product management, and it's where complexity gets turned into something a team can execute against. By evening you've had maybe thirty minutes of uninterrupted deep work. The rest went to context-switching, decisions, communication, and other people's blockers. You're a multiplier. Your output isn't code or designs, it's twenty other people being able to do their best work because somebody gave them clarity and took the ambiguous decisions off their desks. ## The three core competencies Strip out the calendar and three capabilities are left underneath. ### Discovery Figuring out what to build. User research, competitive analysis, market understanding, problem validation. Aspiring PMs hear that and think it means talking to users. It's deeper. The work is building conviction about which problems are worth solving, and for whom, and why now. You have to separate what people say they want from what would actually create value for them. Then you have to see the pattern across the qualitative feedback and the numbers that nobody else has joined up yet. ### Delivery Working with the team to build it. Requirements, acceptance criteria, backlog order, trade-offs, unblocking. The craft here is communication, and it's the thing I'd test for first if I were hiring. Can you describe the problem clearly enough that a designer and an engineer both know why it matters and what success looks like? Can you cut scope without cutting the thing that made the feature worth building? Holding a quality bar while still shipping at pace is a third skill again. ### Strategy Making sure any of it matters. Vision, metrics, the line from a feature to a business outcome, market positioning. Strategy isn't a roadmap. It's the thread connecting today's decisions to where you said you were going. When an engineer asks "why are we building this?", the answer cannot be "because the CEO wants it." It has to reach back to user value, to business impact, to the opportunity in the market, and it has to do that in words the engineer can check for themselves. Good PMs hold all three. The mistake I see most often is over-indexing on delivery, because delivery is the part everyone can watch. Discovery and strategy are what decide whether the execution was worth doing at all. ## Why this role exists Organizations without strong product management drift into being feature factories. I've watched it happen. Engineering builds what stakeholders request and nobody asks whether the request solves a real problem. The roadmap ends up belonging to whoever is loudest. Features ship and then sit there unused, because the assumption underneath them was never checked. The gap is a function of scale. In a three-person startup the founder holds the business context and the technical calls and the users in one head, and it works fine. At fifty people it stops fitting. You need somebody whose full-time job is holding those perspectives together and keeping the whole thing coherent. Good product management compounds. A PM who provides clear direction can 10x a team's impact, because the team spends its months on the right problems in the right way. Without that clarity, months of engineering effort go into features that don't move metrics. ## The hard parts nobody mentions You're accountable for outcomes and you can't tell a single person what to do. Everything runs on persuasion, and on having earned enough respect that people hear you out. When an engineer disagrees with your prioritization or a designer pushes back on requirements, pulling rank isn't available to you. You make the case, then you take the objection seriously enough to either answer it or change your mind. If you aren't naturally collaborative, this is exhausting. Then there's being wrong in front of people. You decide on incomplete information, so some of your calls will be wrong, and the useful skill is noticing quickly and correcting where everyone can see it. That takes a tolerance for discomfort no job description mentions. If you need to be right to feel validated, product management will break you. Saying no is the hardest of them, and I'd put it above the other three. You'll have ten good ideas and resources for three. Stakeholders push their own priorities. Sales promises features to close deals. Your CEO suggests directions that don't match the strategy. The job is to say no, diplomatically and firmly, and then to say it again next week. Every yes is a no to everything else. Most of this job is deciding what not to build, and almost nobody tells you that going in. The last one is ambiguity, and it doesn't resolve. Engineering has requirements to write against. Design has a mockup you can look at and argue with. Product decisions live in the gray. Acquisition or retention? New features, or fixing the ones you already shipped? Underneath both of those, which segment of users you're really answering to. There is no objectively right answer to any of it, only trade-offs with different consequences. You make the judgment call and you live with not knowing. ## The craft, and why it matters There's something genuinely satisfying underneath all of that. You're building things people use. Make good decisions for long enough and you watch them compound into products that solve a real problem, and occasionally into products that change how people behave at scale. The craft is in the synthesis. Messy, conflicting input arrives from a dozen sources and leaves as one clear direction. Signal gets pulled out of noise. Trade-offs get made and then explained. You spend a lot of the day translating between three languages, business objectives and technical constraints and user needs, until everyone in the room is describing the same thing. Good product management is invisible. A team ships something that delights users, hits its numbers and feels solid to the engineers who built it, and nobody thinks "great product management." They think "we built a great product." You're the connective tissue that makes the work possible, and you're rarely the one in the spotlight. ### If you're aiming at this job Start building the synthesis muscle now, wherever you're sitting. Practice understanding perspectives that aren't yours. Make decisions on incomplete information and watch how it feels. Get comfortable with ambiguity. Get better at writing. Then study how the products you admire actually got built, and who made the calls. It isn't for everyone. You have to be able to work through influence with nothing formal behind it, and to be wrong in front of people without it wrecking you, and the ambiguity never lets up. If reading that felt energizing, this is probably your craft. It will push you in directions you didn't plan for. Some days you ship something that genuinely helps people, and nobody outside the team knows you had anything to do with it. I've made my peace with that.