Morettini on Management

General Management and Marketing Advice for Software and Tech Companies

Tag: product planning

BYOD, Enterprise Mobile ISVs and Cross-Platform Support

One of the hottest trends in the technology industry these days is the phenomenon know as “Bring your own Device” or BYOD. For IT departments, this is the latest control-related nightmare they loath so much. The original technological shift from Mainframes to Minis and PCs was probably the start of many control-related sleep disturbances and BYOD continues the trend. Mobile computing in itself was bad enough from the perspective of the internal IT folk;. Mobile BYOD may be enough to push them all to drink.

But enough about anguish for the IT guys: what are the implications of BYOD for independent software vendors?

Cross-platform support

One of the major challenges–or opportunities–that I believe software vendors face in a BYOD world is the potentially wide variety of mobile platforms to support. Many readers are likely thinking “its only the iPhone/iOS and Android, so not a problem. Nothing else is relevant.”

Maybe-But bear with me for a bit.

Things aren’t always what they seem on the surface. For one thing, Android is hardly a single, tightly unified platform like iOS. It’s basically an open source operating system in which every OEM can (and often does) modify the OS to provide differentiation on their hardware platform. In a way this can be a good thing by spurring innovation; but if you’re a third party software vendor dependent on the parts of the OS that is often modified–it can also be viewed as problematic. But should it be?

Google has recently sought to rein in the fragmentation issue as the numerous hardware-focused variants were causing a lot of consternation in the third party software community. At a minimum this fragmentation causes a great deal of testing complexity, and at worst the necessity to maintain different code for each hardware OEM’s platform.

Back in the old days

This reminds me of back in the 80s in the early days of MS DOS. IBM had its PC DOS version and all of the other PC hardware OEMs had their own version of MS DOS as well–almost compatible with each other, but with just enough variation to cause problems. Needless to say, this caused problems in the ISV community which had to choose between supporting myriad platforms–or picking winners. Neither appeared to be a great choice.

Even if you don’t consider the Android fragmentation issue serious, I contend there are other similar platform support issues. In a world tightly controlled by the IT department, the platform choices might indeed be limited to Android and iOS. But what about Blackberry, Microsoft and any new platforms that might come along in this large and competitive market? Again I can almost see the smirking by some reading this: “those platforms are market also-rans with very small market shares. I don’t need to support them!”

Or do you?

Back in the old days–one more time

One more time I’ll take you way back for another analogous situation. In the 90s I was running a systems/network management software business targeted at the enterprise IT market. This was an “add-on” product business; our product ran on top of the Network Operating Systems (NOS) of the day. Back then, Novell Netware dominated the market with an estimated 60-80% share of the business. The other major NOS platforms (widely considered also-rans) were Banyan Vines (about 5-8% market share) and numerous OEM variants of Microsoft LAN Manager (10-15% share total). LAN Manager was slightly different depending upon the OEM hardware platform, much like Windows itself in the earlier example and Android today. The fragmentation of LAN Manager made it even less desirable for an add-on ISV market segment like our category.

All of our competitors looked at the market and designed their products to run strictly on Netware.  On the surface this made total sense. There was just one problem—in the enterprise IT market (the primary target for our segment) the customers are huge companies with a lot of buying power; they like to get vendors to do what they want. Of course, many enterprises did standardize on Novell Netware at that time.

We took a contrarian approach at the time and chose to extend our product, supporting both VINES and LAN Manager in addition to Netware. We found that the larger the company, the more heterogeneous their networking environments tended to be. Even if 90% of the systems within an enterprise were based upon Netware, there was a strong desire in enterprises for support of ALL of their networks companywide. So although Banyan and Microsoft LAN Manager each had a modest number of accounts using only their NOS (we won those by default), we were in a much stronger position than our competitors in the largest enterprises with heterogeneous network environments. We won far more than are share, and the additional revenue more than made up of the modest additional development cost and support complexity.

So how do software vendors capitalize?

I bore you with the old case study above because I believe BYOD in the Enterprise will only accentuate the benefits of supporting as many platforms as possible. Although many companies with highly influential IT departments will limit choice, this is really against the spirit of BYOD. While it may look unlikely to some right now, I see BYOD generally moving the enterprise mobile software market toward heterogeneous, multi-platform environments. Forward thinking ISVs would be wise to consider this in their product plans.

There are many new challenges that are already rising as the BYOD movement takes hold. BYOD in the enterprise is a rich area for discussion. In addition to the cross-platform support issue discussed here, there are major security, legal, support and economic/cost considerations to consider. Some of these issues don’t yet have great answers–maybe we’ll explore them in a later column. BYOD is a major paradigm shift for all segments of the IT business. I believe that there will be many more yet unforeseen factors that will greatly impact the landscape for enterprises, end users and software/hardware vendors as the situation matures.

