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

In my first year, I was asked to do a short investigation on whether we could add a bulk edit flow to an internal tool our support team used. I built a small prototype that covered the core interaction and found that the technical part was manageable, but it also exposed a lot of validation rules that would make the user experience more confusing than we expected. In the review with my lead and product manager, they decided not to move forward because the support team had a bigger pain point elsewhere and this one would take more effort than the impact justified. I was a little disappointed, but I wrote up the edge cases and what we learned so we would not have to rediscover them later. That helped on a later project because we reused part of the validation approach and I also got better at keeping these investigations tightly scoped.

In my second month at a small consumer app startup I volunteered to prototype an offline caching and sync flow because I’d spoken with customer support about users in areas with flaky internet. Over a week I built a basic prototype that stored edits locally and replayed them when the device came online, including a simple rule for handling conflicts. In the roadmap review the product manager chose not to greenlight it: analytics showed most of our active users were on stable connections and the team couldn't commit the extra QA and monitoring work required for a safe rollout. I was disappointed — I really wanted to make the app more reliable for those users — but I packaged the prototype into a reusable module, wrote a short design note and a test plan, and shared the learnings with the team. A few months later someone used the module in a hack day and the design note made it much faster to build a more robust version. The experience taught me to tie POCs more explicitly to measurable business signals and to structure prototypes so they can be salvaged if priorities change.