While there are some models that you tend to see over and over again, there are a lot of ways that planning of products occurs in the technology industry.



DEVELOPER-DRIVEN PRODUCT PLANNING

One typical way is what I call "developer--driven". That's when an engineer, software programmer, or inventor comes up with a new way to apply an existing technology in a novel way to a different, unsolved problem. Or in some cases, the developer is a true visionary, and actually invents a new breakthrough technology, that blows away the existing way of doing things.

While this developer--driven model is very common, and when it works it can lead to blockbuster successes, this approach is rife with problems--I have repeatedly been brought in to clean up the results of this approach in my consulting practice. The reason for this is that companies using this approach usually have a technology or product--centric view of the world. And what's missing in the view?

CUSTOMERS!

Now I don't want to insult all the technologists out there who have taken the lead in developing products. Of course, technology professional understand the need for customers, and the importance of getting their feedback in the product development process. Some have a natural knack for product planning, and are highly effective. Yet the reality is that product developers aren't trained to, nor do they generally derive any pleasure from--trying to extract product preferences, unsolved problems, and workflow issues from potential customers. Often customers don't really know what they want, or have some other agenda which can lead a product planner in the wrong direction--unless the planner is experienced and savvy in uncovering the desired information. Let's face it, developers are trained to design hardware and write software code. Many do pick up product planning skills--but in my experience, it's far from the majority.

The end result of a developer--driven product is often one that is launched, gets a few customers, but then stalls long before gaining traction and critical mass in the marketplace. Precious cash has been burned through, and the typical lament is "it's a great product, if we could only find someone to sell it". What is frequently believed to be a customer--facing sales and marketing issue, is quite often a product that doesn't meet customer needs--as a result of flaws in the product planning process.

CUSTOMER-CENTRIC PRODUCT PLANNING

Another common way that I've seen products planned is what I call the customer--centric approach. This method is characterized by using a few "model customers", with a fanatical devotion to using their input to develop the product. Often you will see this in a company that has previously failed using the developer--centric model discussed above. Sometimes, it's the same technologists on their second try. Now, you may be thinking, this is the way you do it! But while this approach is definitely an improvement in some ways over a purely technological approach--it too has some limitations.

The customer centric model works well if you are developing for a very limited, niche market--or at least one that is quite homogenous. The problems occur in two areas. First, if your target market is of a heterogeneous nature, it is easy to miss that part of the market that isn't represented among your select few model customers. Secondly, this approach can sometimes stifle innovation. In high technology, customer input is very important--but customers shouldn't be doing your product planning for you. Each has their own quirky agendas, unique to their individual companies. In addition, customers often can't see far enough past their current problems and needs--to imagine how to apply technology to make a radical improvement in their workflow, 2--3 years down the line. So if you only build what they tell you to build, you will often end up with a mostly mundane product, and also one that contains a few features that the greater market will scratch their head over why they were included. Worst of all, the product may be nearly obsolete by the time it hits the streets, because you haven't looked far enough ahead of the market, and built--in what's possible and desired for the future. These products get stuck in the present of when they were planned--which in the tech world, is the distant past by the time they are introduced.

MARKET-CENTRIC PRODUCT PLANNING

Finally, let's talk about the way product OUGHT to be built. I call this approach a market--centric model, although it includes elements of both the customer and technology--driven approaches.

The most basic requirement for success in this approach is to have a skilled, balanced product planning team. The core of this team consists of an experienced Product Manager with a marketing background, and an experience Engineering Manager or Technical Project Leader. I call this the "2--headed monster".

Having two leaders to a project sounds like a prescription for design--by--committee, which usually satisfies no one. And there are definitely dangers to this approach. The most problematic (and frequently encountered) issue is when the Product Manager and Engineering Lead clash, or just don't like each other. Then you have a real problem--and one that must be dealt with quickly. But that's a topic for another article. The important thing here is that to make a truly GREAT high tech product, both the Product Manager and Technical Lead possess key expertise that needs to be brought to the table.

The Product Manager is the market expert, and customer proxy when necessary. He is the one who is trained, experienced and skilled at uncovering the true needs and latent desires from potential customers. He also has a market perspective, so he will ensure that all important segments of the market will be canvassed to ensure that the resulting offering is MARKET--driven--not shaped by love of a cool technology or requests from a few key individual customers.

The Technical Lead brings a couple of critical skills to the table. He keeps the discussion centered on what's POSSIBLE, ensuring that you don't plan a product that can't meet the required timing and budgetary constraints--or worse yet, can't be built at all! In addition, he or she can "see ahead" and inject the use of new technology to solve a problem, in a way that those less technical might not be able to envision.

I won't pretend that this approach to planning products is easy to implement. In truth, it's hard to pull off. The key ingredients to success for this model are an honest, open process and culture, where everyone is motivated by the success of the product and ultimately, the company. In companies with a high degree of politics, or rivalries between departments, the process tends to fall apart quickly, to no ones benefit or satisfaction. Mutual respect is critical. Anyone should be allowed an opinion on any aspect of the product.

An engineer can express an opinion on the customer base, or marketing approach. A marketer can have an opinion on what technological approach is most appropriate. This cross--fertilization of ideas is very valuable, and can lead to innovative approaches that just aren't derived from orthodoxy. But at the end of the day, after all the discussion has taken place, there must be mutual respect and trust in the competency of each functional area. Marketing people must be trusted on marketing matters; developers must be trusted on engineering matters. If that trust isn't there or is lost during the process, a successful product is unlikely.

BEST FOR SUCCESS

When done right, the Market--centric approach to product planning is optimal. It usually leads to solid singles and doubles, with the occasional home run. It reduces your risk of an outright flop, while increasing somewhat the normally long odds of creating a blockbuster, market--leading product. Once a company has evolved their product planning process in this manner, it's poised to introduce a succession of market winners.

That's my take on planning great high tech products. What's yours? Post a comment on my site or drop me an email message if you've got an opinion.