Build a Capability Matrix with Evidence Strength

A feature checklist often gives the same green tick to three different things: a documented capability, an observed test result, and a salesperson's description of planned development. That makes a comparison look complete while concealing the evidence a buyer still needs.

Build a capability matrix with separate fields for availability, evidence strength, and workflow fit. A feature may be available but untested in your environment. Another may work in a demonstration but be absent from the edition you intend to buy. Neither situation deserves an unqualified yes.

Give each row one observable behavior

Replace broad requirements such as integration or reporting with a verb, object, and condition. For example: export reviewed account notes with their source identifiers; prevent an unapproved task from reaching the destination; or allow an ordinary user to inspect an error without administrator help.

Then separate the questions. Availability asks whether the current offer includes the behavior. Evidence strength asks what supports that answer. Fit asks whether the behavior satisfies your specific requirement. Keep an owner and next check beside unresolved fields so the matrix directs work rather than merely displaying uncertainty.

Plan boundaries are real. LinkedIn's plan comparison lists full CRM-related capabilities under Advanced Plus. A general Sales Navigator description does not establish what an independent offer includes. Verify the actual subscription and applicable setup before marking a row available.

A completed illustrative capability matrix

The following fictional evaluation concerns QuillDesk, an invented internal research-review product. Its documents, edition names, and observations are assumed solely for this example. No named product was tested.

• C1: preserve source identifiers in exported notes. Required for migration, with both note text and identifiers remaining reusable as text rather than image-only content. Availability: note export is included in the fictional Team edition; preservation of source identifiers is not established. Evidence: documentation describes note export, but omits source identifiers. Fit: unknown. Next check: export synthetic note N-17 containing source S-4 and inspect both fields.

• C2: stop rejected task creation. Required before operational use. Availability: documented. Evidence: an illustrative controlled test records rejection and no matching task at the mock destination. Fit: supported only for that tested route and configuration. Next check: review other action routes separately.

• C3: create tasks while offline. Optional convenience. Availability: unavailable in the current edition, according to the fictional support answer. Evidence: explicit current statement. Fit: not met. Decision: do not block this evaluation because offline creation is optional.

• C4: automatically translate reviewed notes. Optional. Availability: planned, with no committed release. Evidence: roadmap mention only. Fit: not evaluated. Decision: exclude it from the purchase justification.

• C5: let reviewers inspect errors without administrator rights. Required. Availability: claimed in the demonstration. Evidence: presenter used an administrator account. Fit: unknown. Next check: repeat with the intended reviewer role.

This matrix has one narrowly supported result, two unresolved requirements, one unavailable optional feature, and one future idea. It does not produce a meaningful overall completion percentage. Counting ticks would hide which unresolved item can block adoption.

A stronger source may answer the wrong question

An official manual is stronger than an unattributed sales slide for describing the published product. However, a manual cannot prove that your configured workflow preserved a field during an actual transfer. Conversely, a successful test cannot establish a contractual entitlement or future support commitment.

Keep evidence types rather than ranking everything on one ladder. Use documented, observed in a bounded test, commercially confirmed, claimed without support, and unresolved. Multiple labels can apply to one row when they answer different questions.

For C1, suppose the export includes source identifiers but turns every note into an image. The narrow field-preservation check passes, yet the buyer's requirement for reusable text fails. Update the fit decision; do not discard the inconvenient result or broaden the original requirement after the fact.

Review only what can change the purchase decision

Prioritize required unknowns before optional polish. Assign C5 to the trial administrator and C1 to the migration owner. If the vendor cannot provide an appropriate test route, keep the requirement unresolved and explain the consequence to the decision owner.

The existing vendor-requirements guide helps organize buyer priorities. This matrix adds an explicit distinction between availability and proof. Its final output should state which requirements are established, which are unsupported, and what evidence would permit a narrower, defensible decision.