Explain a PM's Daily Work and Product Lifecycle to Someone Outside Tech

An interviewer asks you two related things. First, describe in plain, everyday language what you actually do day to day as a product manager. Second, imagine explaining to a family member with no technology background how a product goes from an early idea to something built and shipped: how would you walk them through that lifecycle? ### Clarifying Questions - Should the answer describe your current or most recent role, or the product manager role in general? - If you have not yet held the product manager title, should you describe the product work in your current job or the role as you understand it? - How long should the explanation be: a two-minute answer, or a fuller walkthrough the interviewer will probe? ### Part 1 — Your typical day in plain words Describe what fills a normal working day for you as a product manager, without jargon. ```hint Name the verbs Picture an ordinary recent week and list what you actually spent your time doing, then describe each activity with an everyday verb instead of a job title or process name. ``` #### What This Part Should Cover - A one-sentence description of the job that separates it from engineering, design and people management - The recurring activities that make up a typical day, and how they shift over the course of a project - Concrete, ordinary detail rather than titles and process names ### Part 2 — Idea to launch, explained to a relative Walk a family member with no technical background through how a product moves from first idea to release and beyond. ```hint One story, start to finish Pick a single feature and follow it from the first sign that something needed fixing to what happened after people started using it. ``` #### What This Part Should Cover - Each stage of the lifecycle in plain language, in order, including what happens after launch - The product manager's specific role at each stage - A comparison or example a non-technical listener can relate to, used consistently ### What a Strong Answer Covers - Clear, jargon-free communication pitched at the listener, with any unavoidable term explained - An accurate picture of how a product manager leads through influence rather than authority - The judgment part of the job, including deciding what not to build - Concision, and a check that the listener has followed ### Follow-up Questions - Your relative asks, "If you don't write the code or design the screens, what would go wrong without you?" How do you answer? - Which part of your day adds the least value, and what would you change about it? - How would you change this explanation for a new engineer joining your team?