Morettini on Management

General Management and Marketing Advice for Software and Tech Companies

Category: Software/Product Development

Will SaaS Lead to the Death of Software Product Management?

There is a lot of talk in the software business these days about changing business models, particularly the trend toward SaaS (Software as a Service).

Will SaaS business models dominate the software business?

Many consultants, pundits and other industry figures are proclaiming that SaaS will very soon take over the world; saying if you’re not on the bus soon, you’re going to be out of business. I believe this is a bit overstated, but the strong trend toward the SaaS business model can’t be denied.

My opinion on SaaS adoption: When bandwidth is unlimited and close to free, all IT systems are totally secure, the Internet is as reliable as old AT&T; and every customer in the world decides they want to rent everything and own nothing–then I’ll agree that SaaS is heading toward 100% market share. As I said above there’s a strong trend in this direction, but we’re a long way from there.

Is software product management dead?

I’ve written about SaaS a number of times before, and since it has become very important in the software business I’ll continue to do so frequently. What I want to address today is another opinion some “experts” are also espousing: that the trend toward SaaS means the end of the Product Management function in the software business.

I find this statement to be downright silly.

When following this debate, it’s important to take notice that many of the folks proselytizing these opinions have businesses whose success is based upon these predictions actually coming true. It’s always important to consider conflicts of interest among the debaters.

In one recent webinar they trotted out a SaaS software company that was growing briskly every year with no product managers in the company. What wasn’t said is that it was always possible to find software companies (of the traditional sort) who didn’t have a product management function. Software companies are often founded by programmers, and they haven’t always seen the need for Product Management. There are very successful companies where the developers talk directly to the customers, with no product managers at all. However, the facts are that a very small percentage of companies that do business this way are successful, and its usually based upon special circumstances: the rare developer who understands markets and customers as well as he does coding, markets where the developers themselves are perfect customer proxies, etc.

So while software companies without Product Managers have always been out there, it just hasn’t been a broad formula for success. Trotting out one SaaS company successfully doing business this way (incidentally, I saw some big holes in their model long-term) doesn’t impress me much.

I’m not defending the status quo–I’ll say it once again, there is a huge move to SaaS in the software biz. Many (and maybe most) will be doing business this way in the near future. However, like most over-hyped trends, this are some pretty big overstatements being thrown around.

SKILLED product management will always be important

The argument being made is that many of the functions Product Managers currently perform are obsolete under the SaaS model. With continuous development more practical using SaaS, there may be fewer (or no) new version introductions. So the old waterfall chart with MRDs being created for the new version may go away along with new product introductions. I’m sure you get the picture. SaaS is a pretty fundamental change to the software business model, so you wouldn’t expect a product manager’s job to be stagnant under such change.

But those predicting the death of product management are focusing on the more mundane aspects of Product Management. The essence of this critical function is the ability to understand markets and match widespread, aggregate customer needs to the technical skills and IP of your company–creating a PRODUCT which can be sold to these many people. It doesn’t matter whether you deliver this PRODUCT over the Internet in a hosted manner using monthly subscriptions, or in the more traditional on-customer premises, licensed model. Product Management is about creating a profitable PRODUCT well-matched for a market segment. It matters not whether you are engaged in customer facing marketing/promotional activities, or upfront product planning–the product manager’s understanding of market needs and how your company can fulfill those needs is crucial in a product business. Otherwise, you’re just selling custom software–one-off’s for every customer. That’s a different business–not a bad one–and one you which doesn’t require product managers.

Can Social Media replace Product Management?

Another thing being bandied about by my favorite pundits is the impact of communities and other social media for its potential impact on product development. The thinking goes that there will be much more direct interaction with the end customer, leading to tremendous amounts of data available to ISVs. While SaaS is very well suited to communities (although not exclusive–they can be well utilized by traditional licensed software vendors), the ability to more easily obtain direct customer comments, and maybe take votes on potential new features doesn’t eliminate the need for product management. To the contrary. While communities and other forms of social media are very powerful tools, don’t mistake more data and customer access with actionable market intelligence. Data needs to be interpreted, and skilled marketers are best positioned to discern who’s telling you what and why–the underlying motivations behind any customer feedback. So all of this added customer access and resulting data will only put a premium on good product management, to use these powerful new tools and data for quicker action and to allow better product planning decisions. Remember, SaaS competitor down the road will have access to the same tools and data that you do.

