... ...

This weekend, my husband and I decided to finally replace our very old washer and dryer.  After doing all the requisite research, shopping, reading reviews, etc, we decided that we should get one of the new machines that use very little water.  As we were placing the order with the appliance company, we were reading some information that suggested we use a low-sudsing laundry soap.  No problem, we thought, that makes sense.

Well, the manufacturer suggested a brand of laundry soap that we don't see very often in our local grocery store, so we thought we'd just find another.  Well, after looking around, we found some that say they are HE.  Looking into that a little more, we learned that HE is for High Efficiency machines.  This is probably what we need to use, but I found it odd that nowhere on the HE package did it indicate that this was a low sudsing detergent.  This got me a little miffed.  After reading all the information, I concluded that we are probably making the right choice, but why couldn't the detergent manufacturer and the machine manufacturer simply use the same terms?  Why is it that the consumer is left with the job of doing the math and making the connection? 

I'm sure that both companies were trying to do what they felt was easiest for the consumer.  The machine manufacturer is trying to describe the detergent (low sudsing), and the detergent manufacturer is trying to describe the machine (high efficiency).  What is easiest for the consumer, however, is consistency.  The consumer needs for these companies to talk to each other, to create a consistent consumer experience.  They should support each other, and not behave as they would toward a competitor.

Think about your company.  How often do you encourage others to look beyond their immediate sphere of influence to think holistically about the consumer experience?  What people, groups, or companies should you be working with that do not live inside your company, yet are trying to improve your consumers' experience?


In my opinion, one behavior with perhaps the greatest potential to kill to innovation is the aversion to using the phrase "I don't know." 

Let's say you are leading a new project to develop a completely new offering for your company, the outcome is highly uncertain, and someone asks you a question like what you think the selling price of the new offering should be.  Of course you want to give an answer that sounds like you are in control of the process; that you are capable, and confident, and you know what you are doing.  But let's face it.  If you are doing something truly new, you shouldn't have any idea of what the final selling price should be. At least not at the beginning stage of the process designed to figure out what type of offering you should be developing in the first place. 

Would you be empowered at your company to say "I don't know what the selling price should be?", and would you be empowered to follow up that answer with "and at this point in this type of project we shouldn't know the answer to that question?"  If you gave that type of answer, would you be removed as the project leader because you "don't know what you are doing?"  And if you gave an answer that would assure everyone of a certain outcome, would you be sabotaging your ability to truly innovate?

As discussed in an earlier post, companies reward certainty.  Unfortunately, this reward is often employed at every stage of every process.  Would I ever advocate launching a new offering without thoroughly evaluating what the correct price will be?  Absolutely not.  And of course, "I don't know", may really mean that the person doesn't know what they are doing.  What I am advocating is that we consider the context of the rewards we employ.  Rewards should be consistent with the type and scope of the work we are doing.  We should be clear about the expected outcomes of a project, and what types of decisions should be able to be made at each step. 

There is a time and place for every question. If we're not careful, the "right" answer will be given at the wrong time.  At that point, it may as well be the wrong answer.

 


I've had a few discussions about my previous posts on the translation of consumer insight to guide the development of viable offerings.  Since then, a few people have asked me how exactly to translate what is learned into a better product specification, and who should be responsible for writing that specification.

What I have found to be most helpful is to see this in two steps.  The first step is to learn from consumers, and then create a story about their lives and the aspects of their lives that we can improve.  Storytelling is very useful because everyone in the organization can understand a story about a person's life.  They can also clearly see how that person's life could be better under a new set of conditions.  We then have a shared vision of what we are trying to acheive.

Ideally, after grasping the story, different groups begin to envision ways in which they can contribute to the new set of conditions.  For example, the engineer may say "Oh, I can solve that with existing technology and we don't have to invent anything new."  Or a marketing person may think of new ways to become more relevant to the consumer. 

Responsibility for writing the specification is shared and iterative.  The person leading the consumer insight work is responsible for making sure that the story accurately conveys the motivation behind the consumers' behavior.  This person is also responsible for making sure that everyone on the team understands the story.  The people who need to execute the new solution can then write a specification that is meaningful to them.  It is their responsibility to ensure that everyone understands the implications of the intended solution.  In this way, the entire team can understand how each group's solution contributes to the consumer story.  And each group has a meaningful specification.

The next time you hear specification discussions that sound something like "I'm waiting for the product manager to give me the spec", "I did what the spec said", or "Let's build it this way because we did it before and we know how to do it", think about whether the missing ingredient might actually be the consumer story.  I guarantee that when you have a good consumer story, it will drive more interesting, engaging, and productive discussions, and your company will be a better innovator because of it.


A few weeks ago, I reponded to a post on Jeff Jarvis' blog, asking his readers to help with the title of his upcoming book, "WWGD: What Would Google Do?"  Apparently Jeff's publisher wanted him to ditch the WWGD part of the title, suggesting that it was redundant when combined with the rest of the title.  Jeff felt that without the initials, the joke (a play on WWJD - What Would Jesus Do?) would be lost.

The readers commented with various reasons why Jeff should either listen to his publisher, or stick to his guns, with Jeff jumping in periodically.  After about 75 comments that went on this way I had to jump in.  Here's an excerpt from my post:

This is a great exchange, but to me it doesn’t matter what we all think. You should decide based on What Google Would Do, since that is the point of your book (as I understand it).

I went on to discuss how the joke may not naturally play out the same way twice, and how he's trying to control a viral message.  Would Google try to maintain such control?  Here's Jeff's response:

ellen,
Well, there’s the best advice of all. what would google do if they created someting this? what would be googley? simplicity, I suppose.

I'm not sure where Jeff will end up with his book title, but I am sure that he will think about the issue differently.  What's interesting to me is that 75 people obediently responded to a question that forced a choice between two options, both of which may not be the right answer.

The next time you find yourself facing a similar choice, and the options seem to be based on one opinion versus another, ask yourself whether you are trying to answer the right question in the first place.  And then ask yourself what your customer would want, because the answer to that question is where you will most likely find the highest value solution.

Based on the questions in Jeff's response, he's not sure yet what the answer is, but he is seeking an answer to the right question.


Overlap 08 was an enriching experience.  It will take a few days for it all to sink in I'm sure.  Right now, my strongest feeling is that of appreciation and gratitude toward the people who started, and continue to organize this event.  It has been the only venue in which I feel professionally at home, and I came away once again feeling much less alone as I strive to connect diverse people and disciplines with my clients.  Reconnecting with people, meeting new people, and coming away with new ideas truly resets my momentum.

For all of you that come to this blog, I am looking forward to continued dialog about the ideas I am exploring.  I love pushing, pulling, and honing ideas with smart people who are open to new things.  I was surrounded by that in spades this weekend, and will make a conscious effort to expose myself to your thinking continuously throughout the year.

 


In many organizations, risk and uncertainty are synonymous concepts.  This is not true.  They are, in fact, very different.

 

Risk is determined by how detrimental the impact of a failed project or initiative will be to the company.  Will the company go out of business if your program fails?  If so, then this is a high-risk project.  Will anyone notice at all?  If not, then this is a low-risk program.

 

Uncertainty is the extent to which you know the outcome of a project or initiative before you start it.  Do you know which product offerings will come out of an innovation initiative that will begin with broad understanding of consumer values?  Probably not.  This is highly uncertain.  Will a misstep in this project kill the company?  Maybe or maybe not.  The level of risk is independent from the level of uncertainty.

 

Most organizations consider uncertainty to be scary.  They then define it as risky.  This fear traps them into only taking on projects where the outcome is certain.  The results can be projected and quantified before the project is started, and everyone "buys in" to the projected result. This is not scary, and as such, it is not considered risky by the organization.

 

Let's just say that you are in a highly compeititive industry.  You operate in with a high degree of certainty because a misstep is considered risky.  And let's just say that this highly certain manner of selecting projects causes you not to invest in any project with uncertain outcomes.  And let's just say that your competitor just launched a new offering that will change the face of your industry.  You may go out of business if you cannot respond quickly.  Again this is highly certain.  But is it risky?

Think about how you determine risk and uncertainty at your company.  


There are two types of consultants, Trusted Advisors and Trustworthy Partners.

 

Trusted advisors focus on a client's business goals.  They provide an objective perspective and structured thinking that helps clients to think through the right course of action to grow their businesses.  Recommendations offer the best course of action with analysis and scenarios with likely consequences. They share responsibilty with the client for the usefulness of their work to the organization. 

 

Trustworthy partners work with clients to fill skill gaps in the organization.  They are experts in their field, and clients rely on them to provide the best solution within the constraints and goals that have been determined.  Recommendations offer the best solution among a set of considered options, and they share responsibility with the client for making sure that the organization can utilize the recommended solution.

 

While the scope of the roles is different, both types of consultant have one thing in common.  They share in the responsibility for their clients’ success. If you are a consultant, be prepared for the level of responsibility you are willing to take for for the client to be able to utilize your work.  Clients use consultants because they do not have the perspective or skills that the consultant brings to the table.  Clients cannot tell the consultant what to do or what needs to be done; if they could, they wouldn't need to hire the consultant in the first place.

 

If you are a consultant, think about how often you find yourself (or your people) complaining that "the client doesn't know what he wants us to do", or "we'll write the proposal when the client figures out what they are doing".  If you're not prepared to help your client to think these issues through, then you may be a monkey in consultants' clothes.


Seth Godin had an interesting post about how people cling to old ways of doing business, and approach fast-growing new ways with trepidation.  He uses the newspaper industry as an example.  People are clinging to the old business model, while online venues are showing much more promise.  The most interesting point he makes is that the people who are best suited to developing the new model are often the skilled hands that created the old model.  Yet they are the ones who are leaving this task up to those who are less experienced.

How often is this happening to you, every day?  It's easy to point to such glaring examples as the newspaper industry or the airline industry, and from the outside it's easy to point to several things that are going wrong.  But these companies are run by smart people, so I can only think that this tendency of human nature must be so strong that it is surely affecting all of us every day.  We don't see it because we don't perceive that it is affecting us measurably.

Find ways to see your blind spots.  Ask friends, coworkers, and anyone who's opinion you respect.  Remember, it will be easy for the outsider to see things that you do not even know exist.


... ...
... ...

Recent Comments

Comment RSS

Month List

License

Creative Commons License
Please contact me for permissions beyond the scope of this license.
Sign in
... ...