Hear more from Mark on integrated requirements by watching this on-demand webinar, "Best Product Requirement Management Tools," as part of our new webinar series on strategies to streamline product innovation.
"If I had asked people what they wanted, they would have said faster horses" Henry Ford's quote on 'the way its always been done'--Henry Ford
Integrated requirements and biased design thinking…
Ground breaking products requires fresh thinking about the problem in a different way and getting away from the “we’ve always done it this way” attitude. Requirements and in particular integrated requirements (requirements tied into product design) ensures you’re not backing into pre-selected solutions by not seeing viable solutions because you’ve got your prior-experience/preconceived solution blinders on.
This “pre-selection error”/bias turns out to be serious problem with plenty of product, organization, social and even tragic consequences that go along with it. Some examples from of short term/biased decisions with serious long term consequences
During my senior year in engineering school we had a required creative thinking course. At the start of the course, the class worked together on defining a problem we were going to solve as competing teams—the outcome of which would be a major chunk of our grade. Being seniors we wanted to keep the problem simple and the brainstorming session came down to “a paper airplane that went the farthest would be the winner”. The professor guided us by pointing out a few problems with our requirement:
Paper? Why not some other material? That discussion lead to removing paper and substituting an ‘object’
Went the farthest? What would you use to launch this airplane/object in a consistent way? After a long discussion it was decided we would need a standard launch platform that could consistently launch each airplane/object. A 10 foot step ladder with a shelf at the top rung was acquired from the nearest custodial closet and the top rung shelf when dropped would be the standard launch platform.
…so the requirement was adjusted to be “an object dropped [with no assist] from the [standard] 10 foot step ladder shelf [Brand X Model Z serial # 332207] that went the farthest [the point at which the object stops] as measured by tape measure [Brand Q model D; stored at room temperature (70’ F) prior to measurement [as documented by periodic temperature measurements performed by a disinterested, outside the class student—background checked for conflicts of interest] would be the winner”.
After all those arguments/discussions, the professor divided us into teams and the competition began with the ‘fly off’ taking place on the last day of class. It wasn’t long before there began to be scheduling conflicts for the launch platform and wind tunnel with a scheduling system put in place for using the test equipment (including accusations about some teams overscheduling the equipment and subletting their time for a price and rumors about industrial espionage). As designs evolved, questions arose about the environment within which the airplane/objects would be final tested… outside weather, wind, etc. Arrangements were made and the requirement adjusted (and approved by the configuration control board staffed by representatives from each team) to designate the college basketball arena as the environment within which the final fly-off contest would take place. On the last day of class, the certified ladder/launch platform as placed on the center court to provide adequate space 360 degrees around the launch platform for those airplanes/objects that might turn during flight (it was agreed by the Requirement CCB to adjust the definition of distance to convey the absolute distance from the launch platform; not just ‘in front’ of the launch platform). A random drawing was held (using the vetted disinterested outside class student) for the sequence of the launch trials. Each team launched their airplane/object which included a number of elegant airplane-like solutions (carbon fiber, Mylar skins,…)--some of which went almost to the base line from a standing start when dropped from the shelf at the top of the ladder/launch platform. Then the last team stepped forward with a SuperBall (some of you are old enough to remember the Wham-O SuperBall). The entire class appealed/demanded an evaluation of the SuperBall solution by the professor; ”an object when dropped from… “…a SuperBall met the requirements. The SuperBall team had also been testing their solution with the standard test equipment/launch platform and figured out how to place their solution on the shelf that when dropped it would consistently hit the bottom rung of the test equipment/ladder and it took off out of the basketball court and down an exit hall on the way out of the arena, blowing away the competition and getting the A in the contest.
The losers all learned a valuable lesson about preselection bias/error that day.
Preselection bias (our airplane thinking) had blinded us to other possible solutions to the requirements. How do you get past the blindness? By asking “why” and making sure the requirements are integrated into your product lifecycle so you know how requirements are satisfied and why (and presenting that why when looking at your solution/potential solutions)—so the “why” is always with you.
You can learn about the critical role of integrated requirements to drive innovation with our integrated approach to cross-domain product development by attending a live webinar on April 4, 2019, "Best Product Requirement Management Tools.
Integrated Requirements enlighten the entire product lifecycle
Remember the value of product requirements isn't simply in documenting or managing them in standalone spreadsheets or disconnected requirement tools, but in integrating them into development to influence decisions across the design chain -- providing requirements visibility to everyone from mechanical and electrical engineering, software development, testing & validation -- and further downstream to procurement, manufacturing, service, partners, and suppliers—giving everyone the ‘why’ behind the requirements; exposing your design biases in the process.