What are your thoughts on the cross platform support issue we’ve raised in this article? Give us your take. And what are some other issues brought on by BYOD that aren’t widely being discussed yet? Post a comment so we can all benefit from your experiences.

Follow Phil Morettini and Morettini on Management via Twitter, Facebook, LinkedIn, RSS, or the PJM Consulting Quarterly Newsletter. Contact Phil directly at info@pjmconsult.com

Save on DeliciousDigg ThisShare via email
Submit to redditSubmit to StumbleUponShare on Tumblr
No Comments by admin on March 16, 2013
filed in Business Models, Corporate Strategy, General Management, Product Marketing/Management, Software/Product Development, enterprise software
tagged , , , , , , , , , , , , , , , , , , , , , , , , , ,

Software Product Marketing: Horizontal vs. Vertical

An important discussion for most software companies–both in the product planning stage and in the downstream active marketing phase–is the manner in which it will be marketed. The decisions to be made in each phase are separate but closely related. This set of discussions need to happen regardless of whether you are marketing a traditionally licensed application, an open source application or a SaaS application.

One of the more important aspects to this is whether the product will be aimed tightly at one or several vertical segments, or marketed more broadly to the widest possible audience. This is the crux of the vertical vs. horizontal decision. Let’s examine a few topics which can be useful in framing this discussion.

How specific is the “language” of your application to a vertical audience?

This is very important because in some product categories the unique business processes of a vertical can be very important, while in other categories there is great commonality in process and language across industries. If you’ve written your application specifically to solve one market segment’s unique problem, it’s probably VERY specific. When this is the case it’s pretty obvious that you’ll start (and possibly end) with a highly vertical marketing effort. Sometimes as thing go along you may find that you’ve solved a problem for market A, but it’s also useful in market segment B and C–although there often needs to be at least some modification. If you’ve solved a more generic problem that applies to many markets, the decision to market the solution horizontally or vertically can be much less clear.

How big is your overall market?

A key consideration when you’re entering a new market with a new product. The larger the market the more likely it is you will need to take a vertical approach get initial traction. In many cases this means verticalizing the product in the product development phase. But even if there isn’t a strong set of vertical needs with respect to product features and “language”, in large markets a vertical promotional approach may be required to build market traction. It is often far easier to build a brand name and market traction in a tight vertical before you move on to the next segment, than by taking a more scatter-shot approach with no vertical focus.

What is the level of competition in the overall market?

This question is related to first question above as strong competition often goes hand in hand with large markets. They are separate issues, however, and should be evaluated individually. If the level of competition is high, regardless of market size, a new entrant is likely to have a better chance of success with a more vertical approach. It there isn’t significant competition in the segment, you may be able to have success with a horizontal approach, which can be a more efficient way to use both product development resources and marketing dollars.

Market maturity: has the overall market verticalized already?

Regardless of the level of competition and the market size if the larger market has already evolved into a number of vertical sub-markets, it may be too late to take a horizontal approach. It is usually very difficult to defeat entrenched verticalized competitors when entering a market with a horizontal application. The exception to this would be a new competitor with a product that provides a quantum leap forward in functionality (usually as a result of a technological paradigm shift).

What level of marketing resources are available to you?

The level of marketing dollars available to you are quite important in formulating your approach to the vertical vs. horizontal question. As one example, let’s say you are entering a market that is large, quite competitive and you won’t have a lot of marketing budget available. In this case, it would be very important to develop the product upfront with the strongest vertical focus possible and market it accordingly. On the other extreme, you might be entering a market of modest overall size that hasn’t verticalized to a great degree to date and you are well funded, enabling a substantial marketing budget relative to the competition. It this case it might be an easy decision to take the ROI-efficient horizontal approach both from a product development and promotional perspective. There are many potential scenarios between these two extremes which unfortunately will lead to less obvious decision-making.

Is your software a “point” or “platform” application?

Most software applications are “point applications”, meaning they have little or no integration with the rest of the software infrastructure. In addition, any possible customization is generally intended to be done by the application vendor themselves or maybe their channel partners.

I define a software application as a “platform” when it utilizes an open API which enables BOTH channel partners and third party software vendors to write add-on applications which extends the platform software’s functionality in two key area:

1)      by adding “vertical” functionality not present in the platform software thereby enabling a complete solution for a specific vertical market.

2)      using the API to integrate the application with other parts of the software infrastructure

