Compare on facts that stay true

A comparison page is written once and read for a long time. So is the slide in the pricing deck, and so is the table in the positioning doc. Some of the facts on them change only when the product itself changes: what it is built around, where the data sits, what it does when the user’s plans change. Others can change overnight: the rival’s price, the free tier, the feature list. The second kind is the easiest to put in a table, which is how it came to carry the decision on my own pages.

A fact earns a place in a comparison when it stays true and someone stands behind it. A rival’s price fails the first test. A revenue figure with no owner fails the second.

A rival’s price goes stale first

For one of my apps, a meal planner, I approved comparison pages with a price table at their center. Later that same day I saw the pages rendered, and I reversed my own approval. On that site, the price table changed what the page was about. To me, a page whose spine is money is a price-comparison site with no point of view, and I doubt money is why most people pick a meal planner. The table had turned the product into one line in a grid of prices.

A rival’s prices, feature list and free tier move. Your page keeps saying what was true on the day you wrote it, and it says it under your name. The strategy notes for that site call a page in that state “a lie with our logo on it”.

Compare on how the product is built

Take a single row. The decaying version reads: their monthly price, our monthly price. The lasting version reads: where the plan lives, theirs and ours. The first row goes out of date the next time the rival runs a sale. The second stays true until one of you changes how the product works.

These are the four rows I settled on for the meal planner. A reader can check two of them by trying the product: what it is built around, and what happens when plans change.

What the product is built around. A recipe box and a weekly plan both hold recipes, and they solve different problems: one keeps things, the other decides what happens on which day. Someone who wants the first may be unhappy with the second, whatever it costs.

Where the data lives. On the phone, in an account, in a space a partner can edit. This decides who can see what, and what survives a lost device. It changes less often than a price.

What happens when the user’s plans change. For a meal planner: someone cancels dinner, a trip moves, a guest arrives. Either the product absorbs the change or the user starts over.

What happens if the company stops. Can people take out what they made, and in what form? Write the answer down for your product and for theirs. On the rival’s side, this row and the data row get a check date like any other, because an update can add sync or an export.

Say plainly where the rival is better, and say who should pick them. The strategy notes for that site make this the rule for every comparison page, because a page that wins every row reads as an advert.

The first row goes out of date the next time the rival runs a sale.

The second test: someone stands behind the number

In the pricing work for a residency-day counter, one figure about the category leader had made it into the research: $60k a month. When the research followed it back, the trail ended at an unrelated founder’s revenue story. It was never about the leader. The research marked the figure unverified and gave it 20 out of 100 for evidence. The instruction on file was short: re-baseline any plan built on that number.

So before an outside revenue figure enters a pricing doc, follow it back to the person or document that first stated it. If the trail ends at another company, as this one did, delete the figure and re-baseline anything built on it. In that research, every row of the demand table carried an evidence score in its own column. Your doc needs less: a column that says whether each outside number is verified, kept beside the number wherever it travels.

I traced only that ending. A trail can also end nowhere, where every copy points to another copy and nobody stands behind the number. Or it can end at the company itself, which is still a company describing itself. The first fails the second test: nobody stands behind it, so it goes. The second has an owner, and the owner is the one who benefits, so it can stay with its mark beside it.

Sometimes no good number exists. The same research flagged revenue and download estimates for the whole category as thin, because the App Store hides them. A plan built in that gap should say so, with the weak numbers marked as weak.

Where rival prices still belong

Keep rival prices in an internal doc, each one with the date you checked it beside it. They still matter for your own pricing, and there a stale figure costs you a re-check that nobody outside sees.

Inside a pricing deck, rival prices are a range you choose to sit inside, checked and dated. A deck that argues only from rival prices goes stale as soon as a rival moves outside your range.

A public page is harder. Someone searching for a rival against you might want the price first, and a page without one leaves that question open. Show a rival’s price only with the date you checked it and a plan to check again, or leave prices off. The meal planner’s site went the second way: no price on any page, ours included. That was one site’s choice in one category. I can’t yet say how those pages perform.

- Mark every fact a rival can change without telling you: price, free tier, plan limits, feature list.
- Replace each one with a row on how both products are built: what they are built around, where the data lives, what happens when plans change, what happens if the company stops.
- Add a row where the rival wins, and say who should pick them.
- Put a check date beside any rival fact you keep, the build rows included, and check it again on a schedule you write down.
- For every revenue figure in your pricing doc, write down who first stated it.
- If the trail ends at another company, delete the figure and redo the plan without it.
- Mark every outside number as verified or unverified, and keep the mark beside it.