High Tech Market Research for New Products

One of the biggest problems in High Tech businesses is the "technology-driven" approach that tends to predominate, especially among startups. Much of this occurs due to the fact the many founders of software and technology companies tend to come from an engineering, programming or other technical background. While a strength in creating a flow of technical innovation, this can be a real problem when companies are planning new products which they hope to find a real market for.

Everyone has a tendency to focus on what they know best; that's just human nature. Folks spend more time on the issues that they enjoy, are more comfortable with, and are more confident about their ability to make good decisions on. Things that don't fit into this category tend to be put off, or given short shrift.

The result is often products are well thought out from a technical viewpoint--but much less well so from a "meeting market needs" perspective. While both are important, the market perspective is absolutely critical initially. So what's the right approach to product planning-oriented market research?

When Should The Research Should Be Conducted?
The answer to this is early, often and forever. The earlier you start prior to design or coding, the more time you will have to obtain the most accurate picture of the market that's possible. Sometimes there are practical limitations to how early you can start--Trade secrets and patent filings, for example, or the lack of a prototype which may be considered crucial to receiving realistic market feedback. Within these limitations, get out and begin interacting with the marketplace as soon as practical. And don't ever stop. Markets, especially the software and technology variety, are like living organisms. They are constantly growing and changing. What may be true in the early phases of a market could change dramatically over even a short period of time. Companies tend to develop an internal "common sense" that is used in making decisions, which is based upon past inputs. When doing Product Planning this can very dangerous in a dynamic market.

Who Should Do The Research?
The best way to do this research is what I often refer to as the "two-headed monster" approach: one marketing person, and one technical person. Not a lone wolf if you can help it, and please--no committees. Most often, this would be a Product (Marketing) Manager along with the Engineering Project Manager who will lead the actual development of the project. In the smallest startups, it might be the technical founder and the "business" founder, for example the CEO and CTO, or CEO and VP Marketing. The Business/Marketing manager should be in the lead for this task, but it's important to note that both camps have a role to play in this endeavor. There are two different perspectives on market feedback, and well as two different priorities in questions to ask. Having both parties involved (assuming there isn't a dysfunctional relationship) usually leads to the most complete and risk-reducing result. In addition, it often eliminates arguments over priorities later in the process after coding starts (and schedules inevitably begin to slip) If only one can be available, it should be the Marketing side--working closely with the Product Development/Engineering lead to make sure their input is included in the process.

How Should The Research Be Conducted?
This is a really broad question which of course depends heavily on the situation. How much do you have available to you in terms of money and other resources? If you're in a big company, you may be able to commission some objective research. If you are a startup with modest resources, it usually is an ad hoc exercise of visiting and interviewing potential customers.

What's most important to keep and open mind, and eliminate your own biases and pre-conceived notions. This exercise needs to be a search for the truth, not an attempt to validate your own theories. Also, make sure that you are talking to the right people. If you are planning a market-creating breakthrough product, you really need to be talking to Early Adopter types, not the guy or gal that only buys after everyone else they know. If you are introducing a product that is very similar to other products in an already large market--but maybe at a lower cost--by all means, talk to those mainstream buyers and even the late adopters. Use the current market phase to guide who to get input from.

It's great if you have the money to do some formal secondary research, but be careful about confusing formality with accuracy. For example, I know of large companies that spend huge amounts of money on Focus groups, while their Product Managers only reluctantly talk to actual potential customers directly. I find this very dangerous (you might say stupid!). Particularly with breakthrough technology, you tend to find a "garbage in, garbage out" phenomena with professionally managed focus groups. But there is that formal, professional looking report that appears very convincing in the aftermath. They can be great if constructed properly, but I have seen a lot of money spent for a very bad result. If the focus group wasn't run properly, or the technology is very revolutionary, the results can be total garbage covered in a beautiful wrapper. I always advise that there is a good amount of old-fashion ad hoc research--talking directly to customers--to be used as a sanity check, if not the main research technique. There are exceptions, of course. If you are doing incremental product research, where the product is well-understood and the changes are evolutionary, objective research methods such as surveys may be a great way to get a quick and definitive read on the market's reaction.

