Check-out this paper by ME310 2013 TAs Tyler Busnell, Annika Matta, and Scott Steber (with some input by Mark C., George T., and Larry L.) Using Dark Horse Prototypes. It contains a couple of good examples from Thales and Swisscom projects.
Some years ago we decided that the first prototype of winter quarter should be a ''dark horse." The idea is to go for something radical that was NOT focused on for the Fall quarter vision informed by the previous CFP-CEP. A good example might be a technology or approach that was uncovered during fall quarter benchmarking and briefly considered, but ruled out because it was seen as "too risky," or "too difficult to complete," or the team thought "we don't have the right talent on the team" with the knowledge and resources available during fall quarter.
Team Audi in 2017 had a project prompt on making shared cars feel more personal to the renter. Their dark horse was a HitchHikerBot:
'HitchHikerBot done by Audi in 2017'
'HitchHikerBot attached to the back of a car'
Check out more about Audi's Dark Horse here: Audi Dark Horse
Another good example: from a team that was challenged to invent new approaches to video capture. They followed a very good CFP (which they could easily have stuck with for their final project) with a more radical idea, which became their final project direction.
Design is a series of diverging and converging cycles. Fall quarter has mostly been about diverging, but you ended with a strong converging cycle with your CFP, CEP and final presentation. Taking a "dark horse" idea to the point where you can evaluate it helps to keep the design space from shrinking too fast and to preserve ambiguity. Even if you don't ultimately decide to "change horses," you will likely gain requirement insights that make your final design better (more novel, more sophisticated, better validated). Read the paper cited above to see how you will be a winner no matter what your dark horse does, if you embrace the mission.
If you don't do it now, you never will. As the winter quarter progresses you will focus increasingly on "What are we actually going to deliver in June?" You will be getting increasingly realistic about the scope of the project and you will be rushing to complete the FUNK-tional and FUNC-tional Prototypes.
Over the years we have seen almost all imaginable ''good reasons" why a proposed product or service concept will "never work." Among the language you are sure to have heard are things like "It's impractical", "Management will never go for it", "We need an expert opinion before we try this", "We tried something like this before and it did not work", etc. The Dark Horse is an antidote to such thinking: explore something "impossible" to discover what is both possible and exciting.
Ideas should never be "killed" or "tossed." Instead, certain ideas are only prioritized until it's time to revisit ideas that may not have seem as promising. The Dark Horse prototype is the perfect opportunity to explore the ideas that were not as high of a priority from before. -LD
We expect functional hardware and software that reveals the nature of your Dark Horse as defined by your design team. At all times keep a record of:
what you did,
why you did it,
what you learned from doing it.