Tell me about a time when you or your team were more than half way to meeting a goal when you realized it may not be the right goal.

What steps did you take to communicate this realization to stakeholders?

How did you propose or implement a course correction?

How did you manage any resistance or concerns?

• What was the impact of changing direction versus continuing on the original path?
• What metrics or evidence showed this was the right decision?
• What did you learn about goal-setting and validation?

Sample Answer (Junior / New Grad) Situation: During my internship at a fintech startup, I was tasked with building a dashboard to track daily active users for our mobile app. We were about six weeks into the twelve-week project when our product manager mentioned in a standup that several customer support tickets were coming in about refund processing delays. I started digging into the data and realized that user engagement wasn't actually our biggest problem—transaction failures were causing users to churn before they could even become active users.

Task: As the sole intern working on analytics tooling, I felt responsible for ensuring my work would actually move the needle for the business. My manager had given me autonomy to execute on the dashboard, but I knew I needed to raise the flag that we might be solving the wrong problem. I needed to gather evidence and present an alternative approach without seeming like I was questioning the entire product strategy.

Action: I spent two days analyzing our funnel data and user feedback logs, and created a simple analysis showing that 40% of new users experienced at least one failed transaction in their first week, and 75% of those users never returned. I scheduled a 30-minute meeting with my manager and the product manager, where I presented my findings and suggested we pivot to building a transaction health monitoring dashboard instead. I acknowledged that the DAU tracking was still valuable, but proposed we could create a simplified version in two weeks and dedicate the remaining four weeks to transaction monitoring. I also reached out to the customer support lead to understand which transaction metrics would be most actionable for them.

Result: The leadership team agreed with the pivot, and we shipped both dashboards—a lightweight DAU tracker and a comprehensive transaction monitoring system. Within three weeks of deploying the transaction dashboard, the engineering team identified and fixed two critical bugs that were causing 60% of the failures. Our transaction success rate improved from 82% to 96%, and our week-2 retention rate increased by 18 percentage points. This experience taught me the importance of continuously validating that your work aligns with actual business needs, not just the initially stated requirements. I now make it a habit to check in with cross-functional stakeholders throughout any project to ensure I'm on the right track.

Common Mistakes

• Defending the original goal -- Interviewers want to see intellectual humility, not stubbornness in the face of new information
• Blaming stakeholders for poor goal-setting -- Focus on how you took ownership of recognizing and fixing the problem, not who set the wrong initial goal
• Lacking concrete evidence -- Strong answers include specific data or insights that revealed the misalignment, not just intuition
• No business impact metrics -- Quantify both what you would have wasted by continuing and what you gained by pivoting
• Glossing over the difficult conversations -- Interviewers want to hear how you navigated the stakeholder management challenge of changing direction mid-stream
• Not learning from it -- Miss the opportunity to share what systematic changes you made to prevent similar misalignment in future projects

Result: We pivoted the project and launched the research assistant tool three months later. Within the first quarter after launch, our time-per-article decreased from 5.5 days to 2.8 days, and our article output increased by 65% with the same headcount. The editorial team's satisfaction scores with our tools jumped from 6.2 to 8.7 out of 10. More importantly, this experience fundamentally changed how we approach roadmap planning—we now include mandatory user research sprints at the 30% and 60% completion points of major initiatives. I learned that technical elegance means nothing if you're not solving the actual constraint in your users' workflow, and that having the humility to reassess your goals mid-project is a strength, not a weakness.