5 Common Mistakes in Requirements Gathering

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’ll 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:

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 re-releasing 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 base 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.