In this way a platform software application allows a software vendor to “have it’s cake and eat it too” with respect to the Horizontal vs. Vertical discussion. The platform software itself provides basic functionality which can be sold broadly across many markets, while the open APIs enable the product to be tightly customized for specific verticals as required, by both your channel partners and independent ISVs. The platform application can be a product manager’s dream and is the Holy Grail of software when it comes to efficiently serving as many market segments as possible by leveraging partner investments. But it’s not something that can be forced; there needs to be a natural reason for the platform to exist, or there will be no third parties willing to write the add-on applications so critical to the platform’s success. Without these add-on application a platform will more often than not die a quiet death in the marketplace.

In some cases, such as when you write an application which aimed at a problem specific to a single vertical market, the answer to this “vertical vs. horizontal” question is easy. In many other cases you’ve created a product which is useful across several market segments–but do you have the resources to attack multiple market segments simultaneously? How do you approach this common problem?  Leave a comment below with your take or shoot us an email with your questions.

Follow Phil Morettini and Morettini on Management via Twitter, Facebook, LinkedIn, RSS, or the PJM Consulting Quarterly Newsletter. Contact Phil directly at info@pjmconsult.com

Save on DeliciousDigg ThisShare via email
Submit to redditSubmit to StumbleUponShare on Tumblr
3 Comments by admin on February 16, 2013
filed in Business Models, Corporate Strategy, Distribution Channels, Product Marketing/Management, Promotion, SaaS, Software/Product Development, Startup/Early Stage, VARs, enterprise software
tagged , , , , , , , , , , , , , , , , , ,

Integrating the Marketing and Engineering Functions at Technology Companies

In most tech companies, Product Marketing and Product Development/Engineering are managed separately. There is usually one VP over the Product Development function and another VP over the overall marketing function, which usually includes future product marketing/planning.

While this is certainly an appropriate way to organize a tech company, there is a great danger in one are when it comes to these separate operating “silos”: the planning of new products.

I have a particularly strong opinion on this topic, with an extensive product marketing background and also having worked as a product developer earlier in my career (albeit in a non-tech business).

With respect to current products, the silo approach isn’t much of an issue. The day-to-day activities of the marketing and engineering departments are very different, and can be managed separately quite successfully.

It’s in the future product area that things can get messy. Product Marketing and Product Development both have a key role to play here, if the company is to optimize the process of planning, developing and introducing the best new product possible. The problems is that at every level, from the VP-level down to the engineering project managers and marketing product managers, the product marketing and engineering functions are often staffed by individuals with very different world outlooks when compared to their direct counterparts in the other department.

Inevitably, if care isn’t taken, these very different personality types can lead to some pretty intense conflicts. I’ve been a soldier, captain and general in this war–and let me tell you, at times it isn’t pretty. The battlefield often is the company’s strategic plan, which ends up in a trampled mess. I have seen this battle play out all too often in the companies that I have worked for as an employee, as well as at many of my clients in eight years as a consultant at PJM Consulting. It sometimes gets so ugly it paralyzes a company, putting it at a severe disadvantage vs. competitors who have less conflict.

THE “WRONG” WAYS TO HANDLE THIS POTENTIAL PROBLEM

Unfortunately, most CEOs that I meet are not all that tuned in to how damaging these conflicts can become.

Often they will ignore or deny the problem, thinking it is a responsibility to be handled at the VP level.

Another strategy that I have seen companies put in place is to extract the product planning function from the marketing department, and put it under engineering. This will often greatly reduce or eliminate the conflict, but it is akin to throwing the baby out with the bathwater. As I said earlier, both marketing and engineering have a key role to play in product planning. This strategy effectively removes the voice of the customer, which is a key role that the marketing department should be playing in any successful software or tech company. As much as product developers think it looks easy, they seldom have the mentality or experience to accurately read markets or customers. Almost no one is great at everything; monitoring and reading markets and technical product development are two very different skill sets. Having both mentalities involved in a positive way via both departments leads to far better products in the end.

Finally, if they happen to have come from one side of the battle or the other, CEOs sometimes “take sides” in the battle–predetermining the winner. The problem is there is never any real winner in this battle–and the only certain loser is the company and its shareholders.

A CEO can choose to let Marketing have the upper hand–and this may work out adequately in commodity products where there is very little engineering differentiation. In any other circumstance, results will likely be sub-optimal.

Or he can let Engineering win and dominate the planning process–which is a very common occurrence in early stage, technically-driven software and hardware companies. But this generally only works well for products made by engineers, built for engineers (the early days of Hewlett Packard are an example of this strategy working successfully). For every company that has used this approach successfully there are probably hundreds or thousands that failed in large part because of it.

Ultimately, to make sure that this conflict and its dire consequences are avoided, there is one key thing that needs to happen:

IT IS THE CEO’S RESPONSIBILITY TO PREVENT, RECOGNIZE AND FIX THIS PROBLEM