It is rare to find a developer who has truly exceptional product management skills. That’s not a knock on developers; as a whole they are an extremely sharp bunch. But specialization in life happens for a reason–very seldom is someone the best at everything. Developers are trained to write code and build applications, not understand markets or extract the “truth” from customers. Different types of people’s brain’s work differently, and a good developer and good product manager are an example of this.

I find that it’s when a talented, open-minded development manager teams with a market-savvy product manager, that most great software applications are made. So no, I don’t believe that the Product Management function is going away anytime soon in the software business. There are many important changes going on in the business, the SaaS business model not the least of these. With any change in business model, functional roles will evolve and change. But I believe strongly that Product Management is a fundamental, important role that will remain critical in software businesses far into the future.

That’s what I think about SaaS and product management–what do you think? Post a comment to start the discussion! Follow Phil Morettini and Morettini on Management via Twitter, Facebook, RSS, or the PJM Consulting Quarterly Newsletter.

Startup Mistakes by Software and Tech Companies

Starting a company, any kind of company is the hardest thing to do in business. Sez me.

It’s also one of the most rewarding and fun, if you’re built for the startup experience–though not everyone is. Technology startups have their own unique challenges. There are many different ways to drive off the road, some of which I list below. Keep in mind that no startup is perfect, and mistakes will be made. The future can not be forecast, and in a software or tech startup you’re often flying nearly blind without a map, because you are trying to do something new and different.

In the end, if you are able to make it through, overcoming your mistakes may be the most satisfying part of the whole startup experience. So keep in mind that it’s almost impossible to play a perfect game. On the other hand, it’s crucial to steer clear of the mistakes which are often avoidable–because you only get some many chances to recover from errors.

Here are some of the common, often avoidable missteps to be aware of:

Too little capital
Sometimes this is unavoidable–but if you really don’t have enough capital maybe you shouldn’t start up in the first place. Activities such as software product development are notorious for going way past schedule and over budget. Most products don’t move like a knife through butter with the first modest promotional campaign. So build a decent amount of backup money into your plan, because things rarely go as planned. If they do, great, you can use the money to accelerate growth. But when things don’t go well, you’ll at least give yourself a fighting chance, if you’ve set aside a bit of money for a rainy day.

Don’t try to be a “Big Company” right off the bat
Many startup management teams are jealous of the resources available to their established competitors. These folks can become “Big Company Wannabes”, a classic formula for going out of business early. Don’t spend your precious time and resources on activities that don’t efficiently bring the product out, or market it. Period. Lavish trade show booths, company parties, expensive or large offices, administrative assistants for all the execs, etc., etc. Don’t hire a lot of big company people who don’t have early stage experience–they are prone to the types of costly waste listed above.

No backup plan
It is a startup and you have to expect little margin for error in reaching success. But that’s no excuse for a lack of strategic planning–within the constraints of your resources. A backup plan might be something simple: software companies going to open source if your high-priced commercial strategy meets resistance, a service-oriented revenue strategy with a cheap or free product, using a channel rather than building a full sales force, licensing your technology instead of marketing a full product to end users. It depends on your circumstances, but do try to have some type of a contingency plan going in.

The “Techies know everything” syndrome
This is a common malady in tech startups, because many new software and tech companies are led by management heavy in experience from the engineering or software development side of the business. Usually these folks are very smart, but in some cases also a bit full of themselves, unable to know their own blind spots. Those blind spots often appear in marketing and sales (which every engineer and software developer knows are easy, non-complex activities). The really smart guys quickly figure out those other parts of the business besides the tech stuff is hard as well, and make adjustments through education and bringing in outside expertise.

The “Technology is everything” syndrome
This is a corollary to the bullet point above. The technology and product is crucial in a tech startup, since it is usually the basis for your competitive advantage. But it’s not everything, and many a startup has failed despite great technology and an exciting new product.

No marketing budget or in-house expertise
Believe it or not, I see a lot of companies with little or no promotional budget. Its insanity, but they only have enough money to get the product built, apparently thinking “if you build it they will come”. This is nearly always a failure mode. If there is someone with marketing expertise among the founders, they usually won’t allow this to happen. So secure a marketer on your founding management team, or at least find a close advisor you will listen to, early on.

Under-estimating time to market
This is a very common mistake. By definition, you are trying to do something new, which isn’t forecast-able. So don’t believe your own pretty Gantt charts–garbage-in equals garbage-out when it comes to schedules. Don’t count on making it to the big trade show, commit to costly promotional activities with no recourse, or let the developers all plan to leave for that well-deserved month in Hawaii. Get the product done first. I tell you this with many painful experiences as a teacher, both personally in software and tech companies and through my clients.

Under-estimating time-to-success
Even if you are able to get the product out on time, that doesn’t mean version one will hit the ground running. They often crawl, stumble and fall at first. After all, this is your first opportunity at really accurate market research. Even if the product is right on target, finding the marketing mix that works is generally trial and error. Many products don’t find success until their second version is released, so have some money in the bank, and some emotional bandwidth available for this possibility.

Introducing a “buggy” product
This is one of my biggest pet peeves, especially for software products. Most products aren’t fully stable when the developers think it is ready. They work on it so long and hard, that human nature wants it to be finished near the end–and dangerous shortcuts can be the result. Dedicate as many resources as you can spell to ensure a credible, third party view that the product is as stable as it can be, before the market gets the opportunity to “debug it” for you. You only get one chance to make a first impression. If the situation is bad enough, it can cost you your business.

There are my thoughts on what critical mistakes to avoid in a technology startup. I’m sure many of you have your own lessons and ideas to share. Post a comment to start the discussion! Follow Phil Morettini and Morettini on Management via Twitter, Facebook, RSS, or the PJM Consulting Quarterly Newsletter.

Cloud Computing, SaaS and Such–Have We Read This Story Before?

I have this incredible feeling of déjà vu.

Cloud computing and Software as a Service is all the rage. In my practice at PJM Consulting, I am very involved in software startup activity. Nearly every new software company that I see today is being built on the Software as a Service business model. It’s all the rage–so much so that it appears that any self-respecting software entrepreneur would be embarrassed to start a company using the traditional software licensing model. Even if an entrepreneur was so inclined, good luck finding a VC who would even consider funding such a company. No one wants to look like a dinosaur.

It’s all well and good–there is definitely a real trend toward SaaS and Cloud Computing, with many good reasons for it. But most high technology trends are initially a bit over-hyped, and tend to get ahead of themselves. In addition, this particular story seems ever so familiar to a tech veteran that’s been around for a few of these cycles.

The first bit of history this reminds me of is the old terminal/mainframe model from the early years of computing. There were some real advantages to this model, but also some big disadvantages as well–which opened the door for the golden age of PCs and networking.

The second era that the current SaaS wave reminds me of is “Web 1.0″, when Web-based hosted software (then called ASP rather than the modern SaaS terminology), was first going to take over the world. The current trend seems so very similar because it was around the Web 1.0 years of the late 90s/early 2000 when the traditional software license business model was first proclaimed dead. At that time nearly every new business plan was based upon an ASP model.

So some of this fast-moving Cloud Computing or SaaS trend is new–but much of it could be viewed as recycled from past trends. Let’s look at the Pros and Cons of this computing model:

ADVANTAGES

* Enables “Utility-Style” computing – variable expense instead of. capital investment
* Allows an end run around overwhelmed IT departments (like PC networking did)
* Supposedly “On-demand”–use only what you need, when you need it
* More efficient use of compute resources by time-slicing large farms of cost-efficient computing resources
* Web-based allows anywhere, anytime availability
* Off-site storage of data assists disaster recovery preparedness

DISADVANTAGES

* Immature and inherently more difficult Security
* More difficult integration with other applications
* Internet latency
* Internet reliability
* Data resides outside the company firewall
* Costs over time aren’t necessarily lower for customers
* Lower margins for software vendors–aren’t always accounted for in current pricing

