Warning: strip_tags() expects parameter 1 to be string, array given in /afs/ir.stanford.edu/group/knowledgebase/cgi-bin/wp-includes/formatting.php on line 631
The class assembles in the auditorium section of the d.school. Rows of chairs, some orange, some white, contribute to the room’s random orderliness. Red rolling leather sofas accommodate any overflow. Jim Patell gives a lecture that is part motivational speech, part guideline of what to expect.
He begins by mentioning a Fortune magazine article that has just been published. It’s about the Entrepreneurial Design for Extreme Affordability course and highlights d.light, a company that found its beginnings in the precursor to this class. Patell is proud of this success story, a company that manufactures affordable rechargeable LED lamps that eliminate the need for kerosene, but he emphasizes some projects might not get the publicity of d.light, although they still should be considered successful.
“Products can be brought to market faster through our partners than starting a new organization,” Patell says, referring to the organizations that teams have paired with. Many students will have no further involvement with their product or service once the class terminates in early June, while some continue in hopes of starting a business. Regardless, efforts of all teams are instrumental. The point settles in with the class that everybody’s product or service, even if not taken to market, has an effect on the entire class, since information and progress reports are openly shared.
Furthermore, this is the week in which one of the most creative leaps in the design process—developing a Point of View—begins to take shape. Throughout the first quarter the teams have honed their understanding and observation techniques. The culminating event, the trip to meet with customers thousands of miles away, put those skills to use. Now, it’s a question of where and how to direct all of the gathered information.
The Point of View tells a compelling story in a single sentence, matching a user to his or her need. It acts much like a thesis statement does in supporting an argument and will guide the teams for the rest of the quarter in developing a specific product or service. Example: An Ethiopian subsistence farmer [the user] struggling to save for his children’s future needs a way to remove whole corn kernels from the cob in an ergonomic process [the need] that would lead to more profitable selling, planting, and storing. Once the team has crystallized its Point of View, it can move forward with a more clearly defined mission.
“How do you get creative accidents to happen on schedule?” Patell asks the class. Through trial and error. The reason to build a prototype is to examine the features a team is most unsure about, to reduce risk for what will become the final product.
The most important dynamic is to operate as a group—to have members work independently on different aspects of a project (parallel processing), but to come together and make major decisions as one.
This is where the management aspect of the course comes into play, where teams should view their project schedule as a planning tool and social contract. He even suggests scheduling time to make group decisions. This will prevent any one team member from carrying too much of the load. “Setting yourself on fire to illuminate others only works once,” Patell stresses. He refers to former conflagrant relations within a startup company that grew from a previous class. Tensions ignited because the three founders all thought they were the decision maker. Some, he says regretfully, are no longer speaking.
For the duration of the week the teams will be working on the Point of View for their team and will present that to the entire class the following week.
Also on Stanford Knowledgebase:
