I repeatedly see people protecting "ideas' to the nth degree of paranoia. Even comments such as we don't want our own employees to see ideas of other employees because they may steal them! My answer to that sentiment is simple. Follow the conversation:

• Them: "We don't want to let our employees to ideas that other employees have submitted because they may steal them?"
• Me: "Help me understand, you are afraid an employee will take an idea that you are aware of, leave the company, start a new business from scratch, resource that business, build the solution, and penetrate the market faster than your well-established, well-funded company can?"
• Them: "Yes....err no...err wait"

PC Mag recently cited an Accenture study stating that 68% of electronic product returns worked properly! That means the main issue was that either the product was difficult to use or set up. While it is easy to blame the stupidity of consumers for not understanding how to use your product, you should really ask who is the stupid one? All too often companies get focused on building the best technology; chanting the mantras "add more features", "improve performance". In product development meetings we rarely hear the word "simplify".

Of course it is not necessarily your fault. Early on in your product's life, you had to market to the early adopters. They have a good understanding of technology and will likely get a product with the worst user interface working. They also pound the drum of new features, better performance so that they can get an edge on their competition. So it's not your fault, you were trained to think this way by your customers.

The problem is that the elusive "Early Majority" mass market across Moore's Chasm do not want new features and better performance. It is very likely you have too many features and your performance is more than good enough for them. The value proposition they are looking for is "give me an easy way to solve a pressing problem". They usually don't even want to get an edge on competitors; they just want to keep up with everyone else.

Can you see the problem here. On one side your current customers want more features, better performance that gives them an edge and on the other side your future customers want easy to solve a current problem that will help them keep up with their competitors. What is easy for these groups to demand will be a nightmare for your company to deliver without incredible discipline. At the drop of a hat, you will need to turn your product development strategy 180 degrees; moving from performance to simplicity. It requires an incredible mindset shift and often requires new employees who bring that view to the company. Crossing the Chasm is a great book to help you understand strategically (and tactically) what you need to do, but I will try to summarize some steps.

1. Pick a focused segment of the mass market with an incredibly focused painful problem.
2. Deliver the entire solution to new target market even if this requires you to partner with other companies. This also means making the solution as easy as possible for the customer.
3. Position your product in a category that the new target market understands with two competitors - a budget product and a differentiated product. These will help legitimize your solution and differentiate it as the best solution.

This is not an easy task. Most companies fall into the depths of the chasm never to be heard from again. The goal is to avoid those 68% of product returns because your product is too complicated for the customer to use. Your solution may solve their problem completely, but if they can't figure it out immediately, there attention will move elsewhere - plunging you head first into the chasm.

In January, I talked about RPV analyis in competitive intelligence model. While the technique is great in evaluating your competitor, it can also be used to help you plan for your new product development. This model is taken from Christensen and Overdorf.

Definitions

Values: The key drivers of your company tactics and strategies. Processes: What processes does your company excel at in its current business. Lightweight Team: A cross-functional team of employees. Heavyweight Team: A cross-functional team of high profile employees/leaders of the organization.

Fit Strategies

When evaluating new product development projects always compare the values and processes demanded by the project to those of your company. The fit will tell you how to structure the project. Here are the rules of thumb: Value and Process Fit: Lightweight Team/Internal Project Value Fit Only: Heavyweight Team/Internal Development, External Commercialization Process Fit Only: Heavyweight Team/Internal Project Absence of Fit: Heavyweight Team/External Project You may be able to see some themes. First, as soon as a project doesn't perfectly fit within your company's values and processes, high profile employees must champion the project to enable the project to cut through the inevitable bureaucracy that establishes itself in a company. Second, the key determination of whether a project will need to be spun outside of the companies is the process fit. A heavyweight team can help to address a poor value fit, but changing internal processes for a single project is generally not practical. That is why it requires a spin out.

As some of you may know, I am in the final quarter of my MBA program at The Merage School of Business. The Merage School has a mandate to expose students to strategic innovation - concepts, best practices, pitfalls, execution - a pretty wide view. One of their cutting edge courses is the EDGE course that focuses on how to mobilize action in today's flat, connected world. The course has plenty of high level support. John Seely Brown, former head of Xerox's research park and current board member of companies like Amazon.com, is a big supporter who is involved in setting the class syllabus and attends most classes. JSB started off the class setting the tone of the type of world we are living in. A world where there is no status quo; a world in constant change. The problem is that conventional business school teaches how to establish processes. Processes require stability to function at a high level and exposes them to the competency trap. The competency trap is a play on the experience curve which is depicted in the blue line on the graph below. The experience curve is a traditional S-curve that shows how people generally learn. We start gaining competency slowly. Then, we hit a period of quick learning where we become very adept at the task. After that any additional expertise comes slowly. The counter-challenge to competency is adaptability. When we are unfamiliar with our task, we are more open to new ideas of how to do the task. Once we become adept at the task, it becomes quasi-automatic (that is why we are so efficient). In this automated nature, we are not open to new ideas or able to recognize paradigm shifts. The graph below demonstrates that adaptability decreases the more competent we become at a task. The point is that competency is great in a stable world, but what happens in a world of constant change? Therefore, in this new world, business executives must be prepared operate in a different manner to succeed. While the efficiency gained by competency is attractive, it must never be at the expense of not being able to identify and adapt to change. How does your organization avoid the competency trap? My guess is that many large corporations have incredible difficulty in this area.

Recently, I made recommendations to a public company on how to improve its method of valuing its new product development projects. One of the areas we discussed was Options Analysis that I feel is a better method of financially evaluating technology new product development projects. I have embedded a slide show that demonstrates how NPV's assumptions can undervalue a new product's value. Options Analysis incorporates more realistic assumptions to more accurately value a project. Some things to keep in mind.

1. The added reality increases the complexity of the model. Where NPV can be straightforward, Options Analysis requires you to conceptually understand how options work. I wouldn't recommend it for incremental innovations or low cost projects, but for major PD decisions I strongly feel this is the way to go.
2. PD decisions are not completely made based on financial analysis. In fact studies have demonstrated that companies that solely relied on financial analysis to make investment decisions earn lower returns than companies that use a combination of financial and strategic tools.

I wanted to write a brief comment on a topic that I hear frequently thrown about: Developers would prefer not to deal with people on the business side. I definitely heard this perspective at GSP this past week. I strongly believe, like it or not, we need each other. Business people who love the software arena know we need coders (most of us can't code). Developers like to think they don't need business help, but monetizing cool programs take a different skill set. It was certainly evident at GSP that developers waste alot of time thinking about monetizing the product. I ask you, would your time be better spent coding while someone with those skills focus on that side? Many great businesses realized they needed people with complementing skills - where would Sergei&Larry be without Eric?

As with all relationships between very diverse personalities, the main thing we need to do is improve how we communicate with each other. Coders like to code cool challenging things that interest them and feel that business's requests are not important. Business people want coders to code things people will pay money for and feel that coder's interests will lead to feature creap; creating user-unfriendly products. In reality, the world is not so black & white; the truth is in the middle. A great benefit of my career is the opportunity to communicate with many different functional areas. This exposure has taught me to appreciate their unique perspectives.

Business people need to work hard to understand the world of a developer. Try a little coding. Research development styles. Ask them what is new and cool in their areas - you may find some information that could improve your product. When dealing with coders, the best lesson that I have learned is to take an interest in their world; their opportunities and challenges. Don't expect trust to immediately form, but if you put an honest effort it will grow over time and make you more effective at your job. If coders like to work with you, they will make you look like a star to the other suits.

Now coders, I know business can be a pain in the butt, but look at it from their side - They need to deliver numbers to their superiors. If they are a good at their job, they are obsessed with the consumer's point of view of the product. While I know you can easily navigate the software, but you wrote it! You need to consider how a person unfamiliar with the software (or possibly any software) would respond. Your business guy should be gathering survey responses, feedback from sales, etc. Leverage that data to make your code better!

Developers and Business may speak different languages, but if effort is made by each side to understand the other's perspective great improvements in the quality of the software can be made. Further, developers, let business handle the monetization of your products. This is a big job and if you want to grow the business, you must choose to focus on one or the other. So, if you love to code - code. Let the business person bring in the money. Of course, you will need to find ways to ensure that business performs. Another topic.