Behavioral question
Tell me about your approach to scoping, estimation and timelining for an AI Product you have worked on.
- Behavioral
- Hard
Practice this question out loud. An AI interviewer asks it, follows up like a real interviewer would, and scores your answer. Type or speak.
Start a mock interview on this question · Mock interview from a job description
What this question tests
Tests real experience with the specific uncertainty of AI product timelines: can you show a concrete process for scoping something inherently less predictable than typical software.
How to approach it
- Pick a real AI product you worked on, ideally one where uncertainty (model quality, data availability) made typical estimation harder than usual.
- Set the Situation: what the AI feature was and why standard estimation approaches did not directly apply, such as needing to validate model feasibility before committing to a UI timeline.
- State the Task: your responsibility to produce a credible scope and timeline despite this uncertainty.
- Describe the Action: how you broke the work into a research/feasibility spike first (to de-risk model quality) before committing to a hard ship date, and how you built in buffer or checkpoint gates based on eval results.
- Give the Result: the actual timeline outcome, whether you hit it, and how the staged approach helped manage stakeholder expectations along the way.
- Reflect on what you would change in how you scope the next AI project, given what you learned about where the uncertainty really lived.
What a strong answer includes
- Distinguishes a feasibility/research phase from a build phase explicitly, since AI timelines depend heavily on model quality that is unknown up front.
- Names a concrete checkpoint mechanism, such as an evaluation gate (does the model hit a quality bar) before committing engineering resources to full build-out.
- Gives a specific, honest result, including if the timeline slipped and why, which is common and credible for AI work.
- Shows how stakeholders were kept informed through the uncertainty, rather than presenting a falsely confident single date upfront.
Common mistakes
- Describing standard software estimation with no acknowledgment of AI-specific uncertainty (model quality, data readiness).
- Presenting an unrealistically clean, on-time result with no mention of how uncertainty was actually managed.
- No mention of how stakeholders were communicated with during the uncertain phase.
Likely follow-up questions
- How did you decide when a model was 'good enough' to move from research to build?
- What would you do if the feasibility spike showed the model was not ready?
- How do you communicate timeline uncertainty to leadership without losing their confidence?
More behavioral questions
- How do you know when to cut corners to get a product out the door?Shopify · Behavioral · Medium
- How do you define a good PM vs. a bad PM?Google · Behavioral · Easy
- How did you handle communicating with various types of stakeholders on a project you recently ran and what did you find most effective?Google · Behavioral · Easy
- How do you make sure you keep improving as a PM?Google · Behavioral · Easy
- What kind of project would you like to work with?Google · Behavioral · Easy
- How would you keep developers working on a product motivated and turning out quality work?Shopify · Behavioral · Easy
More questions from Google
Learn the skill behind it
Chapters of the AI PM course that teach what this question tests.
- Chapter 13: Lead the room: staff moves, forward-deployed PM, and the portfolio
- Chapter 14: Get the job: the AI PM interview loop