Last night I attended a panel discussion on Smart Medical Devices, put on by the Biomedical Engineering Society.  There was a lot of discussion about the definition of Smart Devices, new technologies (which were very impressive), and ultimately the discussion found its way to pointing out the need for biomedical engineers to act as translators between the engineering and medical communities.

Sound familiar?  This is exactly the type of discussion that goes on in design thinking circles. Just as it's important for designers to understand human needs to design better products, the same is true for designers and engineers who need to understand clinical needs to develop better products and to guide technology development.  What I truly appreciated was the engineers' description of translation.  This is much less confusing than the thought process of a specific discipline.

This should not be surprising. What struck me, however, was the fact that this capability was discussed as something that was necessary, but the problem was in finding engineers who were interested in spending time in the field.  It was suggested that typical engineers would rather develop cool new technologies, and weren't as interested in solving problems in a low-tech way.

In my work, I have never encountered a designer, engineer, or marketing person who was unhappy that I was able to identify the problem that needed to be solved, and present it as criteria that was relevant to them.  However, I have often found that most designers, engineers, and marketing people who work in development processes are much more interested in solving problems than in identifying them.  My main takeaway from this event is that there is a burgeoning frustration with people trying to solve their way to problem identification.  It just doesn't work. 

As I've discussed in many previous posts, problem-solving and problem-posing are very different activities and require different skills.  It's unrealistic to expect a doctor to define the engineering challenge, just as it is to expect the consumer to define your new product breakthrough.  Problem-posers have developed the skill to discern the motivation behind what is said, regardless of what market you are in.  Last night's discussion was yet another highlight of the same issue.

Of course your company isn't running a casino on purpose. But is it running one accidentally? You can tell based on its approach to innovation investment.

Does your company solicit new ideas for products and technologies in a more random fashion, investing in those that either can be executed with current resources, or do not pose much risk to the status quo?  Do people know the success criteria for a breakthrough idea?  In other words, is there a way to tell if a new offering with no current benchmarks is likely to succeed?  Usually the answer is no.

Does this sound familiar?  If it does, then your company probably casts a wide net in terms of investing in innovation.  Since most ideas are likely to fail, it's better to invest in more, and more varied, options to hedge your bets.  Notice I said bets, because that's exactly what the organization is doing.  The innovation process is essentially providing a mechanism to place bets knowing that most will lose, and hoping that the one(s) that succeed will cover the losses.  Isn't that what happens in a casino?  It provides a place for people to come and place many bets, hoping that a few wins will cover the losses.

On the other hand, does your company understand its market, define new opportunities to better meet the market's needs, and develop technologies that enable new products and services to satisfy those opportunities?  This may not be nearly as sexy an option at first glance, however it does provide a way to tell if radical new ideas have a chance of succeeding before investin in their development.  The chance of failure in developing something truly new and different is greatly mitigated. This is the difference between investing and betting.

In a real casino, the house always wins when most bets are lost.  In a real company, the only way the house always wins is to ensure success.  So why are most companies pursuing the casino model?

It's funny how the planets sometimes align around a topic.  This week it's the chicken and the egg question regarding technology and consumer research. 

It all started last week when I was talking with a friend from a local technology start-up about the need to understand consumer (or other end-user in B2B situations) motivations in order to ensure the relevance of new product offerings.  Then today I saw two interesting posts that essentially dance around the same question; when developing breakthrough innovation, which comes first?  The first post is from Don Norman, and suggests that historically breakthrough innovations begin with technology, and that what he's calling design research to uncover unmet needs is only useful in developing incremental improvements.  The second post is from Roy Luebke and is a response to Norman's post, suggesting that design (observational) research can point to all types of innovations.

What was interesting was that I was able to agree and disagree with both of them, based on a) how narrowly or broadly consumer research is defined, and b) the expectations for what either research or technology will deliver.  Let's look at both.

First, Norman describes the tasks of design research, and points to the fact that pure technological invention was what drove the creation of many inventions from the airplane to text messaging.  And I would say that taken literally, he is correct.  If you've been reading this blog for a while, you know that I view contextual research as a source of information, not answers.  (I use the term contextual research because it does not focus the outcomes too narrowly.) And consumers could never be expected to come up with such breakthrough inventions as the ones he describes.  When viewing contextual research as a source for answers, the most you can expect is a good list of improvements to existing products.

Second, Norman then points out that it is technological invention that is the source of breakthrough innovation.  Again, he is right in that the inventions he described would not be possible without new technology.  However, they would not be successful if they didn't satisfy a consumer motivation.  In reality, consumers rarely change their behavior to accomodate technology.  They adopt when the technology is put into a form that seamlessly fits into their lives.  All of the inventions on Norman's list enable consumers to do something they already wanted to do (travel, communicate, etc), but in a better, faster, less expensive, etc way. Knowing the motivation ahead of time can save a lot of time and money, as well as help a company to define what business they are really in.

In that sense, Norman's post appears to be based on the idea that the consumer will give you the answer, and that after the technology is developed product success is hit or miss.  I would have to disagree with both of those assumptions.

On the other hand, Luebke acknowledges that learning from consumers can point to many different types of innovation.  That is true, but he doesn't comment on the fact that contextual research should be tailored to collecting the information that will inform the decision that needs to be made.  For example, a consumer can be asked directly to evaluate current product features.  Understanding their motivations, however, is what is necessary to guide the development of new products and services they would never think to ask for.  This is the type of constraint inventors typically love to solve with new technology.  This is how learning from consumers can drive technology development - it provides a purpose, not a directive.  This is where research and invention come together.

Ultimately it doesn't matter whether we are starting with a technology or a market segment.  Technology can certainly enable the creation of totally new products and services.  But these new products and services will not succeed unless they satisfy the market's motivations better than existing alternatives.

Yesterday I was referred to a blog post written by Danah Boyd, an academic researcher at Microsoft and Harvard.  Her work focuses on the impacts of the internet and social networks on society.  She wrote about a horrible experience she had while presenting at the Web2.0 Expo.  The post is long but worth reading.  While Danah did take responsibililty for content or delivery problems with the talk, there were several lessons to be learned by those of us whose job it is to create thoughtful, intentional experiences.

First, Danah mentioned minor issues such as the fact that she was not allowed to have a laptop from with to present.  She then went on to describe that the podium she had to use was flat, which enabled the audience to see that she might be reading from notes.  This was exacerbated by the fact that the lights were so bright, she could not see anyone in the audience, making it hard to connect and establish a rapport with them.  And the final kicker, there was a running twitter stream that was displayed behind her, so that she could not see it, but the audience could.

What this created was an open invitation for the audience to carry on a conversation about the talk as it was happening. Not only was it distracting from the talk, it was happening literally behind the speaker's back.  This behavior is rude enough to begin with, and sadly, this audience devolved to the point of making rude comments and juvenile wisecracks.  It was like a bratty kid looking for attention in public.

New technology allows us to do many things we couldn't do before.  But the freedom to do these things comes with the responsibility to use the tools wisely.  I'm sure someone thought it was 'cool' to display a live twitter feed about the talk.  If handled responsibly and with a little more forethought, it could have served to engage the audience and allow Danah to better connect with them by seeing where their interests and energy were going.  Critical thought, active listening, and discussions that challenge existing ideas respectfully all help us to move further faster.  New technology can facilitate that type of interaction better than ever before.  However, when something like this happens people tend to shy away from the technology itself, which could actually set us all back.  It would be much better to stop and think about the experiences we want to create, and question whether what we are doing will actually help us to deliver them.

As you develop products and services at your company, how much thought is given to the actual experience a consumer will have when trying to learn about, purchase, and use your offering?  When developing a new technology, or launching a new product, are there unintended consequences that could result in the actual experience of use?  Obvoiusly there are no right answers to these questions, but it is important that someone is asking them.  Are they being asked at your company?

We've talked about the difference between the innovation process and the development process in terms of the results they are expected to achieve; the innovation process being used to identify market relevant opportunities for innovation, and the development process being used to efficiently and reliably get offerings into the market.  We've also talked about how different people, and different thought processes lend themselves to achieving these goals. 

What we haven't talked about is how the different processes should enable people to best do their work.  This is where we often see culture clashes in companies who try to standardize performance objectives based on discipline when they should be targeted to the overall objectives they are tasked with achieving.  Let's see how this plays out by examining some common process elements and seeing how they differ between the innovation and development processes.

The complexity of the development process can best be defined by the sheer number of tasks, functions, and people that must be managed.  It is often a project manager's sole job to coordinate and keep track of everything that must happen.  This person also communicates the interrelations between the tasks required of different functions so that the team can proceed toward the goal.  For this reason, quality of work is evaluated based on whether or not the team members complete their required tasks efficiently and according to schedule.  There are well defined parameters for the completion of tasks to hit project milestones.  In fact, every task is planned and scheduled before the project starts, and the project operates under the assumption that when all tasks are completed, the project is done.  As can be expected, the planning process is very involved, but this typically happens once, when the process is being initially determined.  After that, most projects are similar to the first and can follow predictably along the same steps. So, it can be said that the purpose of the development process is to ensure that human error can be engineered out of the system.

The complexity of the innovation process can best be defined by the fact that the team typically has no idea what the tasks should be at the beginning of the project.  This team is guided by an overarching goal, and needs to be flexible and creative enough to do whatever tasks are necessary to collect the information that will help to achieve it.  The fact that a set of tasks worked on the last project may be useful knowledge, but it is certainly not a roadmap for the next project which will have a different overarching goal.  For this reason it is difficult, if not impossible, to map a process step-by-step for a person outside the work process to plan, manage, and communicate.  Quality of work is evaluated on whether or not each person is able to construct logic and create solid rationale leading to recommendations, making sure to voice any logic breaches that come up so that the team can step back and address them.  Milestones are certainly helpful, but they are more useful for the team to structure their thinking, and less useful to determine tasks.  At the end of the day, it can be said that the purpose of the innovation processes is to ensure that intuitive leaps are made transparent, able to be evaluated, and that recommendations can be presented in such a way that the rest of the organization can make use of them.

Think about how your company's development and innovation processes.  Are they different?  Do they try to achieve different goals while using a similar process?

Most organizations have mastered the ability to deliver their products and services reliably and efficiently.  Remember the 99% lists?  As consumers we've come to expect excellence, and companies that don't deliver above and beyond this excellence won't last very long.

Organizations themselves also take these skills for granted.  I'm often reminded of this when I'm working with clients to develop innovation processes.  Many of the people within companies become frustrated that the organization's capacity for change is so low. 

At this point, it's helpful to step back and really think about what your development and manufacturing processes are expected to do.  If you work in a business where 99.9% isn't good enough (most organizations), then expecting the current process to accomodate breakthrough innovation is just not realistic.  Alternatively, expecting that the outcome of the innovation process will be products and services that fit neatly into existing systems is equally unrealistic.  Innovation efforts that implicitly carry either of these expectations will most certainly fail.

Innovation processes require room for experimentation, trial and error, incorporating unpredictable human elements, and all the other things that would bring current development and manufacturing processes to a screeching halt.  It's far better to separate each process, and let each one be what it needs to be.  Your innovation process should result in the identification of new opportunities that can be delivered in multiple ways.  Some may be able to work with slight modifications to existing processes.  Others may require completely new processes. 

Your innovation process should deliver market relevant opportunities.  Your development and manufacturing processes should deliver offerings to the market reliably and efficiently.  The real organizational challenge is managing expectations within the organization for what each process should deliver, and establishing the right connections between them (more on how to do that later).  But don't expect one to deliver on the expectations of the other.

Most consumer research focuses on learning about what people do, and most innovation projects focus on developing new technologies into things people will buy. Notice the disconnect?

Too little research is focused on how people make decisions, and too few innovation projects focus on developing something that fits better with people's decision processes.

Learning to do this type of research is difficult.  Learning to connect this research to the development process is even more difficult - and rare.  No one would argue that it is important to learn about how consumers make decisions, nor would they argue with the importance of connecting this knowledge to the development process is important.  In fact, many would say they are already doing it.

I have not seen a product or service fail when this is done well, and yet according to Stevens and Burley, at least 1 of 3 products fail  at launch despite research and planning.  Clearly, we can see that doing these activities does not mean we are succeeding at connecting them.

My last post was about the success of Monocle, and how founder Tyler Brule's incessant, immersive research plays a large role in this success.  But it's not the only reason Monocle is successful.  JD asked the question, "Is Brule able to do this because he is part of his target market, and he is providing products and services that he, himself, would want?"  This is a great question, and my answer is that while this may very well be true, it's not enough.  If it were, he could just sit behind his desk all day and dictate what he likes rather than spend time in the market.

Immersive research to get to the heart of what drives the consumer's decision-making process is half the battle.  The other half is the ability to translate what we learn about the market into products and services that actually connect with these drivers.  In my experience, this is where most companies fall down.  The inability to translate these intangible needs into tangible products actually encourages superficial research.  It's easy to make a direct link from what a consumer says they want, to delivering on what was described.  This is great for incremental improvements, but consumers cannot tell you how to disrupt a market.  Tom Martin said it well today in AdAge, "The customer is paying you to solve his problems before he even realizes he has them."

The translation from consumer understanding to the creation of the right products and services is the other area where Brule's team seems to be executing flawlessly.  The fact that he is part of his target market may help him, but being part of his market does not automatically give him the ability to translate.  We are all members of various target markets and may work for companies that make products for people like us, but the vast majority of us do not have this ability.  So, Brule is good at translating in this market.  For him it doesn't matter whether or not he's good at translation in general.  For other companies, this matters a lot.

The ability to translate is equally important for all functions in an organization, yet it is a skill that is difficult to recognize.  Traditional market research techniques often fail to uncover the depth of insight that will guide the development of disruptive products and services, and traditional evaluation techniques often fail to discern whether or not a disruptive idea will connect well enough to succeed.  Brule clearly does this well, and I don't even need to say more than the words "Apple vs Dell" to further illustrate the point.

I fully believe that you do not need to be in a target market to derive the right insights and translate them into the right disruptive products and services. Right now we're seeing success with CEO's who are good translators, but the CEO doesn't have to be the translator.  Is your company recognizing and supporting this role?

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?

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?