How Do You Know When You're "Done"?
This really depends on what you are doing, but my general answer is that "you will know when you are done when you get there". It's important to not put an absolute time limit on the research, if it is at all practical. In some cases in the real world, this isn't possible, of course. Sometimes you just have to go with the information that you have gathered up to a set point in time, along with your market common sense, intuition, and gut feel. With incremental product releases, waiting may not be possible or necessary. But if you can avoid it, especially if starting a new company, division, or business area, resist the temptation to "go with what you have", if it just doesn’t' feel right. In my experience, when you've "done enough" research to begin serious product planning--it's obvious. You will feel very comfortable with regards to the clarity of the current market snapshoot, and feel you've really nailed the wants and needs of the market as it relates to the new product opportunity. Try not to get "antsy" and move forward because you've reached the original market research end date on your theoretical timetable. Resist that temptation and keep working until you are CONFIDENT that you are there, unless other factors just won't allow it.

Summary And Conclusions
Make sure that you do sufficient market research before you begin building products; product development on a developer's gut feel is most often a prescription for failure. There are a few high profile companies which have entered our folklore that were lucky enough to start that way, but usually this approach will quickly empty your pockets, rather than make you rich.
Include both Marketers and Technologists in the Research if at all possible. In summary:

*Marketing should take the lead on market research for new products
*Always make sure you talk to at least some customers directly and informally
*By wary of formal market research results, if not supported by an informal research "sanity check"
*Make market research a continuous company function
*Don't stop an individual product-oriented market research project until you are comfortable that you've got the correct answer.

There you have my thoughts on market research for product planning purposes. I'd love to hear yours as well.

Phil Morettini
PJM Consulting
http://www.pjmconsult.com/

System Integration vs. Product Development

I've recently engaged on assignments with two new clients. Both of them have businesses selling to large, blue chip customers. Customers of the size that are used to "having it their way"; as a result, getting a deal with them often includes the need for a lot of customization.

The interesting thing about these two clients is how they perceive and approach that need to customize.

A Tale of Two Companies

Company A views customization somewhat as a pain and distraction, something to be controlled--I am assisting them with creating a standard solution offering menu outlining the "Base" offering, with a list of options available at an added cost. They really want to discourage certain customizations, absolutely won't do some things that will be asked, and want to make sure that they charge dearly for items that they find painful. They have the classic mentality of a product company; they want to do the amount of customization necessary to make a large sale to this important customer--but NO more than they have to.

Company B, which also considers itself a product company, has a very different mentality about customization. They welcome it, pride themselves on it, and position themselves to these potential large clients as someone that can quickly bring solutions to the client, customized to their desires. They want their big account reps to be scouring the big accounts for unique pain points or opportunities, which might fall within the company's core capabilities, enabling them to propose a customized solution. In fact, up till now, their product development approach has really been to find out what individual accounts want--and build it for them.

So which of these two business models is the best way for technology companies to go?

System Integration Business Models

Advantages:
*More flexible and able to change with shifts in the marketplace
*Not as capital-intensive due to less "betting" on upfront product development
*Easier to grow business organically with internally-generated capital than in a product business

Disadvantages:
*Less risk due to lower upfront investments
*More competition; System Integration is an "easier-entry" business
*Generally lower operating margins
*Growth is less scalable than a product-oriented company

Product-Focused Business Models

Advantages:
*Provides greater opportunity for strategic advantage and resulting fast growth
*Less competition if a product/brand/technology differential advantage is created
*Can scale much quicker if a hit product is developed
*Higher operating margins if product is successful
*Usually more marketing-driven and less labor-intensive
*If creating a very large company is the goal, much easier to raise outside capital