SUMMARY

I believe that the trend toward computing in the cloud will continue, but there will be some stumbles and pullbacks along the way. Cloud Computing and SaaS has some inherent strengths–but also some under-publicized weaknesses. Many software vendors are overlooking the weaknesses at this time, as is typical of any new and hyped technology. Traditional licensed software hosted by the user still has its strengths and a definite place in the market. Like many mature technologies and business models, the death of traditional software licensing has been greatly exaggerated. Once the early hype passes, decisions on whether to computer within the firewall or in the cloud will once again be made on the individual merits, costs and user needs for a particular application within a particular company. That’s how I see it–post a comment with your opinion so we can look at all viewpoints.

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

Oracle is buying Sun?

Breaking News…. Oracle buys Sun!? What’s wrong with this picture?

What’s surprising is that a very large software company is buying a very large hardware company. You often see a hardware company buying a software company, but I can’t really think of a deal that’s gone the other way around. Certainly not at this level. My practice at PJM Consulting serves all kinds of technology companies–but a focus is on software. Although every situation is different, my typical advice is for software companies to stay away from hardware, if at all possible.

This news is very interesting on several levels:

Involvement of two high profile, strong personalities in the technology business
I’m talking about Larry Ellison and Scott McNealy. Of course, MCNealy no longer actively runs Sun, but he is still Chairman and a power to be dealt with. He was allegedly the force behind the killing of the potential deal with IBM. Apparently Larry and Scott are old buddies, so maybe there won’t be a problem. But these are two very strong-minded, controversial and sometimes outrageous leaders. Even though they are long time friends, they have never before played together so closely in the same sandbox. It wouldn’t be shocking to see a few disagreements, and some public drama as a result.

Combining the Largest Revenue Database Product with the Largest in Unit Market Share
This aspect of the deal will not get as much attention as some of the others. But Oracle is the 500 lb Gorilla at the top end of the market, and the open source MYSQL is the most popular database choice at the low end, particularly in website development. This aspect likely won’t demand anti-trust scrutiny because they don’t really compete directly. But potential marketplace competition from MYSQL going up market, and Oracle bringing out lower cost solutions, is eliminated by this deal.

Software Company buying a Hardware Company
As I stated above, this is highly unusual, especially for companies of this size. Most established software companies have very high margins, and wouldn’t want to “pollute” their earnings with the lower margin, often commoditized hardware revenue. I can’t think of another comparable deal, looking back even into the distant past. The business models are pretty different. In hardware companies manufacturing efficiency and inventory control are major factors in business success; in most software businesses these are inconsequential factors to success. Hardware businesses tend to be more capital-intensive, while software businesses are very R&D; intensive. I could go on, but suffice it to say that the management of these businesses includes different functional skill sets. Why is Ellison interested in Sun? Just for the Java and the Solaris OS software, or is he really going to continue with the hardware business as well? Even though in some ways, Sun was a bargain at the price of just under $6B net. But if he’s just interested in the software pieces of Sun, the price looks pretty steep–Sun’s direct revenue from Java and Solaris is a pretty minimal portion of its total revenue. Ellison had a flirtation with hardware years ago with the Network Computer concept–could he really still be itching to become a fully integrated systems company?

What will Oracle Do With Sun’s Software?
To me, this is by far the most intriguing question raised by the deal. Solaris is a nice OS, and has a good installed base. But it’s never really had the same impact in the market since open source Linux came around. Java is pervasive in the computing arena, and in embedded systems as well. It has a huge impact on the Internet. It’s literally everywhere. But after trying to charge big money for Java in the early days, Sun decided to give it away. I was intimately involved in the embedded Java market in those early days. Sun initially looked like they had created a technology that could allow them to challenge Microsoft for computing dominance. I believe Microsoft was very worried at the time. But to say that Sun fumbled the ball would be way too kind. Frankly, their effort to commercialize Java was like something out of the Keystone Cops. I could detail their myriad missteps. To summarize, the biggest problem was that they were a hardware company attempting to commercialize a software product, which usually doesn’t work very well. Sun appeared not to have a clue as to what they were doing. Finally, they quit trying to directly make money at Java; they put it into open source and basically decided to give away the technology to anyone who wanted to use it. It looked to me like a way to spite Microsoft, more than anything.

