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:
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 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.
Lesson: Requirements gathering is not optional; you can’t wing it, and there are no shortcuts. Changing the look and feel of a product won’t solve its underlying problems. And you should never define a product solely by what it shouldn’t be.
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.
Lesson: You are not your competitors. You can’t build a replica product and expect your customers to jump on board. When gathering product requirements, always think about the needs of your specific customers and why they like your existing products. Ask yourself how you can integrate the value you offer as a company into this new product.
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.
Lesson: If you don’t work from a place of psychological safety with your customers, that is a big red flag for your team. It takes bravery and confidence to show customers your new product—and you need to do this for effective requirements gathering. Not every customer is open to trying new things, of course, but around 16% of people will be innovators or early adopters, according to the Technology Adoption Curve. Identify those forward-thinking customers and start using them in your requirements gathering process.
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.
Lesson: Don’t assume a customer’s level of interest. Get into the specifics with them. Often, customers are more curious than we think. As a product manager, you could end up delivering a feature the customer doesn’t want, and not properly delivering on the features they do want, because you didn’t ask them what they thought.
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.
Lesson: Agile is one way to manage a product or service, but not the only way. At a certain point you need to finalize the requirements and move on to the next stage. How do you know when you’re done gathering requirements? It’s simple: when the requirements have been agreed upon with the customer—and no later. You can use Agile to develop your project, but you should employ a Waterfall-style delivery. Sometimes the best answer to the customer is, “Let’s talk about that on our next engagement,” or “We want you to realize value as soon as possible, so let’s not get distracted by new requirements right now.”
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.