The biggest mistake marketing people make is failing to appreciate the strength of a defensive position.

The glamour of offensive war and the thrill of victory makes the average marketing manager eager to pick up a lance and go charging off at the nearest entrenched competitor.

The paradox is the fruit of victory. If you can win a marketing battle and become the leading brand in a given category, you can enjoy that victory for a long time. Simply, because you can now play defence, the stronger form of warfare.

— Al Ries and Jack Trout, Marketing Warfare, Chapter 3

In the military, the numbers are so important that most armies have an intelligence branch known as the order of battle. It informs commanders of the size, location, and nature of the opposing force.

When two companies go head to hear, the same principle applies. God smiles on the large sales force. Given virgin territory, the company with the larger sales force is likely to wind up with the larger share of the market.

Once the market is divided up, the company with the larger share is likely to continue to take business away from the smaller company. The bigger company can afford a bigger advertising budget, a bigger research department, more sales outlet etc. No wonder the rich get richer and the poor get poorer.

Is there no future for the small competitor? Of course there is, which is one reason why this book was written. “The art of war with a numerically inferior army,” said Napoleon, “consists in always having larger forces than the enemy at the point which is being attacked or defended.”

There’s the illusion, of course, that over the long run, the better product will win. But history, military and marketing, is written by the winners, not the losers. Might is right. Winners always have the better product, and they’re always available to say so.

— Al Ries and Jack Trout, Marketing Warfare, Chapter 2

At Austerlitz in 1805, perhaps Napoleon’s biggest military success, he didn’t have the big battalions. What he did have was manoeuvrability. He tempted the Austrian-Russian alliance to attack his right flank. Then he manoeuvred his left flank to strike at the enemy’s weakened centre. The result was almost total victory. Rapidity of movement was the key to Napoleon’s success. His troops, he claimed, could march 2 miles to the enemy’s 1. “I may lose a battle,” said Napoleon, “but I shall never lose a minute.”

What about marketing? How many minutes, hours, days, and even weeks are lost in planning, in researching, in test marketing? Precious time often wasted. And the result: another defeat snatched from the jaws of victory.

— Al Ries and Jack Trout, Marketing Warfare, Chapter 1

Marketing people traditionally have been customer oriented. Over and over again they have warned management to be customer rather than production oriented. Ever since World War II, King Customer has reigned supreme in the world of marketing.

But today every company is customer oriented. Knowing what the customer wants isn’t too helpful if a dozen other companies are already serving the same customer’s wants.

To be successful today, a company must become competitor oriented. It must look for weak points in the positions of its competitors and then launch marketing attacks against these weak points.

In the marketing plan of the future, many more pages will be dedicated to the competition. This plan will carefully dissect each participant in the marketplace. It will develop a list of competitive weaknesses and strengths as well as a plan of action to either exploit or defend against them.

There might even one come a day when this plan will contain a dossier on each of the competitor’s key marketing people which will include their favourite tactics and style of operation (not unlike the documents the Germans kept on Allied commanders in World War II).

— Al Ries and Jack Trout, Marketing Warfare, Introduction

The gap between promises and results is widespread and clear. The gap nobody knows is the gap between what a company’s leaders want to achieve and the ability of their organization to achieve it.

Everybody talks about change. In recent years, a small industry of changemeisters has preached revolution, reinvention, quantum change, breakthrough thinking, audacious goals, learning organizations, and the like. We’re not necessarily debunking that stuff. But unless you translate big thoughts into concrete steps for action, they’re pointless. Without execution, the breakthrough thinking breaks down, learning adds no value, people don’t meet their stretch goals, and the revolution stops dead in its tracks. What you get is change for the worse, because failure drains the energy from your organization.

Repeated failure destroys it.

– Bossidy and Charan, Execution: The Discipline of Getting Things Done, Chapter 1

The success of XP has reawakened interest in software development methodologies. The fact that it has become popular without large organizational backing or promoting represents a large shift in the software development community.

Although you could easily be misled into thinking that XP is the ultimate approach to software development, there are many competing approaches out there. Sooner or later another approach will catch the attention of the software development community and XP will become just another way to develop software. Personally, I think that this can not happen soon enough, because the hype surrounding XP hinders reasonable discussions about where it works and how to apply it.

Overall, though, any successor or alternative to XP will have to be superlative to supplant it in teams that have a lot of experience in using XP. This is not to say that XP is the end of the line for process evolution, just than XP is very captivating for a lot of people. It is a development process that people actually enjoy using.

– Pete McBreen, Questioning Extreme Programming, Chapter 21

There are two things that really strike me about developers who use Extreme Programming: 1) They really like programming, 2) They really like working on XP projects.

Although these observation could be dismissed as being obvious, that would be a mistake because they reveal an interesting aspect of XP – the
fact that XP considers developer enjoyment of the process important.

No wonder, then, that developers are attracted to XP, It values what developers consider to be important. It also taps into the pride in work that most developers share. At least half of the practices are intended to address code quality and maintainability. Couple this with iterative development leading to small releases so that developers can see their code going into production and it is easy to see why developers are attracted to XP.

– Pete McBreen, Questioning Extreme Programming, Chapter 20

Many projects have gotten into trouble in the past because the developers have tried to build a completely general, optimal solution. Indeed, a common joke is that some programmers would rather build an application generator (and use it to build the application) rather than simply build the application. Most of the time this is an obvious case of what Kent Beck called false feature rich, and the obvious solution is to ask the developer to do the simplest thing that could probably work.

The real problem is that the idea of build generic, optimal solutions is really seductive. After all, what could be more effective that writing a simple report generator and using it to produce the reports? It will obviously be much faster than having to develop 20 different reports.

Unfortunately, it is never that simple. All too many projects have wasted lots of time and money building a simple bit of generic infrastructure, so to address this risk Extreme Programming has an explicitly saying to warn against this mistake.

– Pete McBreen, Questioning Extreme Programming, Chapter 19

I have to question the sanity of any organization that would assemble a team of novices and then claim that it is playing to win. There is a subtle mismatch between word and deed. Regardless of the software  development methodology approach selected, a team of novices is going to struggle and have a much lower probability of success than a more
experienced team. An experienced coach might be able to mitigate the worst of the risks for a small group of novices, such that they quickly learn from their mistakes, but my guess is that it would be better to have the coach take a month or two to train the novices before starting the project.

Yes, you could plausibly suggest that the collaborative practices of XP would allow a team of novices to learn faster than a traditional team of novices, but that avoids the question of why use a team of novices in the first place. Low-experience teams are hazardous to the health of any project, especially if the team members are convinced that because they know objects, design patterns, UML, and Java they are bound to be successful. Knowledge of these things helps, but there is a lot more to a successful software development team than a bunch of individuals who happen to know some esoteric technology.

– Pete McBreen, Questioning Extreme Programming, Chapter 18