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."
Conclusion
Sergey
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.
