Alternate Title: Microsoft Embraces New Work Spaces Reminicent of the Purple Sofa Era

Both titles bear a bit of explanation. Marketing has 4 P's used as a model for strategy: Product, Price, Promotion, Place. In the process of uncovering the details of events going on within one group at Microsoft, I realized that they'd effectively identified 5 P's for Design & Development. These are shared in the context of this piece.

As to the Purple Sofa Era, those of us who lived it, immediately identify with it. In the late '90s, nearly every dot.flop interactive agency (and even some internal corporate eBusiness groups) created more dynamic, creative physical work spaces to support the different work they were intending to generate, and to attract highly-creative resources.

These environments seemed to have common elements: purple sofas, Herman Miller furniture (especially Aeron chairs), writeable walls, and foosball tables. What is disheartening is that what follows in this piece was clearly suggested, with research (The People Are the Company), in 1995. So we're a little slow on the uptake.

There are two supporting media pieces: the short version (a 15 minute tour of Microsoft's Patterns & Practices Lab) and the long version (a 49 minute interview describing the evolution of the group and their workspace).

Notes and Observations...

The Microsoft Patterns & Practices group insists that their focus is to help customers build better solutions with less effort. They evolved out of the Agile development approach and decided that their workspaces did not meet the needs of the work they needed and wanted to do. Given that they started, as many intensive workgroups do, in a hijaacked conference room (a 'war' room in many companies), their new spaces reflect this close quarter, communal interaction -- complete with glass 'whiteboard' wall panels which can be moved and reconfigured as needed. They suggest that it's a natural way of working. The details of the space itself is best experienced via the tour.

With a specific focus on the experience design of application developers, their group finds ways to directly interface with representative customers. They have people on their team whose job it is to find these people, to talk with them, and in some cases to bring them in to the "Customer Room" -- where the team comes to directly interact with customers. As they talked through their approach to design the 5 P's came through.

Pain: What are their challenges? What do they have to deal with repeatedly?
Possibilities: What can be easilty changed or influenced?
Patterns: These emerge both out of the pain and the possiblities.
Parts: These are the explicit representations of patterns.
Practices: These are the means and the methods to facilitate the other P's.

They attribute the success of their approach two things: 1) People want to tell you how to help them and 2) Their development approach embraces delivery within tight feedback loops and the approach is extended to a community of practitioners who participate in the building of solutions. The latter can only happen when companies can likewise drop their concerns for intellectual property: "We share as much as we can...because then we can see where people take the thing." [So effectively, by observing behaviors, design is informed...hmmm, novel (sorry for the pointed sarcasm).]

Their documentation is written as a story: "They wanted to know why we made the decisions we made and how we made the decisions." This supports one of my axioms of relevant design -- one that I drop on vendors all the time: If this is the answer, what was the question?

There's no such thing as correct...that's why we don't say best practices, we say proven practices.

They understand the significant of context: a practice that works in one context might not work in another context.

They also extend their charter to helping the other product groups improve their results (that would be good news for the rest of us).

Their teams are structured cross-functionally: developers, testers, architects, a project manager and a product manager all work together in the same space. There are project spaces and offices, but even the offices are often recombined to house a 'set' of pracitioners (e.g. the architects). The inclusion of a product manager should not be lightly taken, or dismissed because of the nature of Microsoft's business. I firmly believe that the IT industry as a whole has underachieved its potential for not recognizing that everything they put out is a product (or service) and as such needs the focus and related activities which a product manager would bring to a project that is different from a project manager. Had that been the case, experience design would have evolved much more rapidly than it has.

Their approach testifies to a critical 'blue message' (a message we repeat so much our faces turn blue): there is no such thing as phases (as in classic development methods -- esp. requirements, design, etc.) -- its' all continuous. Classic application development is dead -- or is something that will only be practiced by companies who are intent on dying.

What really made this [work] for us is the team of people who love to work together and love to solve customer problems...the facility makes it that much easier.

Ah...solving customer problems circles us back to Design Thinking...it's all one great whole.

[The group hug at the end is classic. My thanks to all three of the unique personalities: Rory, Peter and Edward.]