Project management features worth keeping are boring: history and exports

Every product in this category has boards, lists, and a calendar view. Those are table stakes and they photograph well. The features that decide whether the tool is still useful in year two are duller and are usually described in one line on the comparison page.

This is a guide to which ones are load bearing, and to the specific question that reveals whether each is real.

What to take away

The history of an item is the most valuable feature in the product and the one nobody demonstrates.
Permission granularity decides whether outside collaborators are possible at all, and it is frequently a tier above the one you were quoted.
Custom fields are a liability with a benefit attached. Every one you add taxes every item created afterwards.
Roll up reporting is only as honest as the shared definition of a status, and most organizations do not have one.

The history of an item

When a date is disputed, and it will be, the only useful evidence is a record of what changed, when, and at whose hand. Ask three things about it.

Item history questions

How far back does it go?
Visible to workers or admins only?
Does it export?
Retention perioddecision or default?

How far back does it go, on the tier being quoted? Some products keep a full history and some keep the last handful of changes. Is it visible to the people doing the work, or only to an administrator? A history that requires a support request is not part of daily work. And does it export?

Treat the retention period of that record as a decision, not a default. It is the one part of the product that answers questions after the fact.

The general case for treating log retention as a deliberate choice appears in the guide to security log management. That reasoning transfers directly to a work tracker: a record that has rolled over is not evidence of anything.

Permissions, tested rather than described

Every product says it supports granular permissions. The test is to create the situation you actually have.

Permission boundary test

Add person to one project
Check other project names
Check member directory and search
Check attachments on items
Remove person and verify uploads remain
Confirm reassignment and link expiry

Add a person who should see one project. Then check what they can see everywhere else: the list of other project names, the member directory, search results, and anything attached to an item. Several products treat project membership as a filter on a view rather than as a boundary, and the difference only shows up when you look.

Then check the reverse. Remove that person and confirm that what they uploaded remains, that items they owned get reassigned rather than orphaned, and that any link they were given stops working.

Custom fields, and the tax they levy

A custom field is added because one person needs it once. It then appears on every item forever, and new joiners fill it in with a guess.

Custom field rules

Written definition and named owner
Required or empty, decided deliberately
Delete fields whose owner has left
Can you remove a field without data loss?
Can you see how many items use it?

Three rules keep this in hand. Every field has a written definition and a named owner. Every field is either required or is allowed to be empty, and which one is decided deliberately rather than by default. And a field with an owner who has left is deleted, not inherited.

The feature to look for is not more field types. It is whether the product lets you remove a field without losing the data in it, and whether you can see how many items actually use one. A product that cannot tell you which fields are unused is a product where nobody will ever dare delete one.

Dependencies, and the honest version

Dependency modeling is the feature most often bought and least often maintained. The question to ask is not whether the product supports it but what it does when a date moves.

Dependency behavior when a date moves

What happens when a date moves?

Yes

silently pushes forty tasks; people stop moving dates

dependency is decorative

If shifting one task silently pushes forty others, people will stop moving dates and start lying. If it does nothing at all, the dependency was decorative. The useful middle is a product that shows the consequence and asks. Test it by moving a task in the trial and watching what happens to everything downstream.

Notifications are a design decision

The default notification volume in most of these products is set for a demonstration, where activity is a sign of life. In production it is the reason people mute the tool, and a muted tool is an out of date tool.

Notification control levels

Product default

Who controls it: Vendor
Typical state: Demo-level noise
Consequence: Tool gets muted

Individual setting

Who controls it: Each user
Typical state: Manual muting
Consequence: Inconsistent

Admin default

Who controls it: Administrator
Typical state: Often missing
Consequence: New joiners start noisy

Look for control at three levels: what the product sends by default, what an individual can change, and what an administrator can set as a sensible default for everyone. The third is the one that is missing most often, and its absence means every new joiner starts with the noisy setting.

Reporting that does not lie

Roll up views promise a single picture across projects. They deliver one only if a status means the same thing in every project, which is an organizational agreement rather than a feature.

Reporting readiness checks

Define what each status means
Align blocked across teams
Views saved and shared, not rebuilt
Views can be exported
Counts items or effort?

Before evaluating reporting, define what each status means. If two teams use blocked differently, no chart from that field is worth reading.

Once definitions exist, focus on features: views that can be saved and shared instead of rebuilt by each manager, whether a view can be exported, and whether the tool counts items or effort. Those give different pictures of the same quarter.

Automation, and what it costs to keep

Automation rules are genuinely useful and they accumulate quietly. Six months in, an item moves and nobody can say why.

Ask whether rules appear in one list, whether each rule shows when it last ran, and whether a rule can be disabled without deletion. Then ask who owns them.

Where automation reaches outside the product, the connection becomes an interface with its own maintenance. Treating it that way from the start is the point of published API and data standards: a connection nobody documented is a connection nobody can fix.

Which features to weigh, and how much

Which features to weigh

Feature	Weight	Because
Item history and its retention	High	It settles disputes and nothing else does
Permission boundaries	High	It decides whether outside work is possible at all
Export quality	High	It sets what leaving costs, and you cannot test it later
Dependency behavior	Medium	Only if you will genuinely maintain a sequence
Saved shared views	Medium	Removes a recurring hour from several people's weeks
Automation visibility	Medium	Prevents the unexplained state change
Field types and board styling	Low	Adjustable later, and rarely the reason anything failed

Where this fits

The category overview covers what these products differ on structurally. The setup discipline matters more than any feature here, since most liabilities above are self-inflicted during configuration.

Where features sit above the tier you were quoted, which is usual for history and permissions, the cost model explains the pattern. Connections into other products belong in the integration inventory from day one.

Common questions

Is a Gantt view worth paying extra for?

Only if somebody will keep it current. An out of date chart is worse than a list, because it is believed. Ask who updates it weekly and what happens when they are on leave.

Do we need time tracking?

Only if a decision depends on the number. Billing a client, or knowing whether a service is viable, are real reasons. Curiosity is not, and time tracking imposed without a stated purpose produces numbers shaped by what people think you want to see.

How many statuses should we have?

Few enough that everyone can recite them. Each one needs a meaning and a person responsible for moving work out of it. A status with no owner becomes a place where items go to be forgotten, and the count of items sitting there is the most useful report in the whole product.

What about artificial intelligence features?

Judge them the same way as everything else on this page: what do they leave behind, and can it be checked. A generated summary that nobody verifies becomes the record. A suggested priority that nobody can explain is a decision with no author.