Building software is hard: successfully bringing a new software product from conception to market is harder. Building a successful software company that develops and markets multiple software products is harder still.

The days of ‘build it and they will come’ are over. Simply creating a great piece of software and waiting for the customers to knock on your door no longer works – if it ever did.

Nobody should ever think that building software is easy: some small application may indeed be easy to build, but meaningful software applications and platforms are extremely complicated things to create. However, building software is at least a reasonably well-defined task, which isn’t true of many of the other things that need to be done. Indeed it isn’t even clear what needs doing.

Creating a successful software product, and building a successful software company, involve a myriad of other activities that are far less easy to define and put boundaries around. The first of these is just deciding what it is that should be built. But perhaps the most difficult task of all is bringing all these activities – well-defined, poorly defined and never defined alike – into alignment so that they move towards a common goal. This is akin to an exercise in formation flying in which the individual pilots have their own opinion on where they should be going. The bigger the company, the more complex the environment, the more difficult the task.

Still, every seven years or so the industry comes up with a new paradigm which allows small pieces of software, sometimes written by one person, to advance the ecology itself. A few become millionaires while many have walk on parts.

Apps are the latest iteration of this cycle. Even the word application is too big for the small pieces of software we download and install on our phones, tablets or other gadget. iOS Apps, Android Apps, Facebook Apps and now Apps for televisions. We’ve been here before, last time it was the web, and before that Windows, before that MSDOS and before that Apple IIs and TSR-80s.

That is the way the software industry is: high growth, high failure, dynamic, loved of politicians and venture capitalists. The barriers to entry are shockingly low: as long as you can code, have an idea and can live on credit cards for a few months you can play too.

Yet the barriers to success are extremely high. Just because you can play doesn’t mean you will succeed. Infant mortality is shocking. And we repeat the same mistakes over and over again.

Perhaps the biggest mistake is to believe that if we build it they will come. Those days are over, if they ever existed in the first place.

Successful software companies know about marketing, product strategy, roadmaps, customers and many other things. In fact, successful software companies have a lot in common. There are, just as in code, patterns of success, patterns of business.

Over the last eight years I have collected many of these patterns. Often identifying and writing one pattern leads to the discovery of several more. All patterns are available for download from my website - www.allankelly.net - and 36 were published as a book in early 2012, Business Patterns for Software Developers. In the rest of this piece I’d like to discuss a few of the patterns and how they fit together.

Same Customers, Different Product

Once your business has a relationship with your customers they will trust you, satisfied customers have a positive impression of your company and your. Sales staff already have a relationship with the customers and the company is in a good position both to understand their needs and to supply them

Modern consumers are faced with a bewildering number of brands and product variations. Choosing a trusted brand is one way to navigate the jungle.

Nor is it just individual consumers who return to existing suppliers and brand. Business customers find it easier to buy from suppliers they have worked with before; and the promise of a compatible product is a big plus.

So rather than continually seek out new customers for the product you have consider the customers – rather than your products – as the asset. Expand your product offering so you have more products to sell to your existing customers. Do this by focusing on the customer

This approach has the additional benefit that by deepening your relationship with the customer not only will you sell more, the customer will get a better solution and the relationship will be strengthened further.

Some sales will build directly on the products you have already sold – sometimes called "plus one" sales: more licenses for the same software, upgrades to enhanced versions new versions of existing software, and add-on modules are all possible. The next sale could be a service: support contracts, training and installation are highly applicable to existing products.

In fact, when you think about it there are actually four possibilities for sales, as shown in Figure 1.

Figure 1 - Four growth options

Different Customer, Same Product is probably the default position of most companies – "We have a product, we need to find more customers!" Yet making sales can be very expensive in itself, customers might already be using a competitor product or new sales channels might be needed to reach new customer groups.

Same Customer, Same Product is normally found with consumable products - Gillette razor blades or HP ink jet cartridges but it could be software upgrades, I must have bough five or six copies of Microsoft Office in my life.

When products last, like software, ways need to be found to entice the same customer to buy more of the same product. If the customer is a large organization then it might be possible to move from one group within the company to another selling licenses as you go. While the paying customer might be the same the end user will be different.

For home users it might be an upgrade cycle – new OS, new PC, new Office version. Although even this might be considered a Same Customer, Different Product model depending on how you view upgrades.

Diversification - Different Customer, Different Product – is inherently risky because it is, in effect, establishing a new business. Sometimes companies pull this off, like the way Caterpillar extended its brand into clothing. Perhaps more often this is one jump too many, look at the way many tobacco companies tried to move into food only to retreat later.

Same Customers, Different Product view customers, not the product, as the asset. Rather than sell an existing product to new customers you sell existing customer a new product. When done well this can be highly effective at low risk. Think of Oracle building on the database customer base to sell enterprise software and middleware, or the IBM Rational developer toolset.

Nor does the different product need to be your own product. You could use the patterns Value Added Reseller or White Label to offer products to your existing customer base under your own name. Offering another product as a complement to your own can reduce costs and eliminate competitive tension – something described in the pattern Complementor Not Competitor.

Of course it is sometimes difficult from the outside to tell what a company’s strategy actually is. Consider Dell’s recent acquisition of Quest Software. This might be a diversification move – Different Customer, Different Product – or attempt to sell software to existing hardware customers, or possibly vice versa.

Homogenous and Segmented Customers

In the beginning many companies assume – by conscious decision or through naivety – that all customers are Homogenous. Indeed, this approach has some advantages: it reduces time to market entry and therefore costs. By entering the market it puts the company in the best possible position to understand what customers want and what is possible.

A homogenous customers approach has worked well for the likes of Microsoft – with MSDOS – and even Google’s early search product. If you consider all customers to be the same then one product is all you need to enter the market – thus keeping costs down and time short.

In the beginning companies may simply lack an understanding of potential customers. Sometimes the best way to gain knowledge about customers is simply to get into the market. However, sooner of later companies start segmenting their customer base so to serve customers better, and to extract more money.

Segmenting makes sense: customers are not homogenous. Different customers want different things, some value speed or ease of use, others value low price. Many a software development team has been lead astray by focusing on the needs of one customer too closely and producing a product which has little, or no, use to others.

The trick is to use Customer Understanding (another pattern in the book) to segment customers into different groups and address the needs of each group separately. Segment groups are typically defined on discernable attributes and characteristics that allow differentiation of one group from another; another approach is to segment on the tasks to be performed. Either way, working with definable groups avoids generalizations that do not accurately describe any one group.

You may choose not to meet the needs of some groups if doing so would compromise the needs of another. When resources are limited is it better to target resources than spread them thin. Segmenting your customers will allow you to segment your market. As you decide which customer groups to serve you will define your market position relative to your competitors. You are also deciding whom you will not serve. In some cases you may need to extricate yourself from some existing group to pursue your new targets.

Segmentation can help avoid situations where more attention is paid to the customer who shouts loudest. Strategy is as much, or even more, about what you will not do, whom you will not serve, as it is what you will do and whom you will serve.

Those you decide to serve will benefit because they will get a product that more specifically fits their needs. A deliberate choice not to serve some groups allows you to serve others better. Sub-dividing your customer base will also help you spot opportunities to serve customers better.

But customer segmentation can go too far. While for customers the sheer choice of products on offer under the same brand can be overwhelming. Last year I needed to buy a new car GPS system, confronted with what seemed like several thousand products on Amazon I stuck with the brand I knew, Tom-Tom, and bought the cheapest product rather than spend time considering the merits of each product. (True, I momentarily considered a Garmin but was again overwhelmed by product choices.)

More dramatically contrast the approach of Nokia and Apple to the phone market. Nokia markets an amazing range of different phones. Conceivably there is a Nokia for every customer segment – indeed there might well be more than one. There comes a point were the costs of such a diversified product range become self-defeating.

Now consider Apple’s approach to the same market: there is one. There was one iPhone to start with and although Apple continues to offer older versions, and some Simple Product Variations (another pattern) there is essentially still one iPhone.

Apple too have segmented the market but having done so they decided to only address the premium smart phone market. Even here segmentation is limited. A quick look at Nokia’s website one day in June 2012 showed four different Lumia Smartphones, six other smart phones and at least a dozen simpler phones.

On the face of it addressing a segmented customer base with a range of products targeted at each segment should be a more effective approach than homogenous customers. But as the Apple v. Nokia story shows things aren’t always that simple.

Sequences and competitive advantage

Patterns don’t exist in isolation. If one company faces a problem and solves it using the same pattern as another it is quite likely to find the next problem is also quite similar and the corresponding solution is also similar.

Figure 2 shows one such pattern sequence. The start of this sequence is the desire to reach more customers. After segmenting the customer base the company engages Simple Product Variations pattern – maybe a range of colors products al la the iMac or iPad covers – and Core Product Only. (While Core Product Only works in some domains it doesn’t have great history in the IT world. Consider Microsoft Works, it has most of the Office functionality most users need but has never sold well. Even Linux seldom appears on its own, it is usually the core of a distribution or baked into a product like Android.).

Consequently the company has a Product Portfolio. In order to reach the different customer segments – and limit competition with itself – the company then engages a variety of distribution channels.

While one pattern may address one set of problems right here and now in resolving the question new issues arise. Thus patterns tend to lead to other patterns – a pattern of patterns usually know as a pattern sequence.

Figure 2 - Pattern Sequence for reaching more customers

That different companies follow the same patterns and same sequences isn’t a bad thing, in fact it validates the whole approach. For many companies the product, not the process or organization, is the competitive advantage. Why reinvent the process wheel when plenty of others have already shown how to play the game?

That said, for some reinventing the wheel is the competitive advantage. The way the product or service is delivered, or the way the company works, could well be the things that make the company a winner. The actual product may be very similar to the competition but delivery very different. For these companies business patterns serve not as a template for what to do but rather a description of what not to do.

Finally

The software industry, indeed the wider technology, industry doesn’t stand still. As the patterns were re-edited for Business Patterns for Software Developers it became clear that some updates were needed.

For example, Nokia was sited as an example in several patterns. In some case the pattern and example still held. In others, the events at Nokia lead to new insights into the business of technology.

A year after publication, nearly two years since the most of the text was complete the patterns still stand up. I believe the patterns themselves will stand the test of time but I expect some of the details and examples will change. I also expect that using this common languages for much of what our industry does will allow software developers and entrepreneurs to come up with new variations, new combinations and completely new approaches.