Disadvantages:
*Much more risk of "crib death", resulting in complete capital loss if first product has problems in development or marketing
*Harder to "get over the hump"; success is harder to come by, and success often happens as a step function after a difficult startup period

First of all, I want to emphasize that there isn't necessarily a "wrong" approach with either of these business models. You can make a lot of money pursuing either model. Both of the companies I have used as models have managed to attract blue chip customer which would be the envy of any company. What we are really talking about here is the difference between a classic product-driven company and a system integrator.

Company A is that classic product-driven company. They customize when they have to, but also have a point where they will say "no".

Company B also self-identifies itself as a product company, and in fact they have built their business around a small number of standard offerings. But as their core strategic advantage they really are utilizing relationships, the ability to customize beyond what standard product companies (especially larger ones) are willing to do, as well as to react very quickly to customer requests. They've built a very nice business doing this, but have some frustrations as well. They are highly dependent upon a small number of major accounts for virtually all of their revenue, and have the major revenue/profit swings that are associated with this type of business--up one year, back down the next. They also are in constant fear that a larger company will come along and "take away" their marketplace, because they've continuously failed to create new products which build upon a core offering which is very dated technologically. The core offering appears long-in-tooth and vulnerable. This company is very account-focused, and the lack of a market focus has kept them from being able to create additional, broadly marketable products which provide them with a strong proprietary advantage (and causes a lack of sleep at night!)

Company A understands who they are and what they want. That doesn't guarantee success, but it makes it much easier to build a plan that everyone agrees on. At that point success or failure usually depends upon execution, unless the plan is awful. If failure ensues in this scenario, more times than not, the problem is in execution. Company B's biggest problem is that they are floating right in the middle between the two business models. They are trying to leverage both of these business models, and struggling with execution, in some ways with both.

SUMMARY
It isn't impossible to combine these two business models successfully. I'm sure that many of you can't point to several examples of such a very successful compromise. In fact, many technology companies combine both of these models to some extent, with good success. But I find that usually, a company identifies itself primarily as a product company first, or a systems integrator. That identification is their strategic focus, and takes precedence when prioritizing the use of always scarce assets.

The secondary business model is usually utilized on an opportunistic basis. Product companies integrate and customize as needed to get a big deal. Integrators create "products" to fill the needs of a big account, and sometimes happily find they are saleable to other accounts. Occasionally, these "products" prove so widely saleable that they are spun off into a separate product company, or the integrator changes its focus into becoming a full-blown product company.

The most important thing, in my opinion, is to understand who you are, and what you are trying to accomplish strategically. It's the company's that are trying to leverage both business models at once, without one model taking the lead, that gets itself in a heap of trouble. That's my opinion--what's yours?

Phil Morettini
PJM Consulting
www.pjmconsult.com

Organizational Structures in Software & High Tech Companies

So you've put together a hardware or software startup company. Chances are you didn't give a lot of thought to what the next step should be in organization development--you just wanted to bring in some revenue and find a way to keep the doors open. Or, maybe you gave it a great deal of thought, even before you bound your initial business plan--there are quite a few anal-retentive planning types out there--you know who you are!

I don't mean to make light of this issue; it's actually quite a serious one. Let's look at a few of the questions to consider when deciding how to organize your company, as well as a few options.

IMPORTANT QUESTIONS TO PONDER

What are the strengths, weaknesses, and operating styles of the principals? I believe that this is a critical question to ponder, if one wants to organize the company successfully. One of my great examples is HP. Bill Hewlett and Dave Packard instituted a decentralized structure almost from the very beginning of Hewlett-Packard. They were careful to keep the units small, by breaking them up as they grew. In my opinion, this was one of the great drivers of HP's success, and worked well because it suited their personalities, as well as the folks that they hired. They believed in "Management by Walking Around", but also believed in motivating high performance by allowing their employees to use all of their talents, without unnecessary constraints. It seems simple, butit is often hard for managers (especially hands-on, entrepreneurial types) to give their employees enough rope and space to excel. I believe that this hands-off, decentralized approach only worked well because this style fit with Bill and Dave's personalities.