What Happens to Java?
So where does that leave Oracle once they close the deal and own Java? What is their plan to leverage Java in the marketplace? Will they start trying to charge for it somehow? I think this is doubtful; there’s probably no going back on that decision at this point. I’m sure that Mr. Ellison and his team have something in mind–but I can’t imagine what it is. They’ve been very savvy at making some acquisitions that haven’t looked all that complementary, that have worked out well. So I wouldn’t bet against them. But I can help wonder if they haven’t stretched a bit too far in their minds to find synergy in this one. It reminds me a bit of Ebay’s very expensive purchase of Skype, which is now being unraveled because it just didn’t create any synergy. We shall see what happens–it should be interesting to watch this unfold.

SUMMARY
The prospective Sun-Oracle deal is one of the more interesting we’ve seen for a while. There shouldn’t be any major anti-trust issues with this deal, and it doesn’t appear that a higher bidder is likely to emerge. Watching the organizational integration (and possible divestment), as well as the interaction of the outsized personalities, should be entertaining at the very least. But most of all look for what Ellison does with Java–that’s where the real intrigue lays. Post a comment to give me your view of this deal.

Phil Morettini
PJM Consulting
www.pjmconsult.com

Google Chrome–a Strategic Platform or just another Browser?

Google’s new Chrome Browser came out a few weeks ago to quite a bit of attention. It’s big news 1) because it’s from Google and 2) it brings back memories of the “browser wars”, and seems like it could potentially signal the next big battleground in the intense rivalry between Google and Microsoft.

I’ve downloaded Chrome and played with it a bit, but this isn’t intended to be a technical review of Chrome’s merits. It seems reasonably snappy, and has Google’s typical minimalist design philosophy, including a single box for multiple functions (search, address bar, etc.). Your personal preferences will decide whether you like that or not. It has some nice features such as tabbed browsing, which theoretically should prevent one bad browser window from crashing all open browser windows–much like when Windows became multi-threaded. Nice stuff, but doesn’t really fundamentally change the browser game. But technically it’s still a beta anyway (of course just about everything is with Google), and it will evolve over time–so it’s not really time to judge it from a technical perspective anyway.

What I want to do is to examine Chrome as a strategic move by Google with respect to the software and online worlds–what does it really mean, where will it take the market, and what are its chances for success?

Let’s take a look at some of the potential ways that Chrome could affect the marketplace:

A Better Browser
Of course, PR propaganda always will say that this is the “real” reason for bringing out a new product such as this. When I was at HP we used to call this “making a contribution to the market”. Google in particular often gets sanctimonious about this type of thing, with all their “do no evil” and saving the world stuff. Does the world really need another, better browser? Not sure. Firefox and Safari, to name two, are already probably technically superior to IE, and while they’ve made some inroads in the marketplace, they still trail Microsoft by a wide margin. But history tells us that competition is a good thing, and a step forward on major platform like a browser can certainly be thought of as a gateway to allow software innovation to develop faster. Having a company like Google enter the fray should increase rate of innovation that’s possible in the online market.

An Application Development Platform
This is the position that many pundits suspect may be the major impact of Google’s move. In their introduction, Google talked quite a bit about “remaking” the browser for Web 3.0, if you will. And a fresh approach does make sense, given that Internet Explorer was conceived long before serious online applications were envisioned for the Web. With SaaS and Web 2-3-4.0 currently all the rage, having a browser platform designed from the bottom up to accommodate online software applications should be a good thing. If it’s all it’s cracked up to be, this could conceivably be a game-changer and a real threat to Microsoft. The key here is how much of the talk about re-architecting the Browser is real, and how much is hype. This will become more apparent over time as Chrome is further developed, and application developers take a look to see if there truly are features they can take advantage of to build better online apps for users.

