Some software entrepreneurs, when asked, say that their market is whoever buys the box. Some have a clue about who their customers are, but they really do not know well. Some others have a razor sharp knowledge of their market and carefully drive their application development: they know their market positioning. Market positioning is not something that happens, it is a choice that should drive your development efforts. So, it is worth knowing something about. In this post I will even resist the urge to explain where Viney@rd is positioned within the market, so keep reading safely.

First, what is market positioning? The best way to understand it is to think to the market as the shelves of a library. Each shelf covers a topic or an author. The books in the front rows are more accessible than those in the back rows. The books on the higher shelves are more difficult to reach than those at eye level. People looking for a book will locate the appropriate shelf, then they'll likely grab a book on the front row. If the shelf is located 3 meters high, chances are they'll renounce getting it, unless they exactly need that book or a book from the top shelf.

Some people will pass by and casually spot an interesting title and they'll get it. Some others will require a specific book and will browse through the entire library to find it.

The key point, anyway, is that a book (that is, a piece of software) can stay on one shelf. There's nothing like a "matrix oriented shelf".

So, let's start from the last point. Some of you will say that some package is good at doing two or more things. Penthao, for example, contains ETL, reporting, ad hoc query etc. Open Office is good at doing word processing, spreadsheets, database etc. Wrong, Penthao lies among the Business Intelligence suites with Business Objects, Microstrategy, Cognos etc etc; the one thing it does is organizing the process of consuming business information. Open Office is an office automation suite, it organizes the way an information worker relates with knowledge and fellow workers. Even if, technically, a piece of software does more than one task, it will be perceived by the market to fit into a single category. This happens because people define things by comparing them, so anything is something else with some differences (my wife is used to say that a rabbit is cat with long ears and a short tail, but my wife is graduated in social sciences, not biology …).

The library of software, anyway, is organized in two large rooms, the consumer and the business markets. These are very very broad distinctions. Some find difficult to draw a clear line among the two but I use a definition that appear to be sensible, at least to me. A consumer software addresses the problem of an individual or her family, a business software addresses the problem of a business entity, no matter how small it is. The consumer market has looser requirements (if a video game crashes, nobody is hurt and no money is lost …) with low unit costs, usually low unit margins and high volume. The business market is more varied, ranges from few bucks invoicing softwares for professionals to multimillion, high end, enterprise management systems. Often it has higher margins and must comply to much more compelling standards.

First choice: will you build your software for consumer or for business market?

From now on I will cover only the business money because a) it is the one I really know b) it is where the real money is. In my opinion it is the place where even a small or a micro company can prosper because it requires volumes much lower than those of the consumer, Userscape, SmartBear, Balsamiqor FogCreek are living examples of this.

So you enter the business room and you will soon realize that the vast majority of the books is in English. There are few shelves of books in foreign languages and few books which are present in the library in more than one language. It's no use to say that the vast majority of the readers picks books in English. Translation: Microsoft Windows rules. All the other OSes have their role in the market but they occupy a niche. This is not going to change in the near future. I know that I'll be flamed for this, but it's a fact of life. So, the operating system is not really a choice, while being multi platform is a plus, not building for Windows imposes heavy self limitations.

The actual choice though, is related to what is called "ecosystem", that is, the complex of business software and architectural building blocks that revolve around one of the big players. The ecosystems worth considering are:
Microsoft (AX/Nav - SharePoint - Office - SQL Server - .NET)
Oracle (Oracle Apps/One world - The Database - Hyperion - chunks of Linux)
SAP (The ERP - Netweaver - Business Objects)
There are also minor ecosystems which feature a less comprehensive coverage of the business world like:
IBM (websphere - db2/Informix - iSeries and X worlds)
Open Source (a blob of technologies revolving around Java and the LAMP stack) and few others.
To be complete, I must say that there are technologies which span through all of these ecosystems (like Adobe, the MS Office application or the rising Google) but are rather specific and not really relevant at the moment of this writing, despite all the hype which surrounds them.

The ecosystems imply that, in a business environment, an ecosystem tend to dominate the others; that is, the "best of breed" approach is always less and less popular because it requires interfaces among systems, which imply costs and complexity.

The ecosystems are not perfectly equivalent despite the marketing claims, so you have to pick carefully because your choice will focus you toward the referring market. Even the most general applications have a bias toward it. For example, if you build a LAMP stack based application for meeting rooms management, you may feel to be completely independent. In a business environment, anyway, you'll be asked first to interface your data with the local ERP HR module to have evidence on the employees data of the meeting usage, then with MS Outlook to coordinate reservations with meeting invitations, then with the accounting module to automatically post meeting costs etc. At the end, the market will ask you to have your PHP created screens inside the ERP, and you'll find yourself locked within an ecosystem, even if you did not mean to. The more the app you are creating is complex and the less it can be easily ported to other environments, the more you'll be compelled to chose a reference ecosystem.

Second Choice: which ecosystem do you pick?

So far you have chosen a shelves row in the library, now you have to find a position to place your book. Of course, the books on the front rows are spotted much easily and chances are that they will be the most read. Nobody picks that dusty gray book in the back row, unless she needs exactly that one.

That is, your software may address a wide range of requirements, standing together the other players on the market, or it can focus on a specific niche with specific requirements, becoming known only to niche players. From a business perspective, both solutions are viable and can lead to a sustainable cruise speed. What you have to do, anyway, is rather different. In the first case you'll need to tie, more or less, the other players in most of the features and to be outstanding in the feature which differentiates you. In the second case you need to concentrate on your niche and to adhere closely to your (potential) customers requests. The mindset, the competency, even the people you need are different.

Third Choice: do your software addresses to a niche audience or to the broader public?

The books on the higher shelves are, of course out of reach of many, none the less few people still read them. Even if your software is addressed to a niche audience, chances are that there are going to be different price ranges. You have to chose the tier in which your software will lay. Obviously, the low market tier will target lower unitary margins and higher volumes, the hi-end market will feature few sales to few key customers. As explained before, you need to work differently to address the two segments. Be aware that there is a point not obvious about this. At lower ends you usually end up talking about features, at higher level what matters most are the concepts inherently embedded within the software; that is, how the business processes are influenced by the use of the software (no matter if there is auto completion for fields or not).

Fourth Choice: does your software addresses the low, the mid or the high tier of the market?

So, simply writing down the four questions and answering them clearly in one or two sentences may well help you decide where to go with your software.

Did you do this kind of analysis before starting up your company? Do you have any experience on this kind of planning? Let me know.