5 Common Mistakes in Requirements Gathering
Requirements gathering is a crucial but often overlooked part of the development process. Steer clear of these five ineffective approaches and identify meaningful ways to improve your requirements gathering process.
Requirements gathering is a crucial but often overlooked part of the development process. Steer clear of these five ineffective approaches and identify meaningful ways to improve your requirements gathering process.
Michael is an experienced program, project, and product manager with in-depth knowledge of large-scale, global IT solutions. He has held several roles at Microsoft, including senior build product manager and senior program manager. Michael holds a master’s degree in cybersecurity, and also has a professional degree from the General Management Program at Harvard Business School.
Previous Role
Senior Build Product ManagerPREVIOUSLY AT
Those of us who were living in the US in 2013 may remember when HealthCare.gov, a new (and at that time, controversial) online marketplace for health insurance, was launched by the US government and crashed within two hours. A subsequent study by the Government Accountability Office found that the website had been developed “without effective planning” and that “key technical requirements were unknown.” User demand had also been severely underestimated. Essentially, many of the site’s failures were due to poor product requirements planning.
Requirements gathering is a crucial part of product development—and it’s also the stage at which product leaders often go wrong. Numerous studies point to ineffective requirements gathering as a source of major issues for developer productivity. In an extensive 2022 survey by CodinGame and Coderpad, for example, the main challenges for software developers were cited as “rework, changes, unplanned work, unplanned problems” and “unclear direction.” These challenges can be mitigated by implementing a robust requirements gathering process.
As a senior program, project, and product manager, I’ve witnessed a broad range of attitudes toward requirements gathering by companies and teams, some of which have ultimately resulted in wasted resources, scope creep, disappointed customers, and underperforming products. In this article, I unpack a few of these mistakes and identify key learnings so that you can avoid making these same errors.
Common Biases to Avoid During Requirements Gathering
One of the key challenges at any stage of the development process is not letting inherent biases influence our work. This is why a robust, objective requirements gathering process is essential.
Research by renowned project management expert Bent Flyvbjerg reveals several common biases that often arise in project management. In my experience, these same biases can also influence the early stages of product development. These are the ones you should watch out for:
Bias | Manifestation |
---|---|
Strategic misrepresentation | The tendency to deliberately and systematically distort or misstate information for strategic purposes (also known as political bias, strategic bias, or power bias) |
Optimism bias | The tendency to be overly optimistic about the outcome of planned actions, including overestimation of the frequency and size of positive events, and underestimation of the frequency and size of negative events |
Uniqueness bias | The tendency to see your project as more singular than it actually is |
Planning fallacy | The tendency to underestimate costs, schedule, and risk, and overestimate benefits and opportunities |
Overconfidence bias | The tendency to have excessive confidence in your own answers to questions |
Hindsight bias | The tendency to see past events as being predictable at the time those events happened |
Availability bias | The tendency to overestimate the likelihood of events with greater ease of retrieval (availability) in memory |
Base-rate fallacy | The tendency to ignore generic base-rate information and focus on specific information pertaining to a certain case or small sample |
Anchoring | The tendency to rely too heavily on one trait or piece of information when making decisions, typically the first piece of information acquired on the relevant topic |
Escalation of commitment | The tendency to justify increased investment in a decision, based on the cumulative prior investment, despite new evidence suggesting the decision may be wrong; also known as the sunk-cost fallacy |
5 Ineffective Approaches to Requirements Gathering
The requirements gathering process will look different for every company and product, and there are several approaches you can take that will lead to a successful outcome. Rather than talking about what to do, it’s more efficient to describe common missteps that will have a negative impact on product outcomes. Here are the top five mistakes to avoid during requirements gathering:
1. Defining a Product by What It Isn’t
A few years ago I was on a team handling a company intranet portal upgrade. The customer’s goal was simple: Design a new portal that does not resemble the previous failed product. (The company had recently tried to update the portal but the final solution had been rejected by the end users.) At first glance, “Not like X” might seem like a great requirement. But the team’s response was to focus on the visuals, keeping the same features and rereleasing the product with a new color and branding. Of course, this product encountered the same issues as the previous one because its features and functionality remained largely unchanged. The problem wasn’t the color or branding—it was that the product requirements had not been redefined.
2. Copying Your Competitor
A midsize company sees a competitor has taken advantage of an opportunity in the market, and it wants in on the action. Speed to market is vital, so no time can be spared to gather requirements. Instead, the team simply copies product features from its competitor. The customer’s response is: “Where are the support features in this product that we value in your other products?” and “How does this product integrate with the other products we have already purchased from you?” The lack of a coherent answer to these questions results in a frustrated product team and unsatisfied customers.
3. Not Engaging With Customers
I was once on a team at a new company that had built a product with amazing features that outperformed the competition. Unfortunately, the team forgot one vital element in the requirements gathering process: the customer. In fact, they were fearful of engaging with them, leery of negative feedback, and afraid of a poor product-market fit being revealed. Thus, the set of product requirements they had developed lacked vital customer input.
4. Creating Unnecessary Features
As product managers, we must be experts on our customers’ needs. If the services your company provides are B2B, you must even understand your customers’ customers. Success is the customer wanting what they get. In order to know what your customers want, you can analyze reports, read articles, and attend conferences—but to gain the clearest insight, you need to ask them what they want.
I have learned this lesson myself the hard way. On one project, we had engaged with customers and other stakeholders and developed a list of product requirements. However, when it was time for me to create user stories, I didn’t confirm each one with the customer. I thought they wouldn’t care about a back-end logging feature or a minor Kubernetes infrastructure node configuration change—basically, anything that wasn’t UI- or UX-based. But I was wrong. One specific customer was obsessed with all the features in our product and wanted to know about every layer of its functionality, and even had new ideas for useful features.
5. Believing Agile Is the Only Way
Recently, I was on a team at a large IT services company delivering a customer engagement product. The product scope was that a small team of consultants would visit the customer’s site, deploy our proprietary software analysis product, and analyze the customer’s network for cloud connectivity issues and opportunities. After the service was delivered, a report would be sent to the customer. It was a simple Waterfall product delivery with fixed deliverables, timing, and costs. A few hours into the on-site delivery, the customer found other network issues that did not involve the technology we had agreed to scan. “Let’s be agile,” they said, and asked us to change our product to analyze the printers, firewalls, and client connectivity issues. The product requirements had already been agreed upon, however, and we needed to prevent scope creep. We opted to deliver the current product, then take the new customer requests and use those as requirements for a future version.
Implement These Lessons for a Robust Approach
Requirements gathering is a vital stage in the development of any product and should not be overlooked. The basis for a product cannot be what you don’t want it to be, nor should it simply be a replication of something already on the market. Engage with your innovator and early-adopter customer bases to get their valuable insights, and don’t be afraid of asking questions to ensure you’re not wasting time building unnecessary features. Know when to finalize the requirements and move on, or use a Waterfall approach for delivery. Implement these lessons for requirements gathering at the outset of your projects for productive teams, happy customers, and successful outcomes.
Further Reading on the Toptal Blog:
Understanding the basics
What is requirements gathering?
Product requirements gathering is the process of identifying and documenting the needs and specifications of a product, including its desired functionality, features, and constraints. It involves researching, collating information, and prioritizing requirements.
Why is requirements gathering important?
Product requirements gathering is a crucial phase that sets the foundation for successful product design and implementation. The goal is to ensure comprehensive understanding of what the product should achieve. This helps minimize misunderstandings, prevent scope creep, and ensure the product meets customer needs.
What are best practices for requirements gathering?
Best practices for product requirements gathering include defining a product by what it should be (not what it shouldn’t), being original instead of copying competitors, engaging with customers, ensuring all features are necessary, and knowing when to finalize requirements and move on to delivery.
İzmir, Turkey
Member since April 29, 2021
About the author
Michael is an experienced program, project, and product manager with in-depth knowledge of large-scale, global IT solutions. He has held several roles at Microsoft, including senior build product manager and senior program manager. Michael holds a master’s degree in cybersecurity, and also has a professional degree from the General Management Program at Harvard Business School.
Previous Role
Senior Build Product ManagerPREVIOUSLY AT