software revenue accelerator blog

Does the migration to cloud-based computing spell doom for Microsoft?

eriks@atlanticcrossing.com — September 21, 2011 3:36 PM EST

This post is a loose translation of my post on the technology business blog at Danish national newspaper Berlingske.

Q: How fast will the transition to cloud-based computing take place, and what will it mean to Microsoft and their cloud-based products like Azure and 365?

A: This transition will be going on over the next 25 years - meaning that some apps will probably never be migrated. As an example, some of the back-office banking systems in use today were probably written in the 1970s for a mainframe computer - which is where they are also still executed today.

The apps with the most value, and with the highest re-development costs, tend to remain where they are... but very little new stuff will be developed for these stagnating platforms (mainframes, minicomputers, file servers, client/server). So the market may be seen as a huge lump of jelly, moving at varyings speeds depending on the segment in question.

The established players on the established platforms have a great interest in delaying the transition as much as possible - IBM on mainframes would be as good an example from the late 1980s as Microsoft is now on client-based computing.

The market value of Microsoft franchise relies almost exclusively on client-based software. Indeed, it would be easy to argue that the entire life cycle of Microsoft is closely correlated with that of the personal computer. Which was once called a micro-computer... the parallel to micro-software is almost too obvious.

It came as no surprise when Microsoft a couple of years ago started talking about "Software and Services" - even when they were speaking at conferences like SaaS University 2008 (http://www.softletter.com/SaaSUniversity/SaaSUniversity.aspx) where the rest of us were doing presentations on Software-as-a-Service (aka "cloud computing").

People that underestimate Microsoft's ability to change and reload have often paid dearly for their beliefs (including this author). And in the current situation it seems that Azure and 365 are true cloud products, or services, to remain in the lingo. But if one draws a parallel back to IBM 20-25 years ago, it would also be a fair guess to say that the product managers of Microsoft's cloud-based services probably have some uphill battles internally in the organization.

The whole development will, however, be interesting to follow. I can't recall any example from the history of software where the "defending champion" on the old platform has won the battle for the new one.

Market-Driven development and Product-Centric marketing for software revenue acceleration

eriks@atlanticcrossing.com — June 30, 2011 11:35 PM EST

We can build upon our previous observations in the case of the early commercial development of what eventually would become Microsoft Dynamics NAV. The developer Navision (née PC&C) and IBM managed to cooperate to fulfill market demand, using perfect alignment of the Development, Administration, Communications, and Sales functions, all orchestrated by effective Product Management and Product Marketing.

As we noted in our previous blog post, PC&C had a very good understanding of what the market demands were at the time. And they were able to convert that into a first-class product through a largely informal, intuitive product management process that integrated the northwest corner of our model.

So the development was definitely market-driven, the product ideas coming from market observations and/or intelligence. And it is easy to argue that any software developer that brings forward a product that at least some players in the market are willing to pay for, has found success in being market-driven.

But as most software developers will testify, having a product that some customers will buy, is probably less than half the battle. Then comes all the Product Marketing questions: how will the product be marketed, where, through which sales channel(s), under what name, with which prices, bundled with which other products and/or services, and so on.

All those items must find answers, answers that function well with the product itself. This exercise is far from trivial, as many failures will attest to. Changes to any one of those areas will most likely have an immediate and direct impact on perhaps even all the other ones. As a consequence, the Product Marketing function must have great vision, a very wide angle of view, and great attention to detail in the exchange with each of the “four corners” in the model.

Most importantly, however, Product Marketing must make all these details work, based completely on the product that has been developed – that is the sole point of departure for all these efforts. As the aforementioned René Stockner of IBM and Navision often stated: “A software company is an exercise in Product Marketing.”

With those wise and visionary words, we arrive at the perhaps somewhat counter-intuitive conclusion that software success is built upon Market-Driven development and Product-Centric marketing. And that leads logically to naming our model for software revenue acceleration “The Market-Driven/Product Centric™ Model” – or MD/PC for short.

A foundation for software revenue acceleration

eriks@atlanticcrossing.com — May 29, 2011 2:09 PM EST

In our previous blogpost we discussed how ERP-vendor Navision in its early years managed to achieve significant software revenue acceleration.

Due to the short format, we skipped a couple of background items that we’ll pick up in this and following posts. First of all, it’s evident that the software developer was in pretty good synch with the market. They used experience through their existing sales channel to gain feedback with requests for new functionality – and they used incredible sharpness in translating that into product functionality.

Although the tiny developer didn’t have a PM function per se, the North-to-West flow from the Sales box in our figure, through Product Management & Marketing, to Development worked very well. Any given company might not have all the boxes in our figure as real or conscious functions. But that doesn’t mean that those functions are not being performed – at some level.

What IBM then did very well in this model was to take the product and through a product marketing function, create the communication that the sales channel could use to explain the product’s benefits to the market. In terms of our model, that’s West to East, followed by East to North – both via Product Management & Marketing in the middle.

In our experience, these last two steps are where most software companies fail.

“The usual method” is more like: “Great, our product is ready, let’s hire some salespeople.” This method not only skips the communications part of it – it usually attempts to go straight from Development to Sales, bypassing Product Management & Marketing in its entirety. And the expected sales never materialize, or if they do, it’s through a painfully slow process.

Such attempts to short-circuit the marketing and communications process are responsible for thousands of derailed sales careers, and probably thousands of soured angel and venture capital relations. So why do software developers, and investors for that matter, so often skip such vital steps?

Microsoft Dynamics NAV – the early revenue acceleration

eriks@atlanticcrossing.com — May 10, 2011 5:26 PM EST

After talking much about how companies may fail to achieve significant sales growth, we turn our attention to a case in which the success was evident.

Tiny accounting software developer PC&C had achieved a solid success with its single-user accounting software PC-Plus. The logical product line extension was a multi-user solution. Unusual for a small development company at the time, PC&C’s owners also decided to explore whether they could make giant commercial strides forward at the same time.

In an unusually fortuitous deal, the PC&C owners found that IBM in their native Denmark could see an opportunity to couple the upcoming client/server-based, multi-user software with their own PS/2 hardware line. And to employ the IBM PC-dealer channel to promote the offering. The multi-user solution was introduced as IBM-NAVIGATOR.

PC&C obviously owned their good fortune to hard work and careful planning, coming off the early success with PC-PLUS. But they also had a bit of luck. IBM Denmark at the time had one person employed, a person with an unusual skill set of deep technical understanding AND remarkable marketing savvy.

Those in the know will recognize this gifted person as René Stockner, later head of PC&C (by then renamed Navision) in the US, and still later VP of Sales & Marketing worldwide, both in Navision itself and later within the Microsoft organization.

Due to his extensive, technical background (he has a Ph.D. in Database Applications and Systems Science) Stockner immediately understood how the software’s architecture and functionality was different from the competition. And he then, uniquely, was able to translate that into concrete benefits for customers, the PC-dealer channel, and IBM itself.

IBM-NAVIGATOR almost immediately became a roaring success in the market. For the first time, customers could have a PC-based, multi-user solution that was robust and secure – something that was not lost upon potential mini-computer buyers (much to the dismay of their salespersons, such as this author).

And the rest, as they say, is history. IBM-NAVIGATOR became Navision outside tiny Denmark, reaching the shores of more than 20 countries before the company went public in 1999. In 2001 it acquired archrival Damgaard Data before it itself in 2002 was acquired by Microsoft in a deal worth some 12 billion Danish kroner (about US$ 2.25 billion using current exchange rates).

Sustaining sales growth and software revenue acceleration

eriks@atlanticcrossing.com — April 30, 2011 2:58 PM EST

So you have finally found a salesperson that can produce real sales growth to accelerate your software revenues. As we examined in the first series of blogposts, that is often very hard to do when you have a groundbreaking software product. Knowledge and understanding of the product are often limited to your own development staff. Prospects, customers, partners, and even non-technical employees all lack the deeper understanding needed to either buy or sell a product that introduces a new way of doing things.

But you finally got over the hump, or crossed the chasm, if you will. Revenue is accelerating, validating many man years of development and hard work. Founders and investors bring out the "hockey stick" – projecting explosive sales growth over the next five years. First we take Manhattan, then we take Berlin, as Leonard Cohen sings.

Two years later, that euphoria is often followed by deep frustration. As it turns out, finding successful salesperson Two, Three, and Four is just as difficult as finding salesperson One. But hadn’t we fixed that problem? One knows his/her stuff now - shouldn’t knowledge transfer be easy? Sometimes, yes. But very often, that "knowledge" isn’t expressly formulated. It might be more of an individually developed, almost intuition-based method that the successful salesperson has implemented in a trial-and-error way.

So the early, or maybe stubbornly achieved, years-in-the-making, success might not be easily replicated to new salespersons. Even if the sales approach can be consciously described, salesperson One might not be very good at teaching or otherwise transferring expertise.

The predictable result is software revenue figures with poor acceleration, year after year – despite expert sales hires and tons of very hard work - leading to deeply disappointed founders, investors, developers, salespersons, and partners. Sometimes careers and/or relationships are destroyed in the process.

But that makes the companies that truly succeed in accelerating software revenue that much more interesting to examine. Stay tuned for a real-world example that led to billions of shareholder value being created.

The worst solution is often the one chosen in software marketing

eriks@atlanticcrossing.com — April 2, 2011 9:21 AM EST

In many ways, the ideal solution for the early commercialization of a truly groundbreaking product might be the team approach, combining the product communicator, i.e. the documentation writer or some other person with product specialist knowledge, with a salesperson.

Together, they may be able to cover the six requirements for software sales success (see posts below). Like the other approaches, this one is not free. Dedicating two headcounts to the sales process is an investment that is often significant for a startup or small company. Among its advantages is that the results, good or bad, should begin to show within 12-18 months. So you might label it “high-investment, quick return.”

In contrast, hiring just one sales professional will carry a lower price tag. The results, however, may not show until after the professional has acquired most of the six key skills. From experience, that often takes 24-36 months – which is a long time to wait to see if something pans out. So it’s a lower investment per month up front, but with a longer time to payoff also.

The real drawbacks in the salesperson-only method are:

That in addition to personnel costs, valuable time is lost while the sales professional learns the target industry and the product’s benefits in detail,
That time is lost if the sales person ultimately is not the right one for the job, and
That an even greater loss is incurred if the conclusion is, after 36 months, that the sales person is the right one, but the product is wrong.

The worst outcome is unfortunately one that is seen quite often: that the founders/investors lose patience with the process and the salesperson after 12-18 months. Firing and hiring a new one is quite expensive. But what is probably worse is that no firm conclusions are reached regarding the product, the way it is marketed, nor in most likelihood the salesperson’s true abilities. The software vendor might have had the right person, but didn’t allow for the complex learning process to unfold.

Or, the software company may go forward, over and over again, trying to find the right person, and the right way to market a product that, worst case, could be an answer in search of a question.

Accelerate software revenue by training the person who wrote the manual

eriks@atlanticcrossing.com — March 23, 2011 10:28 AM EST

Continuing from our last post, solving the problem of having a truly great software product and no revenue acceleration is not an easy task. But the solution may be right under your nose...

Instead of spending enormous amounts of money and efforts trying to find "a great salesperson" whom you'll then spend three years teaching about your product and market, and often fail, you could go in the opposite direction. Recalling our requirements list:

Domain expertise in the prospect’s business to formulate and relate the challenge.
Financial insight to demonstrate ROI if the problem is solved.
Technical insight to understand how the product category solves the challenge.
Product knowledge of the specific product to apply the relevant features, those that benefit the prospect in question, and only those, to the discussion.
The visionary or “evangelical” personality skills to install confidence in the prospect.
The “normal” sales skills to close a deal.

Chances are that, somewhere in the organization, you already have several people who possess 3 out of the first 4 items. Your developers do if your product is truly great - although they may lack some of the ability to relate it in lay terms to the average businessperson. And if you have a user guide or manual, you also have someone who is able to communicate.

I will argue that it's a lot quicker, on average, to teach a technical person with communication skills to sell (i.e. items 5 and 6), than it is to teach a sales professional the product and the market (i.e. items 1 through 4).

History is filled with successful examples. Among those that I'm familiar with, ERP-developer Navision (acquired by Microsoft in 2002, now MS Dynamics NAV) had as their first salesperson exactly the one who wrote the manual. I know that this very successful former CEO will argue that he was selected as technical writer and salesman mainly because the other two founders were better programmers than he was :-) But that would obviously be selling himself short.

In a situation where time to market is of the essence, which is every situation, you could gain valuable time by pursuing this alternate path. I know that every venture capitalist and every headhunter will probably tell you otherwise. But it is truly sad to see promising software companies spend years and years, money and efforts, going through salesperson after salesperson, who "just wasn't good enough" to achieve significant software revenue acceleration.

This alternative path may not be doable or practical for every software company, but it would, at the very least, be worthy of serious consideration.

How a truly great software product may be a problem

eriks@atlanticcrossing.com — March 14, 2011 2:56 PM EST

In the latest blog post below we discussed what it takes to be a good salesperson of a ground-breaking software product. In this context we’ll interpret the term “software” broadly, meaning licensed pc products, server products, subscription-model Software-as-a-Service products, etc.

We concluded that being a good salesperson takes an unusual stack of skills:

Domain expertise in the prospect’s business to formulate and relate the challenge.
Financial insight to demonstrate ROI if the problem is solved.
Technical insight to understand how the product category solves the challenge.
Product knowledge of the specific product to apply the relevant features, those that benefit the prospect in question, and only those, to the discussion.
The visionary or “evangelical” personality skills to install confidence in the prospect.
The “normal” sales skills to close a deal.

So, contrary to one’s immediate thinking, the more competition a product has, the easier it is to sell – assuming a person skilled in sales techniques. Yes, there’s more head-to-head selling, beating each other up on speeds-and-feeds as well as on terms and pricing.

But the educational effort is probably not needed at all as the prospect already understands the product and its benefits well, and he’s probably also able to calculate the financial benefits in terms of ROI (Return on Investment). That broadly takes care of items 1-3 in the list above, and in a very mature market, probably also of item 4.

With only items 5 and 6 left as requirements, the pool of available talent becomes quite large and finding the “right” salespersons is a manageable process. Whereas the pool of talent covering all 6 items ranges from small to non-existent, depending on the product and the size and maturity of the prospects’ industry and/or function.

Hence, a truly great software product that takes care of previously unsolved challenges, and one “without competition,” may indeed present an often insurmountable problem when it comes to finding even “good enough” salespersons.

Whether you call it “Crossing the Chasm” or “Commercialization Challenges” the problem remains very real to thousands of software development companies.

Firing the sales force when the product is the problem

eriks@atlanticcrossing.com — March 8, 2011 8:24 PM EST

In the last blog post we discussed how frustrating it is for founders and investors when the first, and maybe even the second and the third push for commercialization of a software product fail. Frustrating that finding decent salespeople can be so difficult!

That observation would undoubtedly be true if the company in question was selling beer, or even a spreadsheet. The target customer has a good grasp, not only of what he or she is looking for in a product, but also of what the competitive landscape is. So if the pricing and terms are right, the sale is pretty much up to the salesperson in charge.

But that scenario is often far form the one found in smaller, innovative software development companies. They typically try to solve a problem that either hasn’t been solved before, or is currently worked around in some way. So the product may truly have “no competitors” – which most often means that the competition is “some other way of doing things.”

Great – must be an easy sale for a capable salesperson: the answer to all the prospects' prayers, and no competition. How hard could it be to find sales resources good enough for that challenge?

In reality, the challenge is often enormous. First, the salesperson most educate the prospect on the not-yet-established fact that he indeed has a problem/challenge/task that can be met in a new way. Then he must convince the prospect that it is worth solving. Then that the software company’s product will actually perform the way claimed, and that the company will still be around some years down the road. Only then, and finally, may the salesperson close the deal if the price and terms are right.

And, all these parts of the overall challenge assume that it indeed IS a great product – otherwise, forget it…

So what are we really asking for in a “good enough” salesperson?

Domain expertise in the prospect’s business to formulate and relate the challenge.
Financial insight to demonstrate ROI if the problem is solved.
Technical insight to understand how the product category solves the challenge.
Product knowledge of the specific product to apply the relevant features, those that benefit the prospect in question, and only those, to the discussion.
The visionary or “evangelical” personality skills to install confidence in the prospect.
The “normal” sales skills to close a deal.

These salespeople do exist, but it’s pretty evident that they don’t grow on trees. And that they probably command a high price in the market. All still assuming that the software development company has a truly great product.

A software sales force that isn't will last 9-18 months

eriks@atlanticcrossing.com — February 26, 2011 12:12 PM EST

So what happens next when the software revenue acceleration doesn't happen - even after hiring supposedly great, and often highly paid, sales people?

Invariably, the sales force that doesn't sell is let go. They just weren't good enough, in spite of their glowing credentials. And this time the software company decides to do everything in a top-professional way. No more hiring out of the founders' or other key employees' networks. A real executive recruitment agency is retained - to match the superior qualities of the software product.

After a couple of months where the sales effort is on standby, the new salesperson(s) arrive. The search and the salesperson both carry expensive price tags, so there's light at the end of the tunnel.

By now, we all know that, most likely, history will repeat itself. And the software revenue growth is still moderate at best, even after several iterations.

A lot of us have been there, done that. Some of us, like me, have been there more than once, repeating our own failures.

So what is the solution? You're welcome to chime in with suggestions and/or your own war stories in a comment.