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.

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 you are comfortable that you've got the correct answer.

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

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