An Additional Way To Track User Behavior
This is one of the more cynical viewpoints as to the major motivation behind Google’s introduction of Chrome. The thinking is that this is one more insidious move by Google to “big brother” your online activity. It’s no secret that Google uses web activity data they collect by various means (such as Google Analytics) to fine-tune their advertising business. Certainly owning browser could be seen as the “holy grail” towards creating a complete characterization of online activity. What else might they use this data for, in addition to fine tuning their advertising platform? That’s the question and concern.

A Way To Drive More Search Traffic And Adwords Revenue
Along the same lines as the bullet point directly above, owning the browser could be seen as the ultimate in terms of driving web traffic toward Google’s Adwords online advertising. The first thing you see upon downloading Chrome is the opportunity to switch to Google as your default search engine. How much will they do in this regard, either subtly or in a straightforward manner? As stated above, at a minimum, it gives them the opportunity to make Google the default search engine, which is critical to their base business. Only time will tell how much of a factor this is in Google’s Chrome strategy.

A “Real” Competitor Aimed At Microsoft IE To Make Them Defend Their Turf
Of all the bullet points I’m raising, this is the one I’m most sure of. Google and Microsoft are locked in one of those classic death matches for online software supremacy, and don’t miss an opportunity to tweak their arch-rival and make them sweat a bit. Going back to the application development argument above, there is a feeling that Chrome could serve as the basis for a suite of online Google apps to threaten obsolescence for Microsoft’s desktop software business. I don’t doubt that Google may try to do this. But even if from a technical and marketing perspective Chrome is only a modest success, it almost certainly will get Microsoft’s attention and cause them to expend resources and management attention on browser technology, to an extent they may not have preferred.

SUMMARY
Chrome is intriguing, but it’s too early to tell for sure what the major reason is for this Google initiative. They may not even know for sure themselves at this point. But the product, and more importantly the move itself, will likely make Microsoft react. The ensuing competition should be all good for the user and developer communities, as long as it doesn’t take us toward another tiresome and market-paralyzing “platform API” war. I’ll be following the future development of Chrome closely to see where it takes us–how about you?

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

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 a VP over the Product Development function and another 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, it isn’t pretty. The battlefield often is a company’s strategic plan, which ends up in a trampled mess. I have seen this battle play out regularly 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 of a conflict.

THE “WRONG” WAYS TO HANDLE THIS POTENTIAL PROBLEM

Unfortunately, most CEOs that I meet are not all that in tune 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 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 almost never 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 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 tech 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 even thousands that failed in large part because of it.

Ultimately, to make sure that this conflict and its dire consequences are to be 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 tech 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 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 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 for 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 interface with the other –arrogance is usually 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 to add to our discussion.

Phil Morettini
PJM Consulting
www.pjmconsult.com

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 y
ou 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/

Strategies for a Technology Market Slowdown

Is the world economy slowing down? What are the implications for technology companies?

Recently, technology stocks (along with the stock market in general) have tanked. There is a credit crunch that shows no signs of abating, and inflation is rearing its ugly head, with the continual climb in the prices of oil and other natural resources–commodities which touch every aspect of the world economy. Is the economy headed for a severe downturn–taking technology businesses down the drain with it?

I hardly think so, but we have had a very long running economic expansion, that eventually will reverse by the universal law of “what goes up, must come down”. Economies are cyclical by nature, so a downturn has to happen eventually. And tech stocks are usually affected more severely than average in an economic downturn, which affects technology industry investment and ultimately tech growth rates.

So what should you do if you’re the CEO of a software or hardware tech business?

Be Prudent, But Don’t Panic
Now’s certainly not the time to stick you head in the sand, and hope the economy doesn’t get any worse. It almost certainly will; but more importantly, how will it affect your company? That’s what you need to ponder. Is your product a “must have” or a “very nice to have”? Obviously the “nice-to-haves” will have a tougher time in a declining economy, and should plan accordingly. So take the time to analyze you situation, and make a forecast for your own business, based up the unique circumstances of your market and company. Remember, hope is not a strategy.

Look For Opportunities to Outflank Weaker Competitors
For strong players, declining economies can be a great time to pick up market share from weaker competitors. If you have the resources and can do it safely, now might be the time to run a promotion, or selectively increase your marketing. It’s counter-intuitive to most managers’ instincts. But weakening the competition during a downturn can lead to stronger growth when things turn back upward.

