The Six Battlefields: why your best feature might not matter.

In 2018, the Royal Society of Chemistry’s Analytical Methods Committee published a guide to good practice in buying analytical instruments. It does not recommend choosing on headline specifications alone. It treats a purchase as an assessment of an instrument’s specification and performance against “a clearly defined analytical role”, and asks purchasers to look at the intended application, the supplier’s support, consumables, maintenance, installation conditions, operator training and acceptance criteria, among other factors. It recommends evaluating instruments with test samples where appropriate, because performance against a manufacturer’s specification and performance against your own application are two different tests. The question is whether an instrument is fit for the use it is bought for.

If you sell scientific or technical products, that guide describes the room your proposal will be read in. It also explains a familiar disappointment. Your system measures more precisely, runs faster or does more, and the customer still chooses the other one.

That does not have to mean they misunderstood your technology. Your product may simply have been better at something they did not need, while the alternative was good enough at what they did. Mercuri International’s Six Battlefields framework is a useful way to examine that gap, as long as you read it from the buyer’s side.

An HPLC system at the FDA’s National Center for Toxicological Research. US Food and Drug Administration, public domain. Source

What are the Six Battlefields?

The Six Battlefields method was developed by the sales training company Mercuri International. Its white paper and product sheet set out a comparison between three things: a customer’s requirements, your offer and one specific competitor’s offer. It is a commercial methodology, and its value lies in the questions it makes you ask.

Mercuri gives the six positions combative names. The names below are theirs; the descriptions read each position from the buyer’s side.

Battlefield	What it describes	The question worth asking
1. Expand your battlefield	A strength you have that the customer does not currently see as necessary	Is there a real, overlooked consequence that makes this relevant?
2. Shoot from all angles	A strength the customer needs and the competitor cannot match	Can we demonstrate the advantage under the buyer’s actual conditions?
3. Reinforce the borders	A limitation of yours that appears unimportant to the stated requirements	Is it genuinely harmless, or have we misunderstood the requirement?
4. Make sure competitor attacks miss their mark	A competitor’s strength the customer may not need	Does that feature change an outcome the buyer cares about?
5. The frontline of the competition	A competitor’s distinctive strength that meets a real customer need	Can we meet the need another way, or should we acknowledge the gap?
6. Attack your competitor’s borders	A competitor’s limitation that may affect the choice	What evidence can the buyer examine without relying on insinuation?

The descriptions are paraphrases, not a reproduction of Mercuri’s diagram; the original white paper has the complete model.

The framework also covers requirements both suppliers meet, and ones neither does. Those still need evaluating; they just leave no room for a claim of superiority.

Look at the six positions together and most of them turn out to be about something other than which product is better. They ask whether a difference should matter at all.

The advantage nobody asked for

The first battlefield is the most revealing. Your system covers a wider range of experiments than the buyer’s requirements mention. You see a valuable capability. The buyer sees extra cost and complexity.

Either of you could be right. The buyer may be overlooking a real future need, such as a second method coming in-house or a change in sample volume, and you can help them test that against their own plans. Or the capability is irrelevant to a stable application, and the honest move is to accept the answer. Mercuri describes this battlefield as expanding the customer’s view of its requirements, which is legitimate when it uncovers a real requirement and manipulative when every unneeded feature becomes a problem the customer has yet to be persuaded of.

A more useful question than How can we make the buyer want this? is What would actually change in their work if they had it?

How do you prove a competitive advantage?

The second battlefield is plain differentiation: the buyer needs something, you can provide it and the competitor cannot. Proving that competitive advantage means finding evidence for each part of that sentence. Your product has the characteristic; the buyer’s application requires it; and the competitor has no equivalent route to the same result, through another configuration, method or service.

In technical markets, the demonstration carries more weight than the superlative. A sensitivity figure measured under one set of sample conditions may not hold under another. A throughput claim can leave out sample preparation, re-runs and data processing. An integration can sit on a feature list and still take months to implement.

This is where the RSC guide’s two tests matter to you as a supplier. An application note with its method, conditions and limitations intact can persuade more than a bigger number on the homepage. So can a candid conversation about what the instrument cannot do.

Weaknesses that do not matter, and ones that do

The third and fourth battlefields mirror each other: a gap of yours that may not matter, and an extra feature of the competitor’s that may not either. These differences tend to dominate presentations because they are easy to compare. A rival handles a far larger batch, but the laboratory’s volumes are modest and predictable. If both systems meet them comfortably, arguing over the maximum distracts from the cost, maintenance and staffing of running either one.

The catch is that you do not get to declare a weakness irrelevant on the buyer’s behalf. A limitation that seems harmless today can matter once the team changes its method, and a software restriction that suits one researcher can be unacceptable to the institution’s IT team.

Ask the buyer for reasons for each requirement. We do not need that feature is an answer. So is We might need it in two years, and that one deserves a closer look before it becomes a requirement.

Preparing a plant sample for HPLC at a USDA research unit in Oxford, Mississippi. US Department of Agriculture, public domain. Source

When the competitor really is better

The fifth battlefield tests your honesty. The competitor has a distinctive capability the customer needs, and the temptation is to change the subject: lean on unrelated strengths, question how often the capability will be used, or hint that the rival’s specification is inflated.

A requirement can deserve testing. Buyers inherit specifications from an old tender, a vendor presentation or another laboratory, and it is fair to ask where one came from. But if it survives the question, and the other product supports the sample type, workflow or operating condition that yours does not, acknowledge the gap.

You can still investigate an alternative workflow, a different configuration or the real cost of the alternative in time and effort. If the competitor remains the better fit, the opportunity may not be yours, and the gap may belong on your roadmap.

The sixth battlefield, the competitor’s weaknesses, asks for the same discipline. Help the buyer understand credible risks, but do not imply that a rival is unreliable, unsupported or unsuitable without specific, current evidence. Suggest that every shortlisted supplier demonstrates the relevant capability against the same requirements. That is more credible than a whispered warning, and more useful to the buyer.

The decision has more than one owner

The framework talks about the customer’s requirements as if they were one list. In a laboratory or a deeptech company, several people hold different and reasonable definitions of value. The scientist wants dependable analytical performance. The laboratory manager cares about scheduling, training and uptime. Procurement needs a defensible process and a manageable contract. Whoever signs off the budget needs confidence that the equipment will serve the organisation’s purpose, and quality or regulatory specialists may add requirements of their own.

The RSC guide is written for three of them: the analyst who recommends the equipment, the purchasing officer who negotiates the contract and the senior manager who authorises it.

These are pieces of one decision, and a single polished pitch will not answer all of them. A specification that delights the end user can add to the maintenance burden; a good price can hide costly consumables; an established supplier can feel safer than a better alternative. A competitive comparison is only a start: you also need to know who decides, who carries the consequences and which requirements cannot move.

Preparing molecular tests for poliovirus at the US Centers for Disease Control and Prevention. CDC/Holly Patrick, public domain. Source

Differences you cannot negotiate away

In regulated settings, the line between a preference and a requirement is sharper still. A research-use-only in vitro diagnostic product is not interchangeable with one legally marketed for clinical diagnostic use. The US Food and Drug Administration’s guidance on research-use-only (RUO) and investigational-use-only (IUO) products ties those labels to intended use and stage of development. They are not badges a salesperson can recast as a minor feature difference. That is a US example; other jurisdictions set their own rules.

Other requirements are just as binding without being regulatory: compatibility with validated methods, cybersecurity obligations, access to data, dependable service coverage. A superior feature cannot make up for missing a threshold like that, so treat these as lines to check before any negotiation.

Start from the buyer’s work

A better competitive conversation begins with the buyer’s work. Which samples will the team run, and under which methods? Which performance measures are critical, and how will they be tested? What counts as an acceptable result? What changes during installation? Who maintains the equipment, trains new users and pays for consumables? Which limitations are acceptable, and who can accept them?

With those answers, the comparison sharpens: some capabilities are essential, some useful, some impressive and unneeded. A requirement missing from the original specification can be added openly and assessed for everyone; one with no connection to the work can be set aside, with the reason written down. It also changes what you ask after a loss. They chose an inferior product becomes What did they need that we did not recognise, prove or provide?

The framework has limits. It looks at differences between offers in one buying decision, so it will not tell you whether a market is attractive, how rivals will respond to a price change or how to run your organisation. And its vocabulary invites the wrong instinct. A buyer is not a battlefield to be conquered.

Read from the buyer’s side, it comes back to the question behind the RSC guide. Before you argue that your product is better, ask: better for what, for whom and under which conditions?