Failure, Conflict, and Pushing Back

“About a year into my PM role, I was leading the launch of a personalized podcast recommendation feature. I was excited about it it was the first feature I’d owned end-to-end, and I was convinced it was going to be a big win for engagement.

Our data science team suggested we run a four-week A/B test before full rollout. I pushed back. I thought two weeks was enough the early signal looked positive, the team had momentum, and I didn’t want to lose our launch window before a company-wide product review.

So we shipped after two weeks. And the results were not what I expected.

Engagement with the podcast recommendations was flat. Worse we saw a measurable drop in playlist listening among the same user cohort. The recommendation algorithm was surfacing podcasts at moments when users actually wanted music, and it was disrupting their listening habits. With a longer test, we would have caught this pattern the data science team had specifically flagged that behavioral patterns take 3-4 weeks to stabilize for content recommendations.

I had ignored their advice because I was optimizing for speed and visibility, not for learning. That was my mistake not the algorithm, not the team, me. I was so focused on shipping my first big feature that I let my ego drive the timeline.

After this, I made two changes. First, I committed to never overriding a data team’s recommendation on test duration without a documented justification. Second, I started separating ‘launch readiness’ from ‘my readiness to present at a review meeting’ those are two different things, and I had conflated them.

We eventually re-ran the test properly, adjusted the recommendation triggers, and relaunched three months later. The revised version performed well. But those three months were avoidable and I think about that every time I feel pressure to ship fast.”

revenue target. The proposal was to add one more ad unit above the organic results moving from two to three.

I was uncomfortable with this. Not because I didn’t care about revenue,I did, but because our user satisfaction surveys had been trending downward for two quarters, and I believed adding more ads would accelerate that decline. I also had data showing that session duration dropped noticeably on pages with higher ad loads, which suggested users were losing trust in the quality of results.

But I also understood my manager’s position. Revenue targets were real, the quarter was tight, and leadership was watching. I couldn’t just say ‘I disagree’ without offering something better.

So I spent a weekend pulling together an alternative proposal. Instead of uniformly increasing ad density, I suggested segmenting by query intent. For high-commercial-intent queries like ‘buy running shoes’ or ‘best hotel in Barcelona’ users actually expected and clicked on ads. We could safely increase density there. For informational queries like ‘how to train for a marathon’ we should hold the line or even reduce ads.

I presented this to my manager with the data. She pushed back initially segmented rollouts are operationally harder than a blanket increase. We went back and forth for about a week. Ultimately, she agreed to pilot the segmented approach for one month.

The pilot showed that we hit 92% of the revenue target from commercial queries alone, with no negative movement in user satisfaction scores. That was enough for her to approve the full approach.

I’ll be honest if she had said no after seeing the data, I would have committed to her decision. I had made my case with evidence, and at some point, the final call is your manager’s. Knowing when to stop pushing is just as important as knowing when to push.”

“I was working on a new analytics dashboard that was central to our product’s Q4 release. The feature I owned depended heavily on this dashboard, so I had real stakes in how it turned out.

The problem was that our designer and lead engineer had fundamentally different visions. The designer wanted a data-rich, highly customizable layout think drag-and-drop widgets, granular filters, the works. The engineer argued that this would take three times the estimated effort, introduce serious performance issues with large datasets, and create a maintenance burden we couldn’t sustain.

At first, I tried to stay neutral and let them work it out. That was a mistake. The disagreement festered sprint meetings got tense, decisions kept getting deferred, and we were falling behind. After about a week, I realized that staying on the sidelines wasn’t neutrality, it was avoidance.

So I set up a working session with both of them not to vote on whose vision was better, but to realign on the user problem. I asked one question: ‘What are the three things our users absolutely need from this dashboard on day one?’ We went back to our user research and recent support tickets to answer that.

It turned out that about 70% of what users actually asked for was covered by a much simpler version pre-built dashboard layouts with one or two filter options, not full customization. The designer’s full vision was aspirational, but most of it was for edge cases.

We agreed on a phased approach: launch a streamlined version with the core layouts, then iterate based on actual usage data before investing in customization features. Both the designer and the engineer felt heard because neither of them was told they were ‘wrong’ we just redefined ‘right’ using user evidence.

We shipped on time, and the dashboard became one of our most-used features. More importantly, this experience changed how I handle team disagreements. I no longer wait for tension to resolve itself. If I have a stake in the outcome, I involve myself early not to take sides, but to reframe the conversation around the user problem.”

“Three days before our biggest annual sale event, I was doing a final walkthrough of the checkout flow something I do before every major event, almost like a pre-flight checklist. I was testing edge cases: multiple discount codes, bundle offers, loyalty points combined with promotions.

That’s when I found it. When a customer applied a ‘buy 2, get 1 free’ offer and then stacked a 15% promo code on top, the system was applying the promo code to the original price of all three items including the free one. In effect, the customer was getting a 15% discount on an item they weren’t even paying for, which was being subtracted from the total cart value. On a single transaction, the difference was small maybe $3-4. But across hundreds of thousands of transactions during a sale event, this would add up fast.

I pulled the last six months of order data to see how often customers stacked discounts like this. The pattern was more common than I expected about 12% of sale-event orders involved some form of discount stacking. I estimated the potential revenue exposure at over $200,000 over the three-day sale period.

I flagged this to the engineering lead immediately, with the data and the specific edge case steps to reproduce it. They confirmed it was a logic error in how the discount engine sequenced promotional rules. The fix was relatively straightforward apply the promo code to the net price after other offers, not the gross price and we deployed it the next day.

But the bigger change I pushed for was systematic. I built a discount stacking test matrix a checklist of 15 common discount combinations that we now run before every promotional event. It takes about 30 minutes and has caught two more issues since then.

The sale event ran smoothly. But what I’m most proud of isn’t finding that one bug it’s the process I built so that we don’t rely on someone happening to test the right edge case next time.”

Next chapter: we move to the questions that test how you operate when things are messy influencing without authority, navigating ambiguity, and performing under pressure. Which, if you think about it, is basically a PM’s entire job description.