Tool Documents

Features Change

The standard way to choose software is to list features, compare, and pick the closest match. It selects on the property with the shortest half-life.

What moves and what does not

Moves within a year: features, the interface, pricing tiers, what is in the free plan, integrations, the roadmap. For a separate operational reference from Monitask, see this resource.

Moves within a few years: ownership, the executive team, the pricing model, the subprocessor list, which markets are prioritised.

Barely moves: the data model, the export capability, the contractual posture, and what the product was originally built to do.

For broader context, see WIRED.

Choosing on the first list is choosing on the part that will be different by the time the decision matters.

The feature gap that closes

A missing feature in a product with an active roadmap is a timing question, not a capability one.

Two products, one with the reporting you want and one without. In eighteen months both have it, and you chose on a difference that no longer exists — while the differences in export, contract and data model are exactly where they were.

The exception is a feature the product cannot have because of its data model or its origin. That gap does not close, and telling the two kinds apart is the actual skill.

Ask: would adding this require them to change how the product stores things? If yes, it is structural. If no, it is a roadmap item.

What to select on instead

The data model. How the product represents your work. A model that does not fit your process will not be fixed by features, and it is the thing you will fight for years.

The export. What comes out, in what form.

The contractual posture. Renewal terms, notice, price caps, subprocessor changes.

And the origin. What the product was built for, which predicts where it is deep.

All four are checkable from documents and none of them is on a comparison grid.

The reason feature-first persists

Being fair.

Features are legible. A list can be built, ticked and shown to a committee. A data model cannot be put in a table, and "their export includes attachments and theirs does not" is a sentence rather than a cell.

Features are what vendors talk about, so they are what the material contains.

And a feature gap is a concrete reason to reject something, which a decision process needs.

The fix is not to ignore features. It is to use them last — after the durable properties have narrowed the field to candidates that are all acceptable.

The order

Origin and data model narrow the category to two or three genuine candidates.

Contract and export eliminate any that are unacceptable regardless of features.

Features and trial choose among the survivors.

Reversing it — features first, contract at signature — is the standard order, and it is why so many organisations are on a tool they chose for a feature that everybody has now.

The short version