Gathering Requirements

I have noticed a fairly anecdotal negative correlation between the effectiveness of the interactions between a product manager and the engineering team and the frequency with which either party uses the phrase “gathering requirements”.

As I am generally curious about how language determines our understanding of the process of software development, I would like to explore a bit deeper what makes this mental model less productive than others.

I think my unease with this phrasing is really going back to what it implies about the role of the product manager and the nature of the interaction. When someone, engineer or PM, understands their task as “gathering requirements”, what I hear is an attempt to dispose of the responsibility to deeply analyze and understand the problem to be solved and to formulate a coherent strategy.

Gathering requirements expresses the idea that the information about what needs to be done is out there. It is contained in various people’s heads. All that needs to happen is to go out and harvest this information.

Following this line of thinking leads to design by committee and away from a coherent product vision, rooted in a deep understanding of the problem space.

While defining the concept of a “coherent product vision” is a challenging task, indeed, it is easy to illustrate its opposite: Collecting requirements from a group of “project stakeholders” all too often leads to a bucket list of desirable features without an apparent connection, often informed mainly by the most pressing issues that the stakeholders were facing at the time of the conversation.

This bucket list then pins down areas in solution space, skipping the essential step of anchoring their relevance in problem space. However, any coherent product strategy must be informed by a deep understanding of the problem space in question.

Better Questions to Ask

Of course, interviewing relevant parties is an important activity. This most importantly includes the future users of the system (sometimes overlooked). The problem with “gathering requirements” is not the wish to reach out but the mindset it implies. The risk is, that the product manager or the engineer in question will start the discussion with the wish to be told what they need to do.

I would argue that a better way to start the conversation is to ask “please explain your understanding of the problem”. Let them show you how they solve their problem today. If they make a concrete proposal, keep in mind that their wishes might be biased by today’s framing of the problem. Dig deeper and ask “why?”.

The goal is to understand the root of the problem. We do not want to walk out of the meeting with the requirement “need to show average monthly spending by category”. The following analysis would be more interesting: “The customer wants to be compliant with ISO-123 as it is an important sales argument. To remain compliant, the certifying body requests a monthly report. In this report, they request amongst others a proof that spending on category A, B, and C were lower than amount X.”

Productive Product Management – Engineering Dynamics

The relationship between Product Management and Engineering is often full of interesting dynamics as the perspective on the project and incentives are quite different. Nevertheless, I can say that I have experienced very constructive interactions between PMs and engineering teams. Strikingly, the more a PM saw their role as decoding the problem domain and serving as a guide to help the engineering team achieve the same level of understanding, the better the chances of such constructive interactions taking place.

I think the key is that this understanding of the problem space and the formulation of a coherent vision is the missing piece of the puzzle, the thing that the engineering team is usually unable to do on its own. This is a hard task and it requires specialized knowledge: If our customers are using our tool in drug research, it is essential to be sufficiently knowledgable in this field to develop the required deep understanding of the problem domain.

Having such an individual able to represent the customer embedded in an engineering team is amazing: There are many small decisions that we need to take all the time when building software and having someone available that can quickly provide guidance based on their understanding of the customer’s reality can save costly round-trips.

“Gathering requirements”, on the other hand, is something everyone on the engineering team could do if it weren’t for the disproportionate amount of meeting time this requires. It relegates the role of the PM to the purely administrative job of ordering ToDo items on a backlog.

While administrative work is (unfortunately) part of our jobs, the risk of a PM that is mainly “gathering requirements” is that no one is taking up the important work that your engineering team relies on to avoid building the wrong thing.