Whether in phase-gate or Agile development processes, shaping a great product as a product manager necessitates dealing with requirements. Dealing successfully with requirements seems to be a recurring challenge for many organizations. It seems especially challenging for those companies leaving behind the old approach of “contract documents” growing with feature and specs creep with every new product generation. Requirements can be introduced . When such a systematic discipline is introduced into what has so far been an ad-hoc approach, experienced product managers may justifiably feel that their experience and intuition is threatened. engineering as a process framework with corresponding team roles and skills, together with methods and tools However, this is a far cry from the truth. In fact, requirements engineering does not threaten product managers in any way whatsoever. It simply qualifies their contributions towards shaping a great product through frequent and structured exposure of the work on requirements to all relevant stakeholders. As such, success of requirements engineering can be attributed to a healthy mix of: 1. Market research and analysis of customer needs and wants. 2. Experience. 3. Intuition. When starting from a blank slate, all these sources of requirements are initially equally important, if not equally available. Of course, the “importance mix” changes depending on the situation of the product being developed, as well as throughout a project. Yet, all of them need to be kept in the minds of the project team and, especially, of the product manager. Relying on a single one can spell disaster. Product managers can’t rely only on research and analysis Markets and customer segments are never static, and competitors are never to be underestimated. Waiting on market research and analyzing customers ad infinitum to figure out the “perfect” requirements leads nowhere anytime soon. Especially when a large market share is at stake, a product manager can sometimes fall victim to . I.e., deferring a decision while accumulating more and more knowledge of increasingly dubious marginal value. However, the longer one waits, the less this knowledge is relevant as things around the product change; e.g., customer needs, competitive offerings, macroeconomics, regulatory environments, etc. analysis paralysis Furthermore, market research and analysis can usually only provide the product manager with insights on the known unknowns; i.e. customer preferences of product features already imagined and described. These sources of requirements can do little for the discovery of previously unknown unknown. At best, they can be supplanted by more agile approaches, such as . Yet, these require the readiness to question market research and analysis insights, in order to determine product-market fit regardless of the potentially misleading findings of, e.g., surveys. Steve Blank’s Customer Development Perfect requirements do not exist, and they will never be attained based solely on pretend-perfect knowledge through research and analysis. Cutting these activities short means being ready to offload some of the remaining risk onto other sources of insights, such as the experience and intuition of a product manager. Product managers can’t rely only on experience An industry player with lots of experience thanks to successful products could theoretically define new products solely on the basis of predecessor products and prior customer understanding. Yet, this would be extrapolating into the future based on prior success. In other words: the very definition of market-leader hubris. If the answer to innovating with a product is simply to ratchet up the features and tech specs of previous or competing products, then you have already handed the alleged recipe for success to everyone out there who can analyze your product and also knows your customers; i.e., your competitors. Furthermore, what is developed and launched is often not the same product that’s out there a few years later. The necessity of product care and bug-fixing can cast doubt on all that precious accumulated experience after the fact, and make products successful despite the product manager’s pretend-perfect experience, rather than thanks to it. In the case of products with a long life-cycle, lessons and insights from such activities are learned only second-hand through engineers who have to clean up the mess long after the experienced product manager might have moved on to greener pastures. Perfect requirements do not exist, and they will never be attained based solely on extrapolating from the pretend-perfect experience of seasoned product managers. No matter the experience of a product manager, there comes a point in time when it needs to be validated through other sources, such as analysis and market research, or through contrasting with others’ experience. Product managers can’t rely only on intuition Finally, let’s consider intuition. A strong gut feeling about the direction a product can play a major role in product success, especially when market research and analysis are as unavailable to a product manager as prior experience. In other words, intuition plays a larger role when attempting to innovate outside of the boundaries of the past. Sometimes, intuition can be a result of a serendipitous flash of inspiration. Other times, intuition can be the result of mentally processing insights from repeat customer exposure. In all cases, intuition is unplanned and unplannable. Attempts to rationally analyze it are also notorious for turning into rationalizations. As such it makes for an unreliable source of requirements. If we were to pretend that it is a reliable source, then we would only need a clairvoyant product manager who can intuitively sense the future and is able to meet the right requirements to ensure commercial success. Perfect requirements do not exist, and they will never be attained based solely on pretend-perfect “knowledge” (actually, hunches) of what to build through sheer intuition. No matter the trust placed on a single product manager’s intuitive ability, there comes a point in time when it needs to be validated through other sources, if only to keep wishful thinking and confirmation bias in check. Reality-check work on requirements Product managers need to keep all three factors in mind. Throughout product development projects, they can rely on contacts to customers and colleagues to frequently reevaluate questions such as the following: Has enough knowledge been gathered through research and analysis? Is such knowledge-gathering reducing risk, or being used as an excuse for inaction? To what extent is past experience still applicable to achieve results in new product challenges? Do requirements reflect post-launch lessons of past project teams? Are requirements being defined too intuitively? If they are rationally justified, does the explanation hold water or does it seem to others as more of a rationalization? Whether in phase-gate or Agile development processes, shaping a great product as a product manager necessitates dealing with requirements. Using such “reality check” questions can help a product manager do so while also reducing the risks inherent in defining requirements like a risk-averse perfectionist, an infallible expert, or a clairvoyant sage. More Read on similar business challenges, and follow me and . other articles on LinkedIn on Twitter