Slow Near-Term Expense Growth, But Don’t Compromise Long-Term Initiatives
In most cases, companies will want to carefully monitor, and possibly cut back on their spending. You want to make sure that you don’t put your company in jeopardy, by have expenses out of sync with flat or declining revenues. But try your best to keep intact the initiatives that are critical to long-term growth. You must continue to think long-term as well as short term, assuming you don’t get in a situation where your survival is at stake. Cut back on advertising and office space if you’re seeing a slowdown–but make sure you don’t cut the product development project which will lead to growth 18 months hence. These can be tough decisions, but they really separate the long-term successful CEOs from the flash-in-the-pans. Almost anyone can manage when times are good.

Limit The Growth Of Your Staff
While prudent spending can be wise during a downturn, aggressively increasing the size of you staff usually isn’t. There are always exceptions, of course, but adding too much staff can really bloat your fixed cost structure, in a manner that limits your management flexibility. Unfortunately, many companies are often most aggressively adding staff at the end of a growth cycle–just in time for the downturn. If this leads to layoffs, it can have a devastating effect on your company’s morale.

Although layoffs are sometimes necessary, they are always painful and hurtful to the company culture–unless the company culture is already of the “Attila the Hun”, cutthroat variety. The founders of one of my former employers, Bill Hewlett and David Packard, ran HP for many years with a rule of thumb that limited staff increases to 25% of revenue growth. This helped them avoid the natural inclination to hire someone new every time a new task was identified. I believe was an important factor in many years of smooth growth–without layoffs. This particular metric might not be right for your company, but something similar could prove to be a useful damper on excessive hiring.

Make Sure That You Have Money For A Rainy Day
While it’s no time to panic, it IS time to make sure that you have the financial resources necessary to comfortably cruise through a downturn. VCs and Private Equity firms have been flush with cash; if you are close to a deal to bring in outside investment capital–don’t wait–so it now. Availability of funds and terms will only get worse, as the stock market heads down and the credit crunch continues. Also, make sure that you have available the largest line of credit possible with your bank. It may cost you an extra few thousand dollars a year, but its excellent insurance, if you are surprised on the downside. If you’re in startup mode and financing yourself on credit cards and home equity lines–maximize your future access to these as well! Whatever your sources of funds, make sure now that you’re financially well prepared for whatever the future holds.

Be Poised For The Next Upturn, Whenever It Happens
I mentioned earlier that you should try your best to keep long-term initiatives alive. In that same vein, your thought processes should CONSTANTLY be focused on the next upturn, in all of your decision-making. Again, this assumes that your survival isn’t in question. For example, while massive hiring isn’t usually wise during a downturn, you want to always be open to unique opportunities that may not come along often. Say there is a talented executive available, only because of the downturn. If you can safely afford him or her, snap them up now, before a competitor grabs them. Downturns often present opportunities to improve your business when the next growth cycle occurs. But you need to be “looking ahead” and making good decisions now, to take full advantage of the upturn when it finally does.

Summary
Once again, now is not the time to panic. But it is an important time to plan. Anyone that can predict what will happen with an economy should go to the nearest casino–no need to waste your time with a software or technology company! So I suggest that it might be wise to do a “best-most likely–worst” 2 year forecast now, and try to plan as best you can for the two extreme cases. Post a comment and let me know your thoughts on how the economy and the tech industry will fare in the coming months.

Phil Morettini
PJM Consulting
www.pjmconsult.com

Negotiating and Working with Large Technology OEM Partners

The Holy Grail for many software and technology companies, especially the early stage type, is the big deal. Everyone is looking for the big deal, the one that will fund the company’s early activities, provide market credibility and momentum in the marketplace. Of course, if it goes well, there can be nothing better. Many times the big deal takes the form of an OEM partnership with a much larger company. But often when these deals do happen, they end up fitting in the category of “be careful what you wish for”.

TARGET YOUR OEM PARTNERS CAREFULLY
This is where it all starts, good or bad. It’s important to pick compatible partners. Companies looking for large OEM partners are often blinded by the potential of what the OEM can do FOR their business. They often fail to pay any attention at all to what the OEM might do TO their business!

Can the partner cause severe channel conflict? Will they tie the small company up in endless meetings, procedures and negotiations? Do they have a corporate structure and culture so foreign to your way of doing business, where you end up pulling your hair out from frustration–unable to accomplish even the most simple business objective without moving mountains? Sometimes with large companies, its difficult even figure out who you need to speak with–let alone get a prompt, unambiguous answer.

Get to know your partners well before you sign a deal. It’s tempting to rush in before “they change their mind”, but the actual relationship is critical to potential success. It’s like dating before a marriage–no matter how attractive the partner is, you need to make sure you can live with them later on.

NEGOTIATE FROM STRENGTH
I don’t like to do deals with people that are sure they have the upper hand. If they think they can push you around–they almost certainly will. Usually one partner needs the other to a greater extent, but you want to try to avoid dealing with partners where you have no leverage at all. It generally doesn’t’ turn out well. Make sure that you negotiate a deal that you can live with. Above all, you need to have a “line in the sand” that you won’t cross–and be prepared to walk away if the negotiations cross that line.

This can be a painful and difficult thing to do when you are seeing big “dollar signs” in your eyes–and fear if you stay strong, you might blow the deal. But remember, you have something that the other side wants as well–or they wouldn’t be talking to you. If you don’t know what your minimum successful deal looks like, and you aren’t prepared to walk, you may sign a deal that you will regret. Not to mention tying up your time and resources, which might have been used working with a more compatible partner.

WORK ON EVEN TERMS
Once you’ve negotiated a deal that you can live with (and hopefully prosper with!), it’s time to get to work with your partner. Try to keep things as fair and even as possible in the relationship. Of course, it’s important to be accommodating to your partner, and respect the differences in operational procedures. Big OEMs will usually move slower than you, be more process-oriented and structured, and include more people in the relationship. All of this is fine, but it needs to be tempered so that the larger partner doesn’t “swallow all of you available resources whole”. It can easily happen if you don’t guard against it. They have more resources than you (but will always think they are busier!) as well as more process-driven requirements that need to be met. But don’t be afraid to draw the line at a reasonable point, and remind them that you have fewer people and resources available. Suggest a phone meeting instead of flying three people across the country–ask that they come to your place, rather than always trekking to their headquarters. Propose that one of there folks spearhead writing that joint position paper, instead of some scarce resource in your company–you get the picture. Sometimes larger companies will smother you without even knowing they are doing it–don’t be afraid to remind them that you need to do business a little differently.

KNOW WHEN TO SAY “NO”
If you’ve tried everything you know, politely, to keep the relationship equitable and reasonable–but it just isn’t–don’t be afraid to say NO. I meet many smaller company executives in my consulting practice whojust don’t feel they can do this with a larger partner. They’ll talk tough in internal meetings, but when back in discussions with the partner, the tough talk turns to submission. They just feel like the partner is too important to their business to risk ever offending them in any way. That attitude is a prescription for servitude for your company. I’m not suggesting being unpleasant; in fact, when standing up to a larger partner, it’s critical to be calm, polite and non-defensive. But by all means be firm in delivering the message of what your business can, cannot–and won’t'–do. If you don’t, what could be a profitable relationship can turn very sour.

HAVE REALISTIC EXPECTATIONS
The last point I’d like to convey is that it’s important to have reasonable expectations in partnering with large OEMs. Many companies go into these deals believing they will be “company-makers”. In my experience, this rarely happens. Understand what the OEM can do for you, and build your business model around the most conservative projections of their performance that’s possible.

Companies usually turn to OEM products from partners to fill niches that they don’t fully understand, or don’t feel would pay back–if they invested in developing it themselves. It is very rare for products licensed or resold from partners to get anywhere near the push that internally-developed products do. Be realistic about this, and you won’t be disappointed. If revenue exceeds your conservative expectations, you’ll be overjoyed.

SUMMARY
That’s my condensed advice on working with the big software and technology OEMs of the world. This is a common activity for many companies–what’s been your own experience? Post a comment and let me know your own view.

Phil Morettini
PJM Consulting
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