Innovation, Design, and Requirements

ArgonDigital - enterprise automation experts

Share This Post

About the same time I read Joe’s post Who’s the Designer—It Depends, I also read a great article by Geoffrey Moore on the Top 10 Innovation Myths. These two articles collided in my brain and gave me a new angle from which to explore Joe’s post.

Joe raises an interesting question: when writing requirements, should we describe the characteristics of a solution (pure requirements) or simply prescribe a specific solution (design)? He concludes that this is a business decision and the answer depends on the circumstances.

Moore’s Myth #3 is “It is good to innovate.” When discussing this myth, Moore points out that innovation in and of itself is not the goal. Innovation which leads to consequential product differentiation is the goal. Moore further notes that innovation which doesn’t lead to consequential product differentiation “…costs money and entails risk but does not create competitive advantage.”

The debunking of Myth #3 leads to an interesting corollary to Joe’s arguments. Pure requirements allow innovation. But, as Moore points out, innovation is not always a good thing. Therefore, when deciding where we need to land on the spectrum between pure requirements and design, one factor to consider is the potential benefit, or lack thereof, of innovation.

Moore gives us more to consider about where we want to land on the spectrum with respect to next generation products. When throwing light on Myth #1, “When innovation dies, it’s because the antibodies kill it,” Moore shows how legacy commitments to an existing customer base can derail innovation for next generation products. The decision to design, rather than write pure requirements, also limits innovation. Coupling these together in the form of a decision to design a next generation product may result in a virtual absence of innovation, leading to a lack of consequential product differentiation, resulting in the stagnation and eventual death of the product. Therefore, we should be cautious about falling too easily into the decision to simply design next generation products.

Joe’s question is always a tricky one. And, the answer is still “It depends.” But, Moore gives us a few more things to take into account when making that decision.

More To Explore

b2b auto pay

B2B Auto Pay: Automation Use Cases

Migrating a B2B “Auto Pay” Program Companies migrating to SAP often have daunting challenges to overcome in Accounts Receivable as part of the transition. You might have different divisions running

ArgonDigital | Making Technology a Strategic Advantage