Going fast and breaking things has become a ubiquitous phrase in product management, akin to the widely adopted Agile Manifesto. In fact, there are so many variations of this mindset. Fail fast and learn faster. Speed is a currency. Time to market is everything. Iterate quickly. Rapid prototyping. And so it goes.

In this need for speed, I’ve seen a lot of shortcuts.

• “You don’t need to talk to the users. Our team is the voice of the customer, and we’ve collected NPS results already.”
• “We have to be agile. Start making some bets, build, and ship something so we can start learning.”
• “Our competitors have already built it this way. This is the industry standard, and we’re already behind. If we don’t have the resources, I’ll find consultants on UpWork.”

These aren’t truly agile, nor are they failing fast in order to learn and iterate. They’re just failing. It just feels palatable because it’s justified with Silicon Valley phrases and complete disregard for the survivorship bias.

The temptations to justify and succumb to the shortcuts are high. Even as I work on my personal project, I need to intentionally suppress the urges to skip the discovery process and beeline to a conclusion to show the world I’ve made meaningful, impressive progress: a visible, tangible progress.

My antidote to meaningfully slowing down and appreciating the process is to reflect on the frequent shortcuts that have plagued my product development processes in the past. By doing so, I can take proactive steps to prevent these skips from occurring and ensure a more successful outcome for my current project.

In my experience, these are the steps that are frequently cut in a product development process:

• Discovery: research and understanding user problems.
• User testing and iterative design: designing; testing through product validation with real users on the usability, functionality, and user experience; and refining the product in multiple iterations.
• QA and testing: testing the product for quality and ensuring that it meets requirements and specifications.
• Documentation and postmortem analysis: analyzing the iteration, identifying areas of learning and improvement, and documenting for reference.

For my current project, I’m straddling between the discovery, user testing, and iterative design phases. I’ve been feeling self-conscious when asked, “So you don’t have a concrete solution?” or, “So you’ve just been talking to people?”

Here’s my pep talk I give myself:

I chose not to skip the discovery phase despite being told that “building a product is all about making bets.” Making product bets isn’t a shorthand to forgo the discovery phase.

Making bets not about declaring, “This is my belief. It may or may not work, and I’m going to bet on it to find out.” Instead it’s, “Here are all the potential possibilities of how this might shake out, and based on some limited information I have, I’m going to go down this path.”

The discovery phase allows me to take calculated risks. The discovery phase increases the odds of winning the bets I make.

This is an invisible step to many, but it’s an important step for me.

Living up to a core set of values is difficult. I’m often struggling to stick to them. I’m tempted daily to dismiss and downplay the discovery work I’ve done over the past three months because I don’t have a tangible product to show for it. Perhaps you feel the same way as you build out your product or your business.

But I want to acknowledge and appreciate all the failed paper prototypes and ideas I’ve scrapped along the way, as they have refined my betting process and brought me closer to a viable solution: thank you, failures.