So what steps can a software or hardware CEO take to be on the lookout for this problem–and more importantly, what can they do to prevent it from developing?

  • It’s all about relationships: closely monitor the personal relationship between the VP-Marketing and VP-Engineering
  • Make sure that the VPs are monitoring the relationships below them
  • Make sure they are both VPs are open and honest with you about the relationship between the departments
  • Plan activities which allow engineering and marketing counterparts to get to know each other as “people” outside of their project activities
  • Be careful that you don’t inadvertently make decisions or set up policies that reward or tolerate politics
  • Design goals and MBOs to reward the two departments for working together
  • Don’t ever allow one department to “get ahead” by blaming the other–tie them together as much as possible
  • Hire marketing personnel that can talk the language of engineers
  • Screen product development hires who will interact with Marketing without the not-uncommon attitude that engineers are “superior” human beings
  • Encourage the marketing department to get product developers in front of customers
  • Watch out for arrogance when screening potential new hires for either department that will need to interface with the other –arrogance is often the trigger which starts the battle rolling

SUMMARY

Marketing/Engineering conflict over the product planning process is a common problem that is often overlooked by tech company CEOs. A certain amount of creative tension can exist between the two departments and be totally healthy. All too often, though, this tension turns into a bloody fight which is destructive to the company’s prospects. It is not “fait accompli”, however. It can be minimized and even prevented by a watchful and proactive CEO.

That’s my take on a common issue which is rarely discussed out loud. Have you had your own issues in this area? Post a comment below to add to this discussion.

Follow Phil Morettini and Morettini on Management via Twitter, Facebook, LinkedIn, RSS, or the PJM Consulting Quarterly Newsletter. Contact Phil directly at info@pjmconsult.com

Save on DeliciousDigg ThisShare via email
Submit to redditSubmit to StumbleUponShare on Tumblr
No Comments by admin on July 8, 2008
filed in General Management, Operations, Product Marketing/Management, Software/Product Development, hardware
tagged , , , , , , , , , , , , , , , , , , , , ,

High Tech Market Research for New Products

One of the biggest problems in High Tech businesses is that a “technology-driven” approach that tends to predominate, especially among startups. This shouldn’t be a surprise. Much of this occurs because many founders of software and hardware companies tend to come from an engineering, programming or other technical background. While this enables a strength in creating a flow of technical innovation, it can also cause a problem when companies are planning new products aimed at a new market.

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.

In technically-driven companies the result is often products which are well thought out from a technical viewpoint–but much less well so from a “meeting market needs” perspective. While both are very important, the market perspective is absolutely critical in the initial stages of a new product.  So what’s the right approach to product planning-focused 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 hardware 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. That common sense serves you well in relatively static markets, but can work against you when conducting product planning in a dynamic market.

Who Should Do The Research?
The best way to conduct 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. Quite 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 development 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  depends heavily on the situation. How much do you have available to you in terms of money, time 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, along with some background Internet research.

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. Focus groups 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  a good amount of old-fashion ad hoc research–informal individual discussions 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 snapshot. You’ll 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 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 more often this approach will quickly empty your pockets, rather than make you rich. Include both Marketers and Technologists in the Research if at all possible.

*Marketing should take the lead on market research for new products
*Always make sure you talk to at least some customers/prospects directly and informally
*By wary of formal “arms-length” market research results, if not supported by an informal research “sanity check”
*Make market research a continuous company function
*Try not to 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 conducting market research for product planning purposes. I’d love to hear yours as well–post a comment with your experience and views.

Follow Phil Morettini and Morettini on Management via Twitter, Facebook, LinkedIn, RSS, or the PJM Consulting Quarterly Newsletter. Contact Phil directly at info@pjmconsult.com

Save on DeliciousDigg ThisShare via email
Submit to redditSubmit to StumbleUponShare on Tumblr
1 Comment by admin on March 10, 2008
filed in B2C, Pricing, Product Marketing/Management, Social media, Software/Product Development, Startup/Early Stage, market research
tagged , , , , , , , , , , , , ,

High Tech Product Planning

There are many ways to skin a cat, so the saying goes. Planning high technology software and hardware products seems to fit in the same category.

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 or drop me an email message.

Follow Phil Morettini and Morettini on Management via Twitter, Facebook, LinkedIn, RSS, or the PJM Consulting Quarterly Newsletter. Contact Phil directly at info@pjmconsult.com

Save on DeliciousDigg ThisShare via email
Submit to redditSubmit to StumbleUponShare on Tumblr
No Comments by admin on September 29, 2005
filed in Corporate Strategy, General Management, Product Marketing/Management, SaaS, Social media, Software/Product Development, Startup/Early Stage, enterprise software, market research
tagged , , , , , , , , , , , , , , , , , , , , , , ,