People I speak to often talk about “requirements gathering” and “requirements capture”. But I think this creates the wrong mindset, leading to a poor outcome. These phrases imply that requirements are waiting to be collected, and they just need someone with a big enough scythe to harvest them, or a butterfly net to catch them and bring them down to earth.

But the truth is that requirements are largely unknown, which is why I prefer the phrase “requirements discovery”. And not only is a journey of discovery required, but that journey needs to be undertaken by a mix of people, because they bring different perspectives, which all need to be considered.

In a simplified world of just developers and product managers, we can roughly say that product managers understand what’s valuable and developers understand mechanisms for getting there, and the rough costs of that. They might also suggest new directions to go in. The team must work together to find the best outcome. There are countless times when I’ve seen technical and non-technical people planning a product together, bouncing ideas off each other, help each other see the problem in new ways and opening up new options.

If you’re more mathematically inclined you can look at it as an optimisation problem. The best outcome might be something like value/cost, or maximising the value within a cost limit. The team finds itself at a particular point in the landscape and together must plot a viable path to the highest (most optimal) point. The path is as important as the endpoint — there’s no point getting to a desirable place if it takes a long time and doesn’t deliver sufficient value in the meantime.

The requirements landscape needs to be uncovered, and it needs a team to work together.