It's hard to find a company that does not embrace multidisciplinary project teams these days. The idea is that since we all have our functional blindspots, a team that brings disparate disciplines together will have all the potential blindspots and pitfalls covered.  While there may be more team disagreements, they will happen earlier in the process, resulting in less rework and greater efficiency overall.

Then why is it that some multidisciplinary teams fail, while others appear to work magic? What I've experienced myself and in working with client teams is that in an effort to ensure diversity of functional discipline on a team, organizations fail to acknowledge that there are some attributes that a team must share in order to accomplish their goals.  These attributes are not based on functional discipline, but are based on how people think, work, and interact.  Does a person do well with ambiguous problems, or do they prefer concrete goals and information?  And what type of thinking will best suit the needs of the project?  Let's take an example. For simplicity, we'll just discuss the engineering and marketing disciplines.

Project A:  The goal of this project is to launch an upgrade to an existing product. The current product does well in the market, yet it has been acknowledged that some improvements could be made. 

A good marketing person for this project will know the current market well.  They will be comfortable dealing with quantitative data about exactly what features need to be improved. They will also know price sensitivity of the consumers, how current competition will likely react, how an improvement will enhance distribution and retail relationships, what the advertising message should focus on, etc.

A good engineer for this project will know the current technology and processes well.  They will know how to tweak current processes, and how to modify desired features to be made on existing production lines, with minimal upgrades.  They may even have figured out a way to offer an improved product while cutting current costs.  They will know what can be done to hit the launch deadline, and have a plan to continue upgrades in future launches. There will be clear boundaries between their work and the marketing person's work.

Project B:  The goal of this project is to come up with an industry breakthrough that will ensure the company's market leadership in the next five years. It needs to reinforce the company's brand image with consumers, yet make current product competition irrelevant.

A good marketing person for this project will understand why the current market is what it is. They will know what fundamental needs their products satisfy for consumers, and they will want to understand what other product categories also satisfy these needs.  They will shun current industry assumptions about how the market should work, and they will think in terms of new business models, and how to change the current competitive environment. They will focus not on defining product solutions, but on clearly defining the success of a new offering.

A good engineer for this project will understand the needs that different technologies can satisfy.  They will love manipulating technologies to satisfy new needs.  They will not want to be asked to figure out how to make a specific product, but will want to be asked to devise a way to satisfy criteria that is based on both consumer and business needs. They will not want a spec sheet, but they will want to understand the needs first-hand.  The boundaries of their work will often be blurred, blending with the marketing person's work.

Most companies do not define the intended scope of a project as clearly as I have defined here.  Since they typically lack the tools or vocabulary to define the skills required to function well within different project scopes, team members may come to the table with goals that may be at cross purposes.  Imagine the marketing person in project A, being asked to achieve the goals of project B?  Or vice versa?  As they used to say about the old sit-com plots - We can be sure that mayhem will ensue!

The next time you are on a multidisciplinary team at your company, think about the scope of the project you are working on.  Has it been defined? Is everyone on the team suited to working in the way that is needed for that scope?  What have your experiences been?  I'd love to hear how others have tackled these issues.

There's a multimedia presentation in the online Harvard Business Review about how to get a better understanding of what customers may truly want. 

I think this research method is a small step in the right direction.  It shows how most quantitative evaluations that ask consumer to rate the importance of different features can lead to average ratings of each feature against the others.  The new method they propose forces trade-offs of one feature over others in a variety of groupings.  This results in a better understanding of what the consumer truly would prefer.

While this method is an improvement, I can't help feeling a bit uncomfortable with the process of having consumers choose discrete features from a list that was created based on aggregated focus group input.  What's uncomfortable is that a consumer's ultimate opinion is the result of how they perceive experiences holistically. In the presentation the example was from a restaurant chain.  The features were things like "food served hot and on time", or "updated decor".  What this does is force consumers to decide which single attributes are most responsible for creating the experience they would like to have. 

Asking consumers to do this is unfair. They are not restaurant space designers, and they are not chefs. It takes a lot of work to understand what experience the consumer would like to have, and then even more work to figure out how to combine the design and food elements to holistically deliver this experience.  It also leaves designers and chefs with ambiguous instructions for how to proceed.  Should the chefs deliver hot hamburgers quickly while the designers put white linen on the tables? Yes, this is an extreme, but we've all seen it happen.

