Download the editable Feature Gap Matrix
The file is designed for real review work, with structured fields, ownership prompts, status controls, and space for evidence.
What this file is for
This feature gap matrix helps a buying team separate mandatory workflow gaps from preferences, workarounds, integrations, and roadmap promises. It is most useful when several functions need to contribute facts but one person must maintain a single decision record. The working question is whether a product gap is acceptable, remediable, or disqualifying for the target workflow. Keeping that question visible prevents the team from collecting documents and comments that never change the decision.
Use the file before approval, and return to it whenever scope, quantities, data handling, delivery timing, or contract terms change. The expected coordinator is the solution evaluation lead, with input from process owners, administrators, security, integration owners, finance, and representative users. The tool does not replace legal, security, privacy, finance, or technical judgment. It makes each judgment traceable to evidence and an accountable owner.
What the download contains
| # | Working area | How to complete it |
|---|---|---|
| 1 | Required Outcome | Record the fact, its source, accountable owner, status, and the consequence if it remains unresolved. |
| 2 | Current Process Evidence | Record the fact, its source, accountable owner, status, and the consequence if it remains unresolved. |
| 3 | Native Support Status | Record the fact, its source, accountable owner, status, and the consequence if it remains unresolved. |
| 4 | Workaround Or Dependent Tool | Record the fact, its source, accountable owner, status, and the consequence if it remains unresolved. |
| 5 | Gap Severity And Probability | Record the fact, its source, accountable owner, status, and the consequence if it remains unresolved. |
| 6 | Owner, Deadline, And Acceptance Decision | Record the fact, its source, accountable owner, status, and the consequence if it remains unresolved. |
The file also includes instructions, status choices, review notes, and a signoff area. Blank fields are intentional: they should be completed from the documents and tests for the actual purchase. Do not copy a previous vendor's answers unless the underlying facts are still current and apply to the same service scope.
Field-by-field review guide
Required Outcome
Treat required outcome as a decision input in the feature gap matrix, not as a label that proves completion. The entry should show the current fact, the source that supports it, and the consequence for whether a product gap is acceptable, remediable, or disqualifying for the target workflow. Ask the solution evaluation lead to separate confirmed evidence from a planning assumption and to identify who can accept any limitation. Cross-check required outcome against current process evidence, because those two areas can reveal a hidden scope, timing, ownership, or contract conflict. Input from process owners, administrators, security, integration owners, finance, and representative users should remain attributable to the person and evidence used. A specific risk to test here is building a checklist from vendor navigation labels. Record the status, next action, due date, and proof needed for closure. The completed required outcome record should still make sense to a renewal, incident, audit, or replacement team that did not attend the original meetings.
Current Process Evidence
Treat current process evidence as a decision input in the feature gap matrix, not as a label that proves completion. The entry should show the current fact, the source that supports it, and the consequence for whether a product gap is acceptable, remediable, or disqualifying for the target workflow. Ask the solution evaluation lead to separate confirmed evidence from a planning assumption and to identify who can accept any limitation. Cross-check current process evidence against native support status, because those two areas can reveal a hidden scope, timing, ownership, or contract conflict. Input from process owners, administrators, security, integration owners, finance, and representative users should remain attributable to the person and evidence used. A specific risk to test here is calling manual rework a no-cost workaround. Record the status, next action, due date, and proof needed for closure. The completed current process evidence record should still make sense to a renewal, incident, audit, or replacement team that did not attend the original meetings.
Native Support Status
Treat native support status as a decision input in the feature gap matrix, not as a label that proves completion. The entry should show the current fact, the source that supports it, and the consequence for whether a product gap is acceptable, remediable, or disqualifying for the target workflow. Ask the solution evaluation lead to separate confirmed evidence from a planning assumption and to identify who can accept any limitation. Cross-check native support status against workaround or dependent tool, because those two areas can reveal a hidden scope, timing, ownership, or contract conflict. Input from process owners, administrators, security, integration owners, finance, and representative users should remain attributable to the person and evidence used. A specific risk to test here is ignoring gaps that affect administrators rather than users. Record the status, next action, due date, and proof needed for closure. The completed native support status record should still make sense to a renewal, incident, audit, or replacement team that did not attend the original meetings.
Workaround Or Dependent Tool
Treat workaround or dependent tool as a decision input in the feature gap matrix, not as a label that proves completion. The entry should show the current fact, the source that supports it, and the consequence for whether a product gap is acceptable, remediable, or disqualifying for the target workflow. Ask the solution evaluation lead to separate confirmed evidence from a planning assumption and to identify who can accept any limitation. Cross-check workaround or dependent tool against gap severity and probability, because those two areas can reveal a hidden scope, timing, ownership, or contract conflict. Input from process owners, administrators, security, integration owners, finance, and representative users should remain attributable to the person and evidence used. A specific risk to test here is accepting screenshots instead of a repeatable test. Record the status, next action, due date, and proof needed for closure. The completed workaround or dependent tool record should still make sense to a renewal, incident, audit, or replacement team that did not attend the original meetings.
Gap Severity And Probability
Treat gap severity and probability as a decision input in the feature gap matrix, not as a label that proves completion. The entry should show the current fact, the source that supports it, and the consequence for whether a product gap is acceptable, remediable, or disqualifying for the target workflow. Ask the solution evaluation lead to separate confirmed evidence from a planning assumption and to identify who can accept any limitation. Cross-check gap severity and probability against owner, deadline, and acceptance decision, because those two areas can reveal a hidden scope, timing, ownership, or contract conflict. Input from process owners, administrators, security, integration owners, finance, and representative users should remain attributable to the person and evidence used. A specific risk to test here is building a checklist from vendor navigation labels. Record the status, next action, due date, and proof needed for closure. The completed gap severity and probability record should still make sense to a renewal, incident, audit, or replacement team that did not attend the original meetings.
Owner, Deadline, And Acceptance Decision
Treat owner, deadline, and acceptance decision as a decision input in the feature gap matrix, not as a label that proves completion. The entry should show the current fact, the source that supports it, and the consequence for whether a product gap is acceptable, remediable, or disqualifying for the target workflow. Ask the solution evaluation lead to separate confirmed evidence from a planning assumption and to identify who can accept any limitation. Cross-check owner, deadline, and acceptance decision against required outcome, because those two areas can reveal a hidden scope, timing, ownership, or contract conflict. Input from process owners, administrators, security, integration owners, finance, and representative users should remain attributable to the person and evidence used. A specific risk to test here is calling manual rework a no-cost workaround. Record the status, next action, due date, and proof needed for closure. The completed owner, deadline, and acceptance decision record should still make sense to a renewal, incident, audit, or replacement team that did not attend the original meetings.
Decision rules
- Describe the business outcome before naming a feature.
- Test claimed workarounds with the same data and permissions expected in production.
- Price every dependent product needed to close a gap.
- Treat roadmap statements as unavailable unless contractually committed.
Common failure modes
- Avoid building a checklist from vendor navigation labels.
- Avoid calling manual rework a no-cost workaround.
- Avoid ignoring gaps that affect administrators rather than users.
- Avoid accepting screenshots instead of a repeatable test.
Evidence and signoff standard
A defensible file should let a later reviewer reconstruct the decision without relying on memory. For every material item, capture the source document or test, the date reviewed, the person responsible, and the next action. If evidence is restricted, record its approved location and a short conclusion rather than attaching it to an uncontrolled copy. If a vendor answer changes, preserve the final accepted version and note what superseded the earlier response.
Before signoff, verify that the record covers required outcome, current process evidence, native support status, workaround or dependent tool, gap severity and probability, and owner, deadline, and acceptance decision. Resolve critical gaps or document a time-limited exception. The final approver should understand both the desired outcome and the residual risk. Store the signed or approved copy with the contract, quote, implementation decision, or service inventory entry that it supports.
Questions to ask before approval
- What evidence supports the entry for required outcome?
- What evidence supports the entry for current process evidence?
- What evidence supports the entry for native support status?
- What evidence supports the entry for workaround or dependent tool?
- What evidence supports the entry for gap severity and probability?
- What evidence supports the entry for owner, deadline, and acceptance decision?
Authoritative references
The following public resources provide context for the control and acquisition principles used in this file. They do not answer vendor-specific questions; use the current vendor documents and your organization's policies for the actual decision.