A practical review resource

Product & technology review evidence checklist

Gather the evidence that could change your next product or technology decision. Start with what exists, make gaps visible and agree the depth of review around the business need.

Download the checklist (PDF)Editable worksheet (CSV)

Free to use. No email or file upload needed.

20 evidence prompts

Start with what your business already knows

01
Name the decision
What would the evidence help you change?
02
Gather what exists
Use a summary, a walkthrough or existing records.
03
Make gaps visible
Name an owner and the question still to resolve.

Choose the relevant evidence

For a product-led review, begin with customer evidence and roadmap delivery. For a technology-led review, begin with architecture, resilience and release work. Use the shared sections for either. Agree additional depth with the reviewer.

Mark the status, not a score

In the worksheet, mark each request Available, Partial, Missing or Not applicable. Add the owner, where evidence is held and the question to resolve. Missing records are a limitation to investigate, not a verdict on the team.

01 · For either review

The business decision

Start with the choice the review must support. Gather these first, whichever areas you examine.

Decision and deadline

Likely owner: Business sponsor

Why it matters: Keeps the review focused on an action leadership can take.
An example to gather: A one-page brief: whether to commit to the next release, change supplier or invest in the platform.
If that evidence is unavailable: Record the question, decision owner, deadline and consequences in a short discussion note.

Boundaries and upcoming changes

Likely owner: Business sponsor with product and technology leads

Why it matters: Defines which products, systems, teams and dependencies need attention.
An example to gather: An agreed list of included systems, planned changes and known exclusions.
If that evidence is unavailable: Draw a simple boundary map and list assumptions to confirm during discovery.

02 · Product-led evidence

Product and customer evidence

Connect proposed work to a customer problem and a business outcome.

Customer problem and demand

Likely owner: Product lead or customer-facing lead

Why it matters: Tests whether priorities rest on evidence of a need.
An example to gather: A redacted research summary or an aggregated account of recurring support themes.
If that evidence is unavailable: Walk through the intended user task and record which assumptions still need validation.

Product priorities and success measures

Likely owner: Product lead and commercial sponsor

Why it matters: Shows how the roadmap is expected to help the business.
An example to gather: Current product priorities with the intended outcome, measure and reason for each.
If that evidence is unavailable: Write the intended change in customer behaviour or business performance; mark any unmeasured assumption.

Adoption and customer friction

Likely owner: Product lead with customer success

Why it matters: Distinguishes a shipped feature from a usable customer outcome.
An example to gather: Aggregated workflow usage, onboarding issues or a summary of adoption barriers.
If that evidence is unavailable: Use a guided workflow demonstration and a small, anonymised set of recurring issues; label the limits.

03 · Product-led evidence

Roadmap and recent delivery

Use the same recent period for commitments, interruptions and completed work.

Current and previous roadmap

Likely owner: Product lead

Why it matters: Reveals what changed and who made the trade-off.
An example to gather: Two dated roadmap versions with reasons for material changes.
If that evidence is unavailable: Reconstruct a few significant commitments and confirm changes with the decision owners.

Planned and completed work

Likely owner: Delivery or engineering lead

Why it matters: Tests the assumptions behind available capacity and delivery confidence.
An example to gather: An anonymised summary of planned, completed, carried-over and unplanned work.
If that evidence is unavailable: Walk through representative work from decision to release; do not infer team performance from missing records.

Interruptions and dependencies

Likely owner: Delivery lead with operations

Why it matters: Makes support demand, specialist constraints and external decisions visible.
An example to gather: Support and incident demand alongside the owners and status of critical dependencies.
If that evidence is unavailable: List recurring interruptions and unresolved dependencies, separating estimates from recorded demand.

04 · Technology-led evidence

Architecture and dependencies

Map the paths the business relies on, rather than producing a diagram for its own sake.

Critical systems and data flows

Likely owner: Technical lead or system owner

Why it matters: Shows where a proposed change or failure could affect the business.
An example to gather: A high-level diagram of systems, integrations, data flows and business-critical paths.
If that evidence is unavailable: Draw the main flows together and mark unverified connections.

Supplier and platform dependencies

Likely owner: System owner with procurement

Why it matters: Identifies constraints on continuity, change and exit.
An example to gather: A summary of critical providers, operational owners, contract dates and exit questions.
If that evidence is unavailable: Create a list of dependencies and owners; have the responsible person confirm terms separately.

Change constraints and technical debt

Likely owner: Technical or engineering lead

Why it matters: Connects platform concerns to a decision about investment or delivery.
An example to gather: A prioritised set of recurring change bottlenecks with examples of affected work.
If that evidence is unavailable: Demonstrate a representative change and distinguish observed constraints from suspected causes.

05 · Technology-led evidence

Operational resilience

Understand how the business detects problems and restores critical services.

Recent incidents and response

Likely owner: Operations or technical lead

Why it matters: Shows recurring exposure and how operational learning reaches the plan.
An example to gather: Redacted incident summaries, impact, contributing factors and outstanding actions.
If that evidence is unavailable: Walk through a recent disruption and document what is known, unknown and still open.

Recovery evidence

Likely owner: System owner or operations lead

Why it matters: Tests the evidence behind a recovery expectation.
An example to gather: A dated restore or recovery exercise summary with result, scope and follow-up actions.
If that evidence is unavailable: Record the backup arrangements and proposed restore test; an untested backup is not evidence of recovery capability.

Monitoring and operational cover

Likely owner: Operations or service owner

Why it matters: Shows whether important failures can be detected and acted on when the main owner is unavailable.
An example to gather: A high-level monitoring and escalation summary for critical services, with responsible roles and cover.
If that evidence is unavailable: Walk through how an outage would be noticed, who would respond and which assumptions remain untested.

06 · Technology-led evidence

Release and quality

Follow work through to a usable release, including checks and recovery steps.

Release path and checks

Likely owner: Engineering or QA lead

Why it matters: Finds hand-offs or manual steps that affect release safety and timing.
An example to gather: A release walkthrough showing tests, approvals, deployment and rollback arrangements.
If that evidence is unavailable: Document one recent release and the checks actually performed; mark undocumented steps.

Defects, rework and acceptance

Likely owner: QA, engineering and product leads

Why it matters: Shows whether completion includes customer acceptance and unresolved issues.
An example to gather: An anonymised sample of reopened defects, rework and release acceptance criteria.
If that evidence is unavailable: Trace a few recent issues from discovery to resolution; note where comparable records do not exist.

07 · For either review

Ownership and accountability

Identify who can make decisions and who can operate the systems when a key person is absent.

Decision and operational owners

Likely owner: Business sponsor and functional leads

Why it matters: Exposes gaps in accountability and reliance on individual knowledge.
An example to gather: A role-based map of product decisions, systems, suppliers and named deputies.
If that evidence is unavailable: Build a responsibility map in a short workshop and record disputed or vacant responsibilities.

Administrative control and handover

Likely owner: IT or security owner

Why it matters: Clarifies who controls critical accounts and how continuity is maintained.
An example to gather: A redacted access-ownership summary, joiner/leaver process and handover responsibilities.
If that evidence is unavailable: List the roles controlling each critical service and what needs verification. Keep credentials out of the checklist.

08 · For either review

Open questions and next decisions

Make missing evidence useful by connecting it to an owner and a decision.

Evidence gaps and conflicting accounts

Likely owner: Review coordinator with evidence owners

Why it matters: Prevents an assumption being presented as a verified finding.
An example to gather: A list of missing, partial or conflicting evidence and the decision each gap affects.
If that evidence is unavailable: Write each unresolved question, the best available account and what could confirm or change it.

Actions, owners and closure evidence

Likely owner: Business sponsor and delivery owners

Why it matters: Turns the review into a practical next step.
An example to gather: A short action list with accountable owner, dependency, review date and evidence of completion.
If that evidence is unavailable: Agree the first decision or investigation, who owns it and how progress will be reviewed.

Bring the evidence back to the decision

Leave preparation with three clear answers

What do we have enough evidence to discuss?
Which gaps could change the decision?
Who owns the next question, and when will we review it?

You do not need a complete evidence pack to begin. A free 1–2 hour discovery session establishes the pain points and the questions a bespoke review should answer.

Explore Product & Technology Reviews

Use the worked roadmap decision table →See how evidence becomes report findings →

This checklist is FoundationState’s preparation framework, not an audit, certification or assessment result. The technical review depth and any specialist testing are agreed separately. For related recovery guidance, see the NCSC’s incident preparation guidance.