Ever made a gut decision that turned out wrong? You’re not alone.
In my early career, I managed a mobile mapping app, and, like many new product managers, I relied heavily on my gut instinct. At the time, my process involved two simple steps.
There wasn’t much emphasis on product discovery or gathering user feedback before we got started. Instead, we worked off what I thought customers needed and what we believed would set us apart in the market. In other words, a bunch of assumptions.
I vividly remember sitting in countless meetings where we’d brainstorm feature ideas and make quick decisions based on what felt right at the moment. In many cases, we believed that if a feature seemed useful to us, it would automatically be useful to our users too. And because there was constant pressure to ship features fast, we moved forward without much validation.
But the results were often disappointing. A large portion of the features we developed didn’t get any traction. Users simply weren’t adopting them and they certainly did not have any meaningful impact on any of our business objectives. I remember one particular feature, a complex offline mode, that we spent months developing. We were convinced it would be a game-changer for field workers who didn’t have reliable internet access. But once it was launched, hardly anyone used it. It turns out, most of our users didn’t really need that level of offline functionality, and we had overlooked more pressing pain points that would have made a bigger impact.
At the time, it felt frustrating. We were putting in all this effort, yet the features weren’t resonating. Looking back, it’s clear that we were building purely based on assumptions, not actual user needs. That’s when I started to realize that relying on gut instinct wasn’t working, and something had to change.
Around that time, I started hearing more about digital product discovery. I remember attending a workshop where the facilitator talked about validating ideas through customer research before jumping into design and development. They emphasized the importance of understanding the problem before proposing solutions. It felt like a light bulb moment. Up until that point, we had been starting with the solution, i.e. deciding what features to build, before we even fully understood the problem our users were facing.
I decided to give this new approach a shot. My first step was to sit down with actual users and talk to them, something I realized I hadn’t done nearly enough in my previous role. I started asking questions about their pain points, their workflows, and what they were trying to achieve. The insights were eye opening to say the least. It turned out that many of the features we thought were important were not even on their radar. Instead, they had very specific issues we had never considered. For example, I spoke to a customer who was struggling with the speed of saving some forms, which was slowing down their fieldwork. Fixing that problem would have provided immediate value, but we had been focused on adding shiny new features instead.
This user research was just the beginning. I learned how to run quick experiments, like prototyping ideas and getting feedback before committing to a full build. I also leveled up my proficiency with data & analytics so that I could better understand how users were interacting with the product.
Once I embraced the idea of product discovery, everything started to change. I no longer felt the pressure to come up with feature ideas on my own or rely solely on my instincts. Instead, I let the process of discovery guide us. It wasn’t just about what we could build anymore, it was about what we should build and that made all the difference.
The first major shift was how we kicked off projects. Instead of jumping straight into feature selection and design, we started with discovery. This meant spending time with our users, digging into their workflows, and identifying real problems that needed solving. We weren’t guessing anymore. We were asking questions and listening carefully to the answers.
One of the most valuable things I learned was that discovery didn’t have to be a long, drawn out process. We could do quick user interviews, run lightweight experiments, or even use analytics to validate an idea before investing time and resources into building it. For example, instead of developing an entire feature based on a hunch, we started creating simple wireframes or prototypes to test with users first. This way, we could see how they interacted with the idea and gather feedback before moving into full development. It was an eye opener to see how small adjustments based on user feedback could completely change the trajectory of a feature.
As a result, the design phase became much more focused. Instead of brainstorming features in a vacuum, we were designing solutions to problems we knew our users were facing. There was a clear purpose behind every decision. And because we had validated the need for a feature through discovery, the design process feels less risky and more grounded in reality.
Finally, when we got to the development stage, it was smoother than ever. We weren’t scrambling to adjust features based on vague feedback or last-minute pivots. Engineers were working on features that had already been tested and iterated on. It gave us more confidence in what we were building, and that confidence was reflected in the quality of the final product. We saw fewer reworks and wasted cycles, and more importantly, we saw higher adoption rates from our users.
A perfect example of this new approach in action was a feature we developed for one of the SaaS products I now manage. Initially, we had planned to build a dashboard that displayed various user metrics, based on what we thought would be useful. But through product discovery, we found out that users were overwhelmed by too many data points. What they really needed was a simple, clear overview of the most critical metrics. By focusing on what the users truly needed, we ended up designing a dashboard that was not only easier to use but became one of the product’s most popular features after launch.
Once we made the shift to a continuous discovery approach, the results became clear almost immediately. The impact of this change wasn’t just felt in the quality of the products we were building, but also in how we worked as a team and how our users responded to what we delivered.
First and foremost, the most noticeable improvement was the adoption rate of new features. Previously, we had struggled with low adoption because we were building features that we thought users wanted. But with product discovery leading the way, guided by structured product frameworks like the Jobs to Be Done (JTBD) or Lean Canvas, we were now building features that users actually needed. Our development efforts were directly tied to solving real problems, and because of this, we saw an uptick in feature usage almost right away.
For example, we had once built a complex reporting feature that barely anyone used. In our new approach, we spent time talking to users to understand what they really needed from their reporting tools. It turned out they weren’t interested in the extensive custom reports we had built. They wanted a simple way to track just a few key metrics that were critical to their day-to-day operations. So, we simplified the reporting feature, and after launch, it became one of the most-used areas of our platform. That was a huge win.
Not only did adoption improve, but we also started to see better feedback from our users. Instead of receiving vague or negative comments about features not meeting their needs, we were hearing how our product was solving real problems. Users felt heard because we were involving them early in the process and building based on their actual pain points. This was a huge shift from before, where feedback often came after we had already built something and moved on.
The team dynamics also improved. Before, there was always a sense of urgency and pressure to ship features, even when we weren’t sure if they were the right ones. But now, the development process felt more focused and strategic. There was less back-and-forth, fewer reworks, and a clearer sense of direction. The design and development teams appreciated that the features they were working on had been validated and had a higher chance of success. It felt less like a guessing game and more like we were executing on a well researched plan.
One of the biggest benefits was that we were saving time and resources. By validating ideas before diving into development, we avoided building features that would ultimately go unused. This meant we could focus our time on the things that really mattered and would move the needle for our users and the business. It was a more efficient way of working, and the ROI became evident in how much less we wasted on development that didn’t lead to customer satisfaction or business growth.
Overall, the shift to product discovery brought clarity to our entire process. We weren’t just building for the sake of building anymore. We had a clear sense of purpose, grounded in user feedback and data. It was a transformation that not only improved the quality of our products but also deepened our relationship with our users. They trusted us more because they could see that we were truly solving their problems, not just pushing out features we thought were important.
Looking back, the transition from a gut based approach to a product discovery led process taught me more than I ever expected. It wasn’t just about adopting new techniques, it was about shifting my mindset as a product manager. Here are the key lessons that stuck with me.
I learned the hard way that relying on instinct to make product decisions is like driving a car without instrumentation. You have some idea of how far you are going or the amount of fuel remaining, but the risk of not making it is pretty big. Early on, I thought my instincts would lead me to the right solutions, but time and time again, they failed me. Without actual user feedback or data, those “gut feelings” were often disconnected from what the market truly needed.
The most important shift in my thinking was understanding that product discovery isn’t just an extra step, it’s the foundation. By starting with discovery, I was able to understand what users were trying to achieve, what problems they were facing, and where our product could make the most impact. It gave us confidence that we were solving the right problems, rather than just shipping features for the sake of it. This shift led to more impactful product releases and much happier users.
Before product discovery, we would commit to building entire features without any real validation, only to find out after launch that they didn’t resonate with users. I now know that you don’t need to dive headfirst into full development without testing the waters first. Running quick experiments, creating simple wireframes, and testing with users before committing to an idea saved us time, money, and a lot of frustration. Validation has become a non-negotiable part of the process, and it’s made all the difference.
One thing I’ve learned is that listening to users doesn’t mean you just build whatever they ask for. Instead, product discovery helps uncover the underlying problems they face, which can often be different from the solutions they suggest. It’s our job as product managers to distill that feedback and turn it into something valuable. For example, users might ask for a new feature, but through discovery, you might find a simpler way to solve their problem without over-complicating the product.
Another big takeaway was how important it is to bring the whole team into the discovery process. Before, there was often a disconnect between what product management wanted to build and what the development team was working on. Now, because everyone is involved from the start, the whole team has a clear understanding of why we’re building what we’re building. This shared understanding has fostered better collaboration and led to smoother development cycles.
One of the hardest lessons for me was accepting that it’s okay to be wrong. Early on, I thought being a good product manager meant always knowing what to build. But now, I see that being open to learning is far more important. The beauty of product discovery is that it gives you the space to make mistakes and adjust before you’ve invested too much in the wrong direction. I’ve embraced being wrong as part of the process, and it’s made me a more effective product manager.
These lessons have not only shaped how I approach product management but have also given me a deeper appreciation for the process itself. The shift to continuous product discovery wasn’t easy, but it’s been transformational. It’s allowed me to build products that matter, foster stronger relationships with users, and collaborate more effectively with my team.
If there’s one thing I hope other product managers take away from my experience, it’s this. Trusting your gut can only get you so far. Real success comes when you start with discovery, involve your users, and let the data guide your decisions. Embrace the process, and you’ll see the difference in the products you build, the teams you lead, and the satisfaction of your users.
If you’re still relying on instinct to make product decisions, now’s the time to rethink your approach. Start small by incorporating more user interviews, running a few experiments, or setting up a feedback loop. The results will speak for themselves. Trust the process, not just your gut.