What are the key personality traits of your employees and target hires? Similar to the question about the principal's above, the organizational style needs to fit with the "personality" of your company, the culture. If you have a lot of type "A", self-motivated people with strong leadership skills, a decentralized org chart may fit better than a hierarchical, centralized approach.

Are there disparate technologies within the company? This is a big driver in deciding how to organize. If you have several different technologies, how do they fit together technically--if at all? Do they fit together from a market perspective? If there is a lot of synergy or need to coordinate between technologies/products, a centralized, hierarchical approach may work best. The less "fit" that there is between your core technologies or products, the more inclination I would have to organize using a decentralized, business unit approach. This assumes that the resources are available for a decentralized organization. But if resources are so scarce that you can't decentralize properly, does it make sense to try to be successful with multiple disparate products/technologies anyway?

Now let's take a look at some common ways to organize.

ORGANIZATIONAL OPTIONS

Hierarchical/Functional/Centralized - the classic organizational style of traditional businesses. The strength of this type of organization is that it is easier to optimize each function, as there are more resources available within each function in a centralized approach. This can enable a more sophisticated approach to best practices. On the downside, my first job was with a Big 3 Automotive manufacturer, which was VERY hierarchical and centralized. The company was SO hierarchical that it paralyzed the organization to a huge degree; trying to get even the simplest, small thing done had to go many levels up. It was like trying to turn a battleship on a dime, and really painful. I'm not a big fan of this style for larger organizations, but for smaller, single-market or single product companies, it generally is optimal.

Decentralized/Business Units - This is the polar opposite of the traditional hierarchical organization. It's my preference for growing companies who are starting to "spreading their wings" beyond their initial market or technology focus, as well as for larger companies. It's strength lies in the ability to keep lines of communications short, keeping personnel close to the marketplace, and motivate self-starters by providing more positions of broad responsibility. For medium-sized companies, the danger lies in decentralizing before there is really critical mass to run separate business units, which comes with some added costs due to duplication of functions. One good way to mitigate this is to centralize and share as many of the non-product specific functions as possible, such as finance, HR, quality control, etc. The key functions that absolutely need to reside in the business units are usually marketing, product development, possibly manufacturing (for hardware companies) and occasionally sales.

Product-Centric or Market-Centric- This is a variation that can be combined with either of the two major organizational structures above. For example, within your marketing department, there could be people assigned as product managers, or as market managers. Sometimes a hybrid approach is used, where there are product managers for unreleased products, and market managers for currently-marketed products.

Matrix - This organization style is "overlaid" on top of a more typical organizational structure, such as the types discussed above. The main idea is to set up "dotted line" teams, responsibilities and reporting structures that are desirable, but fall outside of the normal way a team is constituted within the main structure in use. For example, in a hierarchical organization, you might set up a matrixed, cross-functional team to put focus on the launch of an important new business initiative. This may give the new initiative more emphasis than it normally would get, given its modest contribution to the overall business at that point. If used properly, matrix management techniques can be a great way to dampen the negatives that are inevitable in any rigid organizational structure. It must be used with caution, however. If used too frequently, or without endowing the "head" of the matrix with real power to accomplish the desired goals, matrix organizations can quickly become ineffective and politically driven entities--and the butt of jokes around the water cooler.

This is just a quick take on a very complex topic. There are many different ways to organize a software or technology company for success--too many to discuss here. And we just touched on a few of the issues to consider. Hopefully this short article will stimulate some thinking on this topic, to avoid organizational structure which often form haphazardly as companies are started and grown. Post a comment if you have a take of your own.

Phil Morettini

PJM Consulting

www.pjmconsult.com