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?
Subscribe to:
Post Comments (Atom)
1 comment:
Absolutely! I wrote about the same concept in Stop gathering requirements, where I said that "A product manager who just 'gathers requirements' is doing nothing more than taking orders or documenting requests. Good product managers add value to their product by understanding the problems and needs behind requests."
Post a Comment