It Didn’t Work - Or Did We Just Do It Wrong?

I’ve often heard product teams say things like, “We tried that before,” or “The data shows users didn’t click on it,” or “That idea just doesn’t work.” It’s a familiar pattern - a feature, campaign, or flow gets dismissed because the results weren’t great. But the truth is, most of the time, it’s not that the idea didn’t work; it’s that it wasn’t done right, or not released at the right time, or not to the right audience.

As designers, product managers, and leaders, we all rely on data and feedback to make decisions. But data without context can be misleading. A low-performing feature might have been buried behind the wrong entry point, launched without communication, or introduced to users who didn’t need it yet. Sometimes, timing alone decides success or failure.

I’ve seen ideas that failed once succeed spectacularly later - not because the concept changed, but because the execution did. A better rollout, improved onboarding, or sharper messaging can completely transform user adoption. What didn’t work before might just need the right story, or the right level of visibility, to click with users.

There’s also a psychological side to this. Teams tend to treat past failure as absolute proof that something can’t work. But product development isn’t binary. What fails in one stage of growth might succeed at another. What users ignore today might be valuable once their needs evolve or when adjacent features make it relevant. Dismissing ideas too quickly can close the door on future potential.

This is where the importance of diagnosis over decision comes in. Instead of simply asking “Did it work?”, ask “Why didn’t it work?” Did users understand the value? Was the problem real enough for them to care? Was it introduced at a time when other priorities distracted them? The answers to those questions lead to better design and better business judgment.

For leaders, this mindset is essential. Teams look for permission to re-explore ideas that once failed. Creating an environment where “let’s try again differently” feels safe encourages experimentation and learning. Failure stops being an endpoint and becomes feedback for refinement.

I once worked on a feature that users completely ignored at launch. The instinct was to remove it. But after watching sessions and talking to users, we realized it wasn’t the feature that failed - it was discoverability. We repositioned it in the flow, made it visible when the user needed it most, and adoption jumped by more than half. The core design didn’t change - context did.

That’s why, when someone says, “We already tried that,” I’ve learned to pause. The follow-up question is, “Did we try it in the right way?” Because in product design, timing, context, and execution often matter as much as the idea itself.

Innovation rarely comes from new ideas alone - it comes from persistence, from trying again with better understanding. When something doesn’t work, it’s not a verdict; it’s an invitation to look deeper. To test assumptions, refine delivery, and see what happens when it’s done right.