September 30, 2023

Common mistakes during requirements gathering

Understanding and Improving Requirements Gathering for Better Product Development
Common mistakes during requirements gathering

All my experience not just as a product manager, but at any project showed an important lesson: requirements gathering is not just a checkbox in product development—it's the cornerstone. A 2022 study conducted by CodinGame and Coderpad underscores this, indicating that software developers often grapple with challenges like "rework, changes, unplanned work, unplanned problems" and "unclear direction"—issues largely avoidable with robust requirements gathering.

The Real-World Impact of Requirements Gathering Gone Wrong

I've journeyed through roles as a senior program, project, and product manager, and along the way, I've observed companies and teams mishandle requirements gathering. The repercussions? Wasted resources, escalated project scopes, disillusioned customers, and products that barely make the mark. Let’s dive deep into the common pitfalls and how to sidestep them.

The Behavioral Biases Threatening Effective Product Development

Bent Flyvbjerg, a revered figure in project management, has meticulously highlighted several biases that plague project execution. Frighteningly, these biases can also worm their way into the nascent stages of product development:

1. Strategic Misrepresentation (or Political/Strategic/Power Bias): This is the intentional misrepresentation of data for vested interests. Example: A team might overstate the capabilities of an upcoming product to secure more funding or approval, even if they know it's a tall order.

2. Optimism Bias: Overconfidence about the positive outcomes and underestimation of negatives. Example: Believing that the product will be ready for market in three months when a more realistic timeline is eight months.

3. Uniqueness Bias: Viewing your project as unparalleled or one-of-a-kind. Example: Thinking your product is the only one addressing a certain need, even when competitors exist.

4. Planning Fallacy: Underestimating challenges and overestimating the positives. Example: Assuming that implementing a new feature will be quick and straightforward, when it actually requires significant resources.

5. Overconfidence Bias: Having an inflated belief in one’s own judgment. Example: Ignoring market research because of a personal belief that a certain feature is essential.

6. Hindsight Bias: Believing past events were predictable. Example: After a product fails, believing you "always knew" a certain feature wouldn't resonate with users.

7. Availability Bias: Relying on immediate examples that come to mind. Example: Designing a feature based on feedback from a small group, while ignoring broader market data.

8. Base-rate Fallacy: Disregarding general information and focusing on specifics. Example: Ignoring industry trends because one customer gave specific feedback.

9. Anchoring: Being overly influenced by the first piece of information encountered. Example: Fixating on the first price point discussed, even if further analysis suggests it’s not viable.

10. Escalation of Commitment (or Sunk-Cost Fallacy): Continuing a project due to the amount already invested, even when it's clear it might not yield returns. Example: Continuing with a doomed product feature because of the time and money already poured into it.

Five Common Missteps in Requirements Gathering: Lessons from the Trenches

1. "Define by Absence" Syndrome:The Case of the Failed Intranet Portal Upgrade: A company aimed to revamp its intranet portal. The directive? "Make it not like the last one." Instead of redefining features, the team focused on aesthetics. The result? A new-look product with the same old problems.

Takeaway: It's futile to define a product by what it isn't. Dig deeper than surface-level changes and try to find out the core reason behind previous failures.

Ideas that might help to avoid:

5 Why technics or laddering can help with it.

2. The "Mirror Image" Approach:The Tale of the Me-too Product: A company, in haste, cloned a competitor's product. The missing piece? Their unique brand value and integration capabilities, leading to customer discontent.

Takeaway: Your value proposition is unique; imitating competitors can't replicate that. Understand and cater to your customer's specific needs.

Ideas that might help to avoid:

Understanding of Kano model might be very beneficial to look for the other side.

3. Fear of Feedback:The Silent Product Launch: A team developed a product with superior features but without engaging the customer. The result? A product that lacked real-world relevance.

Takeaway: Always involve customers. Embrace feedback, and seek out the innovators and early adopters among them.

Ideas that might help to avoid:

Learn more about user personas and why its important to update them.

4. Feature Overload:The Back-end Logging Misadventure: While I assumed customers wouldn't be interested in non-UI features, one customer was deeply invested in understanding every aspect of our product.

Takeaway: Never underestimate a customer's curiosity or input. Every detail matters.

Ideas that might help to avoid:

Learn about importance vs satisfaction framework

Learn about needs prioritization

5. The Agile Misconception:The Cloud Connectivity Product: A product delivered based on pre-agreed requirements was suddenly met with additional requests from the customer. Instead of succumbing to scope creep, we delivered the original product and considered the new requirements for future versions.

Takeaway: While agility is key, there are times when requirements need to be frozen. Understand when to say "not now."


Requirements gathering isn't just a phase—it's the foundation. Understand what your product aims to achieve and refrain from mere imitation. Engage with your users, embrace their feedback, and be aware of when to finalize requirements. Equipped with these lessons, set the stage for a product that delights users and stands tall in the market.

Related News

October 12, 2023
Software deployment is a multi-faceted process that goes well beyond writing code. It involves meticulous planning, development, testing, and eventual release to ensure software quality and reliability. Any product manager should understand challenges and processes behind the scene. As you know, creating software is not just about creating it in lab conditions, but also needed infrastructure to make sure it will work in different environments and error-free. Today, I aim to describe this process, providing you with a clearer understanding of how companies typically ship code to production.
October 3, 2023
Understanding data is fundamental in product management. It aids in making informed decisions, gauging product success, and understanding user behavior. The two primary types of data that every product manager should be familiar with are: quantitative data and qualitative data. Lets check the difference:
October 6, 2023
In the evolving product design and development landscape, understanding the end-user has never been more critical. As businesses oriented to user centric product, user research becomes more and more important. This guide, a comprehensive walkthrough of user research, aims to arm you with the process and types of research needed to put the user at the heart of your designs.