Ask the Expert: Does a Formal Requirements Process Stifle Creativity and Innovation?
Doesn’t a formal requirements process stifle creativity and innovation? Our company seems to spend more time writing requirements and specifications than we do actually writing code and developing products. Shouldn’t we value the result more than the process?
Who would start a development project without a clear idea of what the market wanted to buy? Oh wait! We do that all the time! But does the product become successful?
Requirements are merely a list of problems or features that are driven by the needs of the market. The negativity around requirements generally originates from two problems: 1) poor product management, and 2) a misguided view of innovation.
In the technology industry, innovation is the name assigned to “creativity” while requirements equates to “dull.” Missing from both typical innovation and from formal requirements is context: What is the problem? Why does it occur? Who is having it? How do they deal with it now?
IDEO, a brilliant design firm, uses a method of innovation that begins with a clear statement of the problem and then field observation of it. Sounds like requirements to me.
Innovation is not about creating cool stuff in the isolation of a development lab. Innovation is not just adding more features. The real challenge of innovative projects is knowing what features to omit. The more we understand the persona and her use of the product, the more we will know what features are mandatory and which can be safely removed.
Railing against requirements is often another way of railing against poor product management. Too often, product managers are trying to document their opinions of a successful product. Students of Pragmatic Institute® have learned that product managers are messengers for the market. They know that “your opinion, although interesting, is irrelevant.” Product managers should bring market facts to the planning session instead of their opinions. And most of all, they should put those facts into context with problems, using scenarios and personas.
The relationship between product manager and development manager is like a partnership, a marriage. Each brings something to the relationship: The product manager brings market information; the development manager brings technical prowess. One handles the business decisions while the other handles the creative ones. And when conflict occurs—and it will—the answer can be found in market data rather than opinion.
One more point about market facts: We’re not interested in what features customers say they want as much as an articulation of problems they have. Henry Ford reminds us that if he had asked the market what they wanted, they would have asked for a faster horse. Customers will ask for more of the same while continuing to struggle with problems. Product managers need to identify those problems, not ask for the customers’ wish list of features.
Great product managers observe the problems and report them to Development—in the form of requirements.
Want to see our experts in action? Attend a Pragmatic Institute course.
Looking for the latest in product and data science? Get our articles, webinars and podcasts.