Keep Your Requirements Close But Your "Crazy Ideas" Closer

One of the courses I teach, which I’m quite proud of, is the capstone course for the CS and IT majors.  In the two semester course, we design, build, and release something to the world.  The projects are based on interests in the various groups, usually 2-4 people per group.  We’ve built robots, network sniffing tools, video games (some better than others ;)), and a variety of web portal kinds of tools.  This cycle, one student team built an existential video game called Unbearable which was impossible to win and whose arcade-style high score tracker published random numbers.  It was a silly game on the surface but had lots of ironic and fun easter egg kinds of behavior.

The other teams collaborated to build what was functionally a tele-presence device.  The intent of the device when they started was to be able to “call home” to see your dogs and make sure they were ok.  They had promised “bark recognition” software that would send you a text if the dog was barking too much and a Pan-Tilt-Zoom functionality for the camera so you could watch the dog.  Early designs had a ball thrower so you could play with the dog remotely but that was simply too complex for the time we had.  There had been some discussion about blowing bubbles for the dog to chase instead or perhaps giving the dog “some kibble” to get it to come to the device.  The “kibble launcher” became the in-joke for the two semesters but was kind of moved to “nice to have” instead of a requirement.

Last night, the team demo’d their product with the intent of showing the customer that the product should be funded to actually be built.  One of the team members brought their dog in to show the reaction to the device.  Generally, the dog was less than impressed J  We joked that they should have included the “kibble launcher” after all to get the dog’s attention.  The student responsible for the case that the telepresence device lived in reached under the desk and pulled out a small box-like object which he hooked onto the side of the device.  You could see there was a place for wires and a motor though they had not actually been installed.  He then reached into his backpack and pulled out a baggie of dry dog food which he loaded into the new add-on.  It was manually activated but the dog was excited to get some “kibble” so at least hung around the device during the demo.  Network issues in the classroom prevented the demo from working well but we had seen the process work in the past. 

The reason I bring this all up is that the “kibble launcher” started as a joke with the team while we were brainstorming the functionality of the product.  In brainstorming, you write down all the ideas that come up, no matter how odd they may seem.  Using Affinity Diagrams and other tools, we pared down the ideas to a manageable number of requirements to build.  The launcher was decided to be a “if we have time” kind of feature and it was shelved.  But, we made so much fun of the idea that the cabinet builder kept thinking about how to actually do it.  He mocked up a prototype which he proudly displayed last night.  It helped their product and would have differentiated it on the market if we had really built it. 

My point is that we often come up with crazy ideas in brainstorming sessions and we filter them out right away because they’re silly/stupid/too expensive.  But sometimes, those ideas live on and we find a way to incorporate them into the product.  And we should.  Those “crazy ideas” are how we sometimes get new, cool products.