Tell me about a time when you did some POC but the product decided to drop it

What approach did you take to build and demonstrate the POC?

How did you gather feedback and present your findings?

How did you respond when you learned it wouldn't be implemented?

What steps did you take to understand the reasoning and move forward?

• What did you learn from the experience?
• Were there any positive byproducts or alternative applications of your work?
• How did this shape your approach to future projects?
• What was the measurable impact of how you handled the situation?

Sample Answer (Junior / New Grad) Situation: During my first year as a software engineer at a fintech startup, our team wanted to improve the user onboarding flow. I was excited to explore using a chatbot interface instead of traditional forms, as several competitors had recently adopted this approach. The current onboarding completion rate was about 65%, and there was pressure to improve it.

Task: My manager asked me to build a proof of concept for an AI-powered chatbot that would guide users through account setup. I had two weeks to create a working prototype and present findings to the product team. My goal was to demonstrate that a conversational interface could be more engaging and intuitive than our existing multi-step form.

Action: I spent the first week researching chatbot frameworks and building a functional prototype using a natural language processing library. I integrated it with our staging environment and recruited 15 colleagues to test it, gathering both quantitative metrics and qualitative feedback. When I presented to the product team, I showed positive engagement data from my tests. However, the product manager explained that user research had shown our target demographic (ages 55+) actually preferred traditional forms and found chatbots confusing. I was disappointed but asked clarifying questions to understand their research methodology and findings. I documented my work thoroughly and shared it in our team wiki for future reference.

Result: Although my POC wasn't implemented, I learned the critical importance of validating assumptions with real user research before building solutions. The product manager appreciated my receptiveness to feedback and later involved me in user research sessions. Six months later, when we explored automation for customer support (a different use case), my chatbot research became valuable and we successfully implemented a support bot that reduced ticket volume by 20%. This experience taught me to align technical exploration with validated user needs from the start.

Sample Answer (Mid-Level) Situation: As a mid-level engineer at a SaaS company, I noticed our data pipeline was taking 6+ hours to process daily analytics, causing delays in reporting. I had been experimenting with a new stream processing framework that promised 10x performance improvements. Our infrastructure team was under pressure to improve data freshness, and I saw an opportunity to make a significant impact with modern technology that I was passionate about.

Task: I proposed building a proof of concept to migrate our batch processing system to real-time stream processing. I owned the entire POC effort, including architecture design, implementation, performance benchmarking, and presenting findings to senior leadership. My goal was to demonstrate that we could reduce processing time from hours to minutes while maintaining data accuracy and reducing infrastructure costs by 30-40%.

Action:

Result: While my POC wasn't immediately adopted, the experience taught me that technical excellence alone doesn't drive decisions—organizational readiness and timing matter equally. I used the insights to contribute to the technical debt roadmap, which helped me build credibility with leadership. Eighteen months later, when the technical debt was addressed, the infrastructure team revisited my proposal and we successfully implemented a modified version of my approach. The eventual implementation reduced processing time by 8x and cut costs by 35%, processing over 50 million events daily. More importantly, I learned to validate organizational priorities and resource constraints before investing heavily in POCs, which has made me much more effective at driving adoption of new ideas.

Common Mistakes

• Blaming others -- Saying "the product team didn't understand" or "leadership made the wrong call" shows lack of maturity. Focus on what you learned and how you could have better aligned with stakeholders.
• No self-reflection -- Failing to articulate what you learned or would do differently makes it seem like you didn't grow from the experience.
• Getting too technical -- Spending too much time on implementation details rather than the business context, decision-making process, and interpersonal dynamics.
• Showing resentment -- Displaying bitterness about the rejection signals you may struggle with feedback and organizational decision-making in the future.
• Missing the "why" -- Not explaining why the POC was rejected shows lack of curiosity about stakeholder priorities and business constraints.
• No positive outcome -- Every story should end with growth, learning, or a positive result—even if indirect or delayed. If you can't find one, choose a different example.

Result: While my POC wasn't immediately adopted, the experience taught me that technical excellence alone doesn't drive decisions—organizational readiness and timing matter equally. I used the insights to contribute to the technical debt roadmap, which helped me build credibility with leadership. Eighteen months later, when the technical debt was addressed, the infrastructure team revisited my proposal and we successfully implemented a modified version of my approach. The eventual implementation reduced processing time by 8x and cut costs by 35%, processing over 50 million events daily. More importantly, I learned to validate organizational priorities and resource constraints before investing heavily in POCs, which has made me much more effective at driving adoption of new ideas.