How a d. School Course is Different

I  recently wrote a
post aimed at Stanford students that announced the courses that we are
going to be teaching next term. One of
the classes that I am teaching next term — with Debra Dunn and Kris Woyzbun –
– is called Business Practice Innovation, where the focus is on treating
organizational practices as prototypes. This is part of a series of classes that a group of us are developing where
we try to bring design thinking to business problems. I got a note from a Stanford MBA about the
class, and I thought it would be interesting to share both the question and the
(lightly edited) answer. These d School
classes are so different than most other university classes (at least that I
know of), that I am constantly giving long explanations that sound something
like what you see below. This one is a
bit more detailed than usual, so I thought it might be interesting to anyone
who is interested in how we are teaching innovation. Plus it will give me
something to show to other Stanford students that ask similar questions.

The
question was:

Dear Professor Sutton,

Would it be possible to receive additional information regarding
this course? Specifically, I would like
to better understand what you mean by "changing business practices?" Is this
coming up with a change to the business model / company strategy / new
businesses or products? Additionally, who is going to implement the changes:
the student teams / the company employees with the student teams? I guess what
I am asking is: is this a management consulting type project? What are the
aspects of design in the course?

I
answered:

Thanks
for writing. I wouldn’€™t exactly call it a management consulting class. I guess some of what we will do in class is
sort of like consulting, but the hallmark of this class —  and others in the
design and business initiative — €“ is using design thinking to tackle business problems (not just to advise others, to get in there and do it).
This means developing a point of view about the problem, observing people in
context, developing some potential solutions, picking one or two prototype
solutions that seem most promising, implementing them, and in the basis of what
happens, keeping the solutions, revising them, or discarding them, and
iterating on and on.

Clearly,
in a 10 week class, we can’t do something like, say, a merger or change an
organization’€™s manufacturing strategy. Instead, in this class, you would work
in a small team (two or three students) directly with people in companies to
develop and then implement prototype solutions. So, let’s take one project we
might do (listen to the might, these are not clean and pretty and organized
classes like most business classes. We have real companies and things come up.
Sometimes we are set to go, and then it falls through. But we have firm
commitments from two organizations, and are "€œin talks" with two others). So, let’s
consider one rapidly growing high tech company. The process of getting new
employees on board is kind of a mess (in fact, the word "mess"€ isn’€™t meant to
be negative here; they believe that their messiness is one of the keys to their
success).  But let’s say we applied the design process to improving the
first 24 hours that a new employee is on the job –€“ that is the design problem.
Teams in the class would go through stages that look something like this (all
in 2 weeks, 3 weeks tops):

1.
Develop a point of view on the first
24 hours of the new employee experience. For example, one point of view might be: "What can the employee do him or
herself that first day to make the experience better, without any additional
resources, management, or peer action." This is just one possible point
of view: peers and bosses could be involved too, but those would be different
points of view.

2.
Your team would observe —  take
notes, pictures, shadow, do interviews, and so on — two or three new employees
during their first day on the job.

3.
Your team would then brainstorm ways
that a new employee could better survive the first day. You would pick a few of
the best ideas — prototype solutions — and develop ways to implement them and communicate them to new employees.

4.
Your team would then work with the company to test your prototype solutions, say, on one to three new
employees. You would implement it very
quickly and (even on the fly) and keep refining and improving it as much as you
can given the severe time constraints that you will work under.

5.
You would then do a presentation to the class that describes your method, what
you did, and what you learned.  The presentation would not only be to the
class and teaching team, it would be to members of the company where you did
your work. People from the company would not only would give you comments, they
would also evaluate (yes, grade) your solution.

This class is a prototype itself, and we as the teaching
team will no doubt ask you to do something slightly different than above, and
change things on the fly too. But I think that my fantasy above communicates how
these classes are different than my image of a "management consulting€
class." I think of consulting as mostly
offering advice; although I guess that is part of what we do, our emphasis is
on trying to change things. There
is less talking about what the company ought to be doing, and more emphasis on
finding (often small) ways to get them to do it RIGHT NOW. And  getting our hands dirty in the messy  initial  stages of implementation.

I
hope this helps some; it is about as clear as I can be, as our process is fuzzy
and messy. Thanks again for asking, and feel free to send this to other
students.

Bob

P.S. The napkin above is the original "d.school manifesto," produced a couple years ago (after
going through a process much like that described above) by George
Kembel and Diego
Rodriguez. I think it still pretty much describes what we are trying to accomplish.