Use Competitor Research to Build an Offer Worth Testing

Define the buying situation, then compare the complete offer

Start with the customer's job, not the competitor's homepage. In the example, the retailer wants to serve first-time buyers of a manual coffee-brewing setup. Their need is getting a suitable set of items and enough guidance to produce an acceptable first brew.

That description changes which alternatives belong in the comparison. A shop selling individual coffee bags matters differently from a retailer selling a complete starter kit. A local store offering a demonstration may matter even with an unsophisticated website. Keeping existing equipment and postponing the purchase is itself an alternative worth including — it explains why a customer might never enter the category at all. Do not infer importance from a polished page or a large following; those signals might help you investigate distribution, but they do not establish how many relevant customers buy, whether those customers succeed, or whether the offer makes money.

Once the buying situation is clear, compare offers at the level of their full conditions, not their headline price. Record quantity, specification, delivery region, delivery charge, eligibility and the conditions attached to any service. If a price only applies to a first subscription order, keep that condition. If a demonstration requires booking, record the booking requirement.

A headline price is one field in an offer record — not the whole offer.

For setup help specifically, inspect the actual scope. A downloadable guide, an email reply and a scheduled call ask different things of the customer and the business — "support included" is too vague to make offers comparable. Add an evidence-status column — confirmed, not stated, conflicting, or inaccessible — so an unreachable page is never mistaken for proof that a service doesn't exist. Keep a link and a check date for every material field; sellers change terms mid-project, and an old promotion should never get compared against someone else's current standard.

Use structured extraction to make the comparison inspectable

A spreadsheet and a careful read are enough for a small comparison. Automation earns its place when the same fields need collecting repeatedly across a defined set of pages — and only if it is given a specification before it touches a single website: which pages may be inspected, which fields to return, what evidence must accompany each one, and how to represent information that simply isn't there.

Keep the observed passage, the extracted value and the analyst's interpretation as separate elements, so the route from page to decision stays visible. A record might hold the alternative's name, URL and inspection time; the customer situation and offer scope; the advertised promise and the passage that supports it; price, currency and quantity; delivery, eligibility and recurring commitments; and the reviewer's open questions.

Validate the structure automatically — a missing currency, an invalid date, inconsistent units. Then verify the meaning by hand. A perfectly formatted price can still come from the wrong product variant; a correct number can still omit the subscription requirement that makes it relevant. Where a landing page and a help page disagree, record both versions and investigate — asking an assistant to pick the more plausible one erases exactly the uncertainty the research exists to expose. Parallel research can help when several independent alternatives need checking at once, provided every researcher works from the same specification. More agents collecting the same page do not create independent customer evidence, and retrieval should only ever touch material you're permitted to access.

Find out which differences customers actually care about

The comparison shows what competitors advertise. It does not show what your customer values enough to act on — that requires independent customer evidence: recent enquiries, approved interviews, observed shopping tasks, and the reasons people gave for choosing or rejecting an option.

In the coffee example, a customer might be uncertain about choosing the right grind, assembling the right components, or understanding the brewing instructions. Those are different problems, and the store needs to know which one actually blocks progress versus which can already be resolved with information it has. Ask about the last relevant experience: what did the person try, what did they use instead, which step was hard, what helped them decide?

Avoid treating polite enthusiasm as demand. Someone can like the idea of setup support without wanting to book a call; a buyer choosing a gift may care more about a clear explanation for the recipient than personal help for themselves. Show a concrete description — package, price, eligibility, next step — and ask the person to describe what they believe is included; a misunderstanding about an "unlimited" promise is a finding to fix before launch, not after.

A gap in a comparison table alone is not an opportunity.

The connection has to be explicit: an alternative leaves a question unresolved, customers describe a real consequence of that gap, and your business has a plausible way to help. Absent that chain, a difference on a competitor's page is just a difference.

Model contribution and capacity before you test

An offer can get more attractive while getting less valuable to deliver. Write the promise with boundaries before pricing it: who is eligible, what's covered, how help gets requested, when it's available, and what sits outside scope — define the exceptions before they become a queue of disappointed buyers. Have the people who will actually deliver the service review it: can the needed information be gathered before a session, what happens with different equipment, who owns a product fault?

Then build the economics with finance and operations, keeping assumptions separate from observed costs. In a deliberately simplified illustration, a current offer leaves €20 contribution per accepted order; a proposed bundle leaves €17 after its added contents and service, assuming the same eligible audience and the same acquisition spend.

Ten more orders and €130 less total contribution under those assumptions. At €17 per order, the proposed offer would need at least 118 accepted orders just to match the €2,000 baseline — and at that volume the margin over the comparison is only €6, thin enough that a different return rate or a little extra staffing could reverse the result. Capacity is a separate constraint again: if a session runs ten minutes, twelve completed sessions already consume two hours, before booking administration, missed appointments and follow-up. Estimate take-up, then measure it — don't assume everyone books, or that almost nobody does.

Write the hypothesis so a result could weaken it: name the audience, the obstacle, the mechanism, and the outcome that would justify further investment. Define allocation, the primary outcome and the observation period before the test starts, and agree the response in advance — what happens if the booking system fails, if demand outruns capacity, or if volume rises while contribution falls. Report both numbers; don't move the success criterion after seeing the result.

Competitors reveal the choices available to a customer. Your strongest opportunity comes from understanding which part of that choice remains difficult, and whether your business can improve it economically. For our hypothetical retailer, the answer could be a supported bundle, clearer guidance, or a narrower promise — customer evidence, delivery capability and a useful test decide which direction deserves the investment.

• Define the buying situation. Name the customer's job and the decision you control, including workarounds and postponement.
• Record the complete conditions. Capture scope, price basis, delivery, eligibility and service terms, with a check date and source link.
• Keep missing information visible. Distinguish confirmed, unstated, conflicting and inaccessible — never infer absence from a failed lookup.
• Test relevance with customer evidence. Check comprehension of a concrete offer, not enthusiasm for an abstract idea.
• Calculate the commercial boundary. Model contribution, acquisition cost and service workload together, with uncertain inputs shown explicitly.
• Run a bounded test and preserve the result. Define the outcome and response conditions before launch, and report what the evidence actually supports.