My friend and colleague Stacey shared this with me. She writes,
Over the years, I have found that I always have an internal screech
when someone uses the term “requirements gathering”. The term itself
makes it seem like the requirements are lying there, and the Product
Manager just has to grab them and pop ‘em in a document. If we were
creating custom solutions, the phrase might be more accurate – all of
the users would be identifiable, and we could truly gather requirements
from them. We’d still need to design the product in ways the user
couldn’t even imagine, but with a limited and fully identified group of
users the job would be pretty straight-forward
The requirements beast changes its face when we’re building commercial solutions. We define a market segment, to help narrow the field of potential users. Then, we have to find potentials in that market segment, and watch them in their environment. We need to interview them, to really get to know their situations. And, we need to find ways to sample the segment at large, to find out how pervasive problems really are across the segment
Each potential we visit may use slightly different ways of expressing their problems. The adjacent systems may vary from one location to another. Some problems only occur in parts of the market segment, and the problems sometimes seem to vary greatly
Product Managers must study all of this information, and somehow discern which problems are most important. We have to narrow our field of vision from “all possible requirements” down to sets of problems that, when solved, will incent people to spend money. Only then can we actually document the requirement (Every [frequency], [persona] has [problem].) and clearly guide our teams to build a product that’s worth our time and energy
To build awesome commercial solutions that people want to buy, we can’t just GATHER requirements – we have to study the market, and analyze their problems. Requirements aren’t gathered, they are DISCOVERED through our analysis of market evidence. Then, they are written with the right context to improve communication to our teams, helping our teams build outstanding solutions that resonate in the market
What do you call the process of discovering requirements?