Next time you're evaluating features in your next product, think about what you're really asking consumers to do.  Are you evaluating products holistically, or are you shirking your responsibility and asking consumers to translate features to experiences for you?

There's an article in Fast Company about Google's design lead, Doug Bowman, leaving the company to take a job at Twitter.  He says that Google's culture of over-reliance on testing and data paralyzes the design function.

This is yet another sad ending to an all too common issue.  Businesses that have to place big bets are typically reluctant to do anything that has not been evaluated to mitigate unnecessary risks.  Exercising this type of caution is good, and I am an advocate of evaluating ideas before they are implemented.

Where it goes wrong is when the evaluation methods used are inconsistent with the types of decisions that need to be made.  While I don't know the inside details, I would suspect that this is largely the issue for Bowman, as it is for most designers who work with large corporations.  In most business disciplines, very linear methods of evaluation can be used to make decisions such as the return on investment of new capital equipment, the potential market effects of price changes, or the usability of web products.

However, it is a designer's job to create new experiences, manage consumer's perceptions, and ensure that products and services are meeting underlying consumer needs.  Design elements are used holistically to acheive these goals, and testing individual attributes (such as Bowman's mention that he had to test a 3,4, and 5 pixel border) can lead to inacurate design decisions.  Does that mean that design cannot be evaluated?  Not at all.  In fact, that's where many designers fall down. 

Design can be evaluated, but new methods have to be used that evaluate whether the holistic design elicits the desired response. The key is to focus on the results, not on the individual elements.  I have had great success with this type of evaluation.  The companies that struggle with this type of evaluation typically have not taken the time to figure out what the ultimate goal of the design should be.  Lacking that information, designers are left to grope in the dark, looking for something that either a consumer, or a company leader, will say they like.  This may work in the short term, but ultimately the wrong evaluation will lead to the wrong results.

How does evaluation happen at your company?  Ultimately, are products evaluated based on how well they will achieve the ultimate goals of the person who will buy them?  By ultimate goals, I mean the basic reasons the customer is buying a product in your category in the first place.  If you're scratching your head wondering what the ultimate goals are for the product you're working on, it may be time to start asking some tough questions.

I've been reviewing product development processes for different companies and have noticed something pretty interesting.  It seems that linear development processes that track tasks rather than results lead to lopsided thinking.

What do I mean by that? Well, in some companies, the development process starts with either a marketing or product management person who is in charge of "defining the product requirements."  The technical person then executes the features as defined. In this case, the product definition is presented in technical terms, leaving the marketing person responsible for translating consumer requirements into technical requirements.  This results in a lack of solid, creative thinking on the part of the technical staff on how best to achieve the consumer requirements.  It also results in a linear process that makes it easy to track tasks on a gantt chart.

In other companies the process is the same, but in the opposite direction.  The technical team develops some great new features, and then the marketing team is charged with selling them to consumers.  Consumer requirements are more about how to best position the features that have been developed.  Again, this results in a lack of solid, creative thinking on the part of the marketing staff, leaving the technical person responsible for translating technologies into something the market might want.  And again, it results in another linear process that makes it easy to track tasks on a gantt chart.

Does this mean that I think linear processes and gantt charts are bad?  Not at all.  In a broad sense, the development process is linear, and there are definitely some milestones that must be hit before moving on to the next. 

Where it goes wrong is when the linear process is used to track every task associated with achieving a milestone.  This results in different groups having to pass work from one to the next, without the ability to work together.  Working together requires that each group challenge the other, trying multiple approaches, abandoning old ideas and developing new ideas as scenarios are played out.  While the results of this process can and should be placed on a gantt chart, the tasks associated should not.

Is your organization's development process encouraging lopsided thinking?  One way to tell is to look at a development schedule for a new product.  Are you tracking tasks or results?  Are your groups working together to arrive at new solutions, or are they complaining that the previous group did not define the job well enough to proceed without thinking? 

I'm just back from two weeks away in Argentina.  Fabulous place, and we had a great time.  The only issue was that one of our bags was stolen.  Augghhhh...  Now off to deal with insurance companies to replace the stuff that was taken.  Argentina is great, but certainly has a PR problem with these types of issues.

Soon to be back with more on consumer insight!