glossary · general
Agile product management
An iterative operating model that ships in short cycles, learns from users continuously, and adjusts priorities based on evidence rather than upfront plans.
Agile is an operating environment, not a certification. In practice it means your team ships in short cycles (usually two weeks), builds in mechanisms for continuous feedback, and treats any plan older than a sprint as a hypothesis not a commitment. Knowing the vocabulary is table stakes in an interview. What clears the bar is demonstrating that you understand the PM’s specific job inside each ceremony and where the model breaks down.
The four scrum ceremonies and your job in each
Scrum structures work into four events. Most PMs can name them; fewer can articulate what they are actually responsible for in each one.
Sprint planning. You own the agenda. Before the session, the backlog should be groomed, stories written with acceptance criteria, and the top items already sequenced by priority. Your job is to enter with a clear goal and context, not to let the team re-litigate what to build from scratch. The Scrum Master facilitates; you bring the “why.”
Daily standup. You are not the meeting host. Attend to listen for blockers that cross team boundaries or reveal misaligned assumptions, then act on them outside the meeting. Standups that become status reports for the PM are a failure mode.
Sprint review. You own this one too. It is a working demo to stakeholders and (ideally) real users, not an internal show-and-tell. Your job is to close the loop between what shipped and what the market signal says, and to update the backlog based on what you learned. This is the most underused ceremony in most orgs.
Sprint retrospective. Facilitated by the Scrum Master. Attend as a participant, not the authority in the room. If you leave every retro without a concrete change to how the team works, the ceremony is theater.
PM vs Product Owner vs Scrum Master
Interviewers test this directly because many candidates conflate the roles.
The Product Owner manages the backlog: what gets built next, in what order, written with enough clarity for engineering to act on. The Product Manager owns the roadmap: long-term direction, business case, market context, stakeholder alignment. At smaller companies one person holds both. At larger orgs (Google, Meta, Amazon) they are separate, and the tension between PO-level detail and PM-level strategy is where miscommunication lives. The interviewer is probing whether you know which accountability is yours.
The Scrum Master is a process coach, not a PM. Their job is removing impediments and protecting the team’s working agreements, not making product decisions. When a SM starts opining on priorities or a PM starts running retrospectives, both are operating outside their lane. If you have navigated this tension in practice, name it.
Where agile breaks down
Three failure modes are worth naming in an interview because they signal that you have lived agile rather than studied it.
Mini-waterfall sprints. Sprint planning sets the scope, the team builds it, and no one questions whether the plan was right. The sprint boundary creates the illusion of iteration without the substance. Real agility means adjusting mid-cycle when signal demands it.
Velocity as a scorecard. Story points are a team planning tool. Using them to measure productivity or compare teams is a category error. A common interview trap is asking “how do you ensure the team is productive?” If your answer involves velocity targets, you will lose points with a senior interviewer.
Backlog grooming theater. A long, beautifully organized backlog of items that have not been validated with users. Grooming is necessary. Grooming unvalidated ideas is just structured guessing with extra steps.
The 2026 reframe: AI features and async eval cycles
Standard two-week sprints assume a deterministic feedback loop: build, ship, measure. AI features break this assumption. Model behavior is non-deterministic, eval cycles are tied to model releases rather than sprint calendars, and the feedback loop from a changed prompt to a meaningful output shift can be asynchronous and weeks-delayed.
High-performing AI product teams in 2026 run two parallel tracks: feature sprints on the usual two-week cadence and model or eval cycles tied to harness results and model releases. These tracks do not align cleanly. The PM’s job is to decide which decisions belong in which track and to avoid forcing async eval work into sprint-sized boxes where it does not fit.
Discovery has also accelerated in ways that should change how you run sprint planning. AI-moderated research has compressed the discovery cycle by roughly 91%, from three weeks to around three days. Always-on customer panels now cost under $500 per month. “Time-from-signal-to-shipped” is replacing interview counts as the evidence metric teams track. If your sprint planning does not incorporate weekly customer signal, you are prioritizing without evidence, and a sharp interviewer will notice.
What a strong interview answer sounds like
strong
"I think about agile as the operating environment, not the process. My job in sprint planning is to arrive with a clear goal and a groomed backlog so the team isn't re-litigating scope from scratch. In sprint review I close the loop between what shipped and what user signal says. That's the most underused ceremony in most teams I've seen. On the PM vs PO question: I own roadmap and business case; the PO owns backlog clarity and sequencing. In smaller orgs I hold both. I've also learned where agile fails: sprints that are just mini-waterfall, velocity used as a scorecard, and retros with no output. On AI feature work specifically, we ran two parallel tracks because eval cycles don't fit a two-week sprint. The key is not forcing async model work into sprint boxes."
weak
"We do two-week sprints, daily standups, and retrospectives. Agile means being flexible and customer-focused and iterating quickly." Accurate but generic. It treats the PM as a meeting organizer rather than a strategic voice, says nothing about the PM's distinct job in each ceremony, conflates the PM and Scrum Master role implicitly, and gives no evidence of having lived through failure modes. Interviewers flag this as certification knowledge without practice.
The real test is whether you can describe a moment agile did not work and what you changed. That is what separates the answer that clears the bar from one that describes a process. For more on how to think about backlog prioritization in this context, see how do you prioritize a backlog and PM vs Product Owner.