Product and Program Artifacts

Outcomes tell you what happened. Artifacts tell you how someone works. These are the 20 deliverables behind the case studies on this site — 10 product, 10 program — each with the problem it solves, when it is used and the decision it exists to support.

Where these come from

15 of 20 are working documents from repositories and runbooks I own. The rest are reconstructions — their originals belong to former employers and are not mine to publish.

Sanitized actual artifact: Exists as a working document in a repository or runbook Liorry owns. Condensed for reading, with client names, credentials and production infrastructure detail removed.
Representative reconstruction: The original belongs to a former employer and is not Liorry's to publish. What is shown is the structure of the artifact and the facts already published on this site — not a copy of a company document.

Reconstructions carry no invented numbers, dates or statuses. Where a field would need a value I cannot source, it states the rule the field applies or the question it answers instead. An invented defect count would make the artifact worthless.

10 artifacts

Product artifacts

What a product decision looks like when it is written down: the problem, the requirement, the tradeoff accepted, and how success would be recognized.

Sanitized actual artifactMailerClub — suppression enforcement
One-page PRD
Problem it solves
A requirement described in conversation gets built five different ways. One page, agreed before implementation, removes the ambiguity without becoming a document nobody reads.
When it is used
At the start of a feature, before any implementation work is scheduled.
Decision it supports
Whether the problem is worth solving, and what would count as having solved it.
Extract
Problem
Suppression is the highest-stakes rule in the platform and the easiest to bypass. Every new send path is a new place the check can be forgotten by someone who did not know the rule existed.
Goal
No send path can reach the delivery engine without consulting suppression, and the rule holds for paths that do not exist yet.
Non-goals
Not a consent-management product. Not a re-permissioning flow. No change to how suppression entries are created.
Users
Campaign operators; deliverability and compliance owners; engineers adding a send path.
Requirements
One mandatory funnel every send path passes through · suppression append-only in production · unsubscribe mechanism present on every outbound marketing message · the rule recorded as an invariant with a pointer to the code that proves it.
Acceptance criteria
A new send path cannot compile a delivery handoff without passing through the filter; a bulk delete against suppression is rejected in production; the invariant record names the evidence file.
Measure of success
New send paths inherit compliance rather than re-implementing it — verified at review, not by counting incidents after the fact.
Risks accepted
The funnel is a structural bottleneck and constrains how future send paths can be built. Accepted deliberately: a helper still has to be called; a funnel cannot be forgotten.
Sanitized actual artifact — Condensed from the platform's own service specification and invariant record for the suppression gate.

Sanitized actual artifactgiMTA — recovery contract

Product requirements excerpt

Problem it solves: Reliability requirements written as adjectives — robust, resilient — cannot be tested. Written as verifiable statements, they answer implementation questions on their own.
When it is used: Before architecture, so the design follows from the requirement rather than the reverse.
Decision it supports: What the system must guarantee, and how each guarantee will be proven.

Extract

Product requirements excerpt
ID	Requirement	How it is verified
R1	A send interrupted at any point resumes without re-delivering a message that already reached a terminal state.	Crash-recovery test: kill mid-send, restart, assert message-level outcomes.
R2	The injection-time inventory is written once and never mutated afterwards.	Index written by write-flush-rename; test asserts absence of any update path.
R3	Every delivery outcome is appended to a log that can be replayed independently of the running process.	Replay test reconstructs scheduler state from index plus log alone.
R4	A deferred message that survives a restart keeps its retry timing.	Recovery test asserts timer state, not message counts. This requirement exists because the first version passed a count-based test while behaving wrongly.
R5	A campaign refuses to start when pre-send routing resolution is below its floor.	Gate test at start; abort rather than warn.
R6	One campaign delivers from exactly one sending identity, with no configuration that permits otherwise.	Invariant record plus rejection test on multi-identity handoff.

Sanitized actual artifact — The recovery contract as written before implementation, restated in plain language. Verification column names the test class that proves it.

Sanitized actual artifactLead discovery — operator review gate
User stories with acceptance criteria
Problem it solves
Engineers and testers reading the same sentence and building different things. Acceptance criteria written with the story make the disagreement surface before the work starts.
When it is used
During backlog refinement, attached to the story before it is estimated.
Decision it supports
Whether a story is done, decided by the criteria rather than by discussion.
Extract
- As a lead operations reviewer, I need to see why each discovered address passed validation, so that I approve a list rather than trusting a score.
  Acceptance criteria
  Each result shows mail-exchange validity, role-address classification and suppression status.
  Results can be filtered to only those that passed every check.
  The job's recorded inputs and generated queries are visible from the result set.
- As a compliance reviewer, I need list provenance to be reconstructable after the fact, so that I can answer where a list came from.
  Acceptance criteria
  Every list created from discovery records the job it came from.
  Re-running the same job reproduces the same query set rather than a new random one.
- As the platform owner, I need discovery to have no automatic path into sending, so that no threshold can be raised under deadline pressure.
  Acceptance criteria
  No code path exists from a discovery result to a sending list without an operator action.
  An attempt to import without review fails rather than warning.
  The absence of that path is recorded as a stated non-goal, not left as an implementation detail.
Sanitized actual artifact — Stories behind the mandatory review gate, restated from the service specification.

Sanitized actual artifactMailerClub platform backlog

Prioritization framework

Problem it solves: Scoring models turn into arguments about the score. A ranked set of classes makes the ordering argument happen once, in the open, instead of per item.
When it is used: Every planning cycle, and whenever something urgent tries to jump the queue.
Decision it supports: What gets built next, and what is explicitly not being built.

Extract

Prioritization framework
Rank	Class	Test that puts work in this class	Example
1	Invariant risk	Could this break suppression, unsubscribe handling, bounce processing or sending identity?	Suppression gate coverage on a new send path.
2	Silent failure	If this broke, would anything tell us — or would it look like a quiet week?	Liveness check on the bounce processor.
3	Operator time	Does a person repeat this by hand on every campaign?	Staged send pipeline with per-stage reporting.
4	Revenue path	Does this block campaigns from going out or outcomes from being measured?	Event ingestion and funnel reporting.
5	Cost and cleanup	Does this reduce recurring spend or accumulated debt?	Retiring the legacy sending path; flag lifecycle discipline.

Sanitized actual artifact — The ordering rule applied to the platform backlog. Candidates shown are real backlog classes, not invented tickets.

Sanitized actual artifactPlatform modernization

Product roadmap

Problem it solves: A dated roadmap becomes a credibility problem the first time a date moves. Sequencing by dependency and confidence survives contact with reality.
When it is used: Reviewed each planning cycle; referenced whenever a new request arrives.
Decision it supports: What order the work happens in, and what has to be true first.

Extract

Product roadmap
Horizon	Item	Why here	Status
Now	Operate the current sending path and feed observed behavior back into throughput tuning.	Running work with live campaigns depending on it.	In production
Next	Retire the legacy sending path once remaining campaigns migrate.	Removes a class of configuration traps and halves operational surface.	Not started
Next	Mechanical invariant checks in continuous integration.	Invariants are enforced at review today; a build-level check removes the reviewer as the single point of failure.	Not started
Later	Event-log compaction and retention.	Replay cost grows with campaign size. It is the next scaling constraint, not a current one.	Not started
Later	Feature-flag lifecycle discipline — expiry and review.	Over one hundred flags accumulate faster than they retire.	Not started

Sanitized actual artifact — The Now/Next/Later split as it stands. Everything under Next and Later is published as roadmap on the case studies too — nothing here is presented as built.

Sanitized actual artifactCampaign creation to delivered outcome
User journey and workflow map
Problem it solves
Nobody disagrees about a process until it is drawn. A step-by-step map makes the handoffs, the waits and the missing owners visible in one reading.
When it is used
During discovery, and again after launch to check the map still matches reality.
Decision it supports
Which step to change, and which steps must not change.
Extract
1. Operator composes and schedules
  Audience, template, sending identity and schedule. AI drafting assistance is available and always operator-reviewed before scheduling.
2. Audience resolution
  Segment and list membership resolved to a concrete recipient set.
3. Suppression filter — mandatory gate
  The single funnel every send path passes through. Suppressed recipients are removed before anything downstream sees them.
4. Message generation
  Personalized rendering, including the unsubscribe mechanism required on every outbound marketing message.
5. Readiness barrier — fails closed
  Queue, cache and readiness state must be complete. If they are not, the send is refused rather than started early.
6. Delivery and event ingestion
  Per-recipient outcomes are pulled back, bounces classified, suppression updated — closing the loop.
7. Operator reviews reporting
  Funnel, placement and engagement, with injected, sent and delivered defined separately so they cannot be conflated.
Sanitized actual artifact — The operator journey as the platform runs it today. The full annotated version, including where AI is and is not used, is on the workflow library page.

Sanitized actual artifactCampaign operations

KPI framework

Problem it solves: A metric without a definition gets reported three ways in the same meeting. A metric without a guardrail gets optimized until something else breaks.
When it is used: Agreed before launch; reviewed whenever a number is disputed.
Decision it supports: Whether the system is working, and what nobody is allowed to trade away for it.

Extract

KPI framework
Metric	Definition	Decision it drives	Guardrail
Injected	Messages handed to the delivery engine.	Whether preparation completed as expected.	Never reported as delivered.
Delivered	Accepted by the recipient mail server.	Whether the send is progressing.	Never inferred — only recorded from an actual acceptance.
Deferral rate	Share of attempts the receiver asked us to retry.	Whether to slow down for a destination.	Throughput is never bought by spreading a campaign across sending identities.
Hard bounce rate	Permanent rejections, per send.	Whether list quality upstream needs work.	Every hard bounce appends to suppression; the feed is never paused to improve a number.
Complaint rate	Recipient-reported abuse.	Whether to stop a campaign.	Complaint processing must always be running; its absence is treated as a failure.
Time to first response	Inbound inquiry to first qualified reply.	Whether intake automation is holding up.	A human still owns every client commitment.

Sanitized actual artifact — Definitions as the platform reports them. No campaign volumes or client delivery rates appear — those are not Liorry's to publish.

Sanitized actual artifactgiMTA — one campaign, one lane
Feature decision record
Problem it solves
Six months later, nobody remembers why the obvious option was rejected — so it gets adopted during an incident, when the reasoning is least available.
When it is used
At the point of decision, and re-read whenever someone proposes the alternative.
Decision it supports
The decision itself, plus the cost the team knowingly accepted.
Extract
Decision
One campaign delivers from exactly one sending identity. A hard rule, not a configurable setting.
Options considered
Allow fan-out across identities for throughput · allow it behind a feature flag · forbid it entirely.
Chosen
Forbid it, with the rationale written next to the rule.
Why
Fanning one campaign across sending identities is the fastest available throughput win and one of the most reliable ways to damage domain reputation. Left as a tunable, it will eventually be tuned during an incident — which is exactly when it does the most harm.
Cost accepted
A ceiling on single-campaign throughput. Capacity has to come from parallel workers inside the identity instead.
Result
Capacity and sending identity became independent concepts, which is what made the ceiling acceptable.
Review trigger
Reopen only if the deliverability rationale changes, not because a campaign is running late.
Sanitized actual artifact — Condensed from the invariant record that carries this decision and its rationale in the repository.
Sanitized actual artifactMailerClub release process
Launch checklist
Problem it solves
Release-day steps held in someone's head get skipped under pressure, and the one that gets skipped is the verification.
When it is used
Every release, in order, with the reverse path identified before the change goes out.
Decision it supports
Whether this build is allowed to carry production work.
Extract
- Acceptance criteria for every change in the release are written and tied to the invariant each must not break.
- Unit, integration and end-to-end suites pass on the release candidate.
- Operators run their real campaign flow on the candidate and sign off (UAT).
- Every behavior change is behind a feature flag that defaults to off.
- Migrations have both an up and a down path, and the down path has been run.
- Rollback route identified: behavior reverts by disabling a flag, code by redeploying the previous build.
- First campaign after release is verified end to end at low volume before scheduled volume follows.
- Liveness checks confirmed moving: queue depth, bounce processing, event ingestion.
- Anything learned becomes an invariant, a check or a runbook entry — not a message in a thread.
Sanitized actual artifact — The platform's release checklist, condensed. Host names, service unit names and deploy commands are deliberately absent.
Sanitized actual artifactgiMTA — deferred-timer defect
Post-launch review
Problem it solves
A fix helps once. A review that ends in a permanent check helps every contributor afterwards.
When it is used
After a defect or incident, once the immediate problem is closed.
Decision it supports
What becomes permanent as a result — a test, an invariant, or a runbook.
Extract
What shipped
Recovery logic that rebuilds scheduler state from the injection index plus the delivery event log.
What was expected
Messages with a terminal outcome excluded on restart; deferred messages restored with their retry timing intact.
What happened
Terminal messages were excluded correctly. Deferred messages were reinstated without their timer state, so the engine retried them immediately — the behavior a receiving provider reads as abuse. Nothing crashed.
Why the tests passed
They asserted message counts. The counts were right while the behavior was wrong.
Corrective action
Assert on timer state, not on the number that is easy to compare. The crash-recovery test now kills the process mid-send and checks retry timing survives.
What became permanent
A named requirement (deferred messages keep their retry timing across a restart) with the test that proves it, and a review habit: assert on the state that matters.
Sanitized actual artifact — A real defect and its correction, written up as the review that produced the permanent check.

10 artifacts

Program artifacts

What holds delivery together across parallel workstreams: sequencing, dependencies, risks, testing gates and the release decision.

Sanitized actual artifactgiMTA delivery engine program

Program timeline

Problem it solves: A timeline of dates hides the thing that actually governs the schedule: what has to be true before the next phase can start.
When it is used: Set at program start; the gate column is what gets reviewed, not the dates.
Decision it supports: Whether the program is ready to move to the next phase.

Extract

Program timeline
Phase	Scope	Gate to exit
Discovery	Trace real failure modes on the existing fleet, including the interrupted-send decision that had no good answer.	Failure modes documented and agreed as the problem to solve.
Recovery contract	Write the guarantee as a testable statement before any code exists.	Contract written; index plus event log proven sufficient to rebuild state.
Component build-out	Delivery, scheduling, spooling, signing, DNS and event logging as separate units with explicit contracts.	Per-unit test suites green; boundaries enforced by the dependency graph.
Test infrastructure	A local receiver and provider simulator so throttling can be reproduced on demand.	Provider throttling reproducible offline rather than waited for.
Canary	Partial-volume send compared against the legacy path.	Canary outcomes match expectations; rollback path rehearsed.
Cutover	New engine becomes the active sending path; legacy fleet stays operational as the reverse path.	Production smoke verified per sending identity before scheduled volume.
Legacy retirement	Migrate remaining campaigns off the legacy path and remove it.	Open — not started. Published as roadmap, not as delivered.

Sanitized actual artifact — The phases the engine actually went through, with the gate that ended each one. The final phase is still open and is labeled as such.

Sanitized actual artifactPlatform modernization

Workstream map

Problem it solves: Parallel work collides at the seams. Naming the workstreams and their edges is what makes the collisions predictable.
When it is used: At program kickoff, and revised whenever a workstream's scope moves.
Decision it supports: Who owns which decision, and where two workstreams have to agree.

Extract

Workstream map
Workstream	Scope	Owned by	Seam with
Campaign platform	Preparation, suppression, message generation, reporting.	Product owner (Liorry) with contract developers.	Delivery engine — the handoff contract and readiness gate.
Delivery engine	Import, spooling, scheduling, transmission, event log.	Product owner (Liorry) with AI-assisted implementation.	Campaign platform — bundle format; operations — cutover sequence.
Data and enrichment	Discovery, validation, enrichment for segmentation.	Product owner (Liorry).	Campaign platform — must never block a send.
Agent governance	Capability registry, budgets, staged rollout, audit trail.	Product owner (Liorry).	Every other workstream — what an agent may touch.
Operations and cutover	Canary planning, production verification, incident response.	Operations, with Liorry running the sequence.	All workstreams — release windows and rollback.

Sanitized actual artifact — The real split of the modernization work. Ownership names roles rather than individuals.

Sanitized actual artifactPlatform-to-engine handoff

Dependency map

Problem it solves: The dependency that hurts is the one nobody wrote down, discovered on the day it was needed.
When it is used: Maintained continuously; checked before every release window.
Decision it supports: What can start now, and what is waiting on something else.

Extract

Dependency map
Step	Depends on	Kind	If it is not ready
Campaign loaded	Audience resolved and filtered against suppression.	Internal	Preparation is incomplete; nothing is handed over.
Bundle imported	Message generation complete for every recipient.	Internal	Handoff blocked. Partial imports are guarded against duplicate sends.
Routing pre-warmed	Recipient domain resolution above its success floor.	External (DNS)	Start is refused. Sending into an unknown routing picture produces deferrals that look like throttling hours later.
Signing key verified	Key fingerprint recorded at import matches the key present at start.	Internal	Run stops. Unverifiable mail degrades reputation silently.
Workers ready	Capacity available for the sending identity.	Internal	Send waits rather than starting partially.
Event stream live	Outcome ingestion connected end to end.	Internal	Send is refused: outcomes that are not ingested cannot update suppression.

Sanitized actual artifact — The handoff readiness dependencies enforced by the platform's own gate — the same checklist the operations console displays.

Sanitized actual artifactPlatform modernization

RAID log

Problem it solves: Risks discussed verbally are re-litigated monthly and never owned. A log turns each one into a response someone is accountable for.
When it is used: Reviewed on a fixed cadence, and whenever a new risk is raised.
Decision it supports: Which risks are being actively managed, and which are knowingly accepted.

Extract

RAID log
Type	Item	Impact	Response
Risk	Two sending paths operating in parallel for an extended period.	Doubled operational surface; more ways to make a configuration mistake.	Accepted deliberately rather than forcing a hard cutover on live campaigns. Mitigated by keeping the legacy path as the documented reverse path.
Issue	Signing-key drift between import and delivery produced unverifiable mail with no error.	Silent reputation damage, cause several steps removed from the symptom.	Fingerprint recorded at import and compared at start; run refuses on mismatch. Now checked before every campaign start.
Risk	Feature-flag sprawl — over one hundred flags across config, environment and database.	Cognitive load and dead code paths that outlive their rollout.	Flags stay default-off without exception; lifecycle discipline is published as roadmap, not claimed as solved.
Assumption	Failures announce themselves.	Proved false. A stopped bounce processor looks exactly like a quiet week.	Replaced with a written catalog of real failure modes, each with a positive liveness check.
Dependency	Recipient-domain resolution before a send starts.	External and outside our control.	Pre-warm gate with a success floor; refuse to start rather than warn.
Risk	Discovery throughput limited by human review capacity.	A real ceiling on how fast prospect lists can be built.	Accepted. The alternative — an auto-import threshold — is a number that gets raised under deadline pressure.

Sanitized actual artifact — Real risks, assumptions, issues and dependencies from this program — several of which did occur and are written up in the case studies.

Representative reconstructionMoody's — technology program discovery

Stakeholder map

Problem it solves: In a large program the people who can stop the work are not always the people in the delivery meetings.
When it is used: Built during discovery; used to plan the communication cadence for the rest of the program.
Decision it supports: Who is consulted, who decides, and how often each hears from the program.

Structure

Stakeholder map
Group	What they need from the program	Engagement
Steering committee	Status, risks and alignment with the firm's target operating model.	Bi-weekly pack, prepared for senior management.
Business owners	Confidence that the future state matches how the business actually operates.	Workshops and interviews during discovery, documented and circulated.
Technology teams	Requirements precise enough to design against.	Use cases and user stories; design walkthroughs.
IT vendors	Clear scope, sequencing and evaluation criteria.	Roadmap coordination; scorecard-based evaluation across proposals.
Procurement	A defensible basis for recommending one proposal over another.	Vendor scorecard covering all proposals.
Program finance	Cost estimates that can be challenged and reproduced.	Estimation using parametric, t-shirt and bottom-up methods against delivery performance targets.

Representative reconstruction — Structure only. The groups and the bi-weekly steering cadence are as published on the enterprise case study; no individual, vendor or internal division is named, and no influence rating is attributed to a real person.

Representative reconstructionMoody's — technology program discovery
Steering committee update
Problem it solves
Senior stakeholders do not need the detail; they need the decisions that are theirs to make, stated in one page.
When it is used
On the committee's cadence — bi-weekly on the program this is drawn from.
Decision it supports
The decisions and escalations the committee has to resolve this cycle.
Structure
Where the program stands
Phase, what closed since the last pack, what is in flight. One paragraph, no detail that does not change a decision.
Decisions requested
The specific choices only this committee can make, each with options, recommendation and the consequence of deferring.
Risks and escalations
Risks whose response needs authority the program does not hold, with the mitigation already in progress stated so the item reads as managed rather than reported.
Alignment with the target operating model
How the current design maps to the firm's stated operating model, and where a gap is being carried deliberately.
Sequencing and dependencies
What the next phase needs to be true first, including anything owned by a vendor or another division.
Cost position
Estimate basis and what has changed in it — presented as method and movement, so the number can be challenged rather than accepted.
Representative reconstruction — The section structure of the pack, with the question each section answers. The original packs belong to the employer; no status, date, figure or milestone from them is reproduced here.

Representative reconstructionCredit Suisse — Loan IQ and back-office delivery

UAT plan

Problem it solves: User acceptance testing that starts without entry criteria becomes system testing with business users doing the work.
When it is used: Written during system integration testing, so UAT starts on a stable build.
Decision it supports: Whether the business accepts the change, and whether the release can proceed.

Structure

UAT plan
Phase	Entry criteria	Scope	Exit criteria
Test planning	Requirements signed off; process and data flows mapped.	Test cases written from requirements, traced back to the process step each one covers.	Coverage agreed with the business process owner.
System integration testing	Build deployed to the integration environment; interfaces available.	End-to-end flows across the servicing lifecycle, including upstream and downstream systems.	No open high-severity defect; every executed case has a recorded result.
Defect resolution	Defects logged with reproduction steps and severity.	Triage with technology, fix, and confirmation of what changed.	Fix delivered and linked to the defect; retest scheduled.
Retest	Fix deployed to the test environment.	Re-execution of the failed case plus the cases around it that the fix could affect.	Case passes; regression around the change is clear.
User acceptance testing	SIT exit met; business testers briefed; test data prepared.	Operations staff running their own real process on the candidate build.	Business sign-off recorded against each in-scope process.
Business validation	UAT signed off.	Confirmation that the intended operational outcome actually occurs — not only that the software behaves as specified.	Process owner confirms the outcome; release readiness reviewed.

Representative reconstruction — The plan structure and the phase gates used on that delivery. No loan product, module, transaction volume, test-case count or release date is reproduced — those belong to the employer.

Representative reconstructionCredit Suisse — Loan IQ and back-office delivery

Defect status report

Problem it solves: A defect count with no severity policy is a number people argue about instead of a decision aid.
When it is used: Circulated through the test cycle, and at the release readiness review.
Decision it supports: Whether the defect position permits sign-off.

Structure

Defect status report
Severity	Definition	Sign-off rule	Retest requirement
1 — Critical	Core process cannot complete, or an incorrect financial or operational result is produced.	Zero open at sign-off. No exceptions negotiated during the cycle.	Full re-execution of the failed case plus the surrounding flow.
2 — High	Process completes only with a workaround, or a control does not operate as specified.	Zero open at sign-off unless the business owner accepts the workaround in writing.	Failed case re-executed; workaround documented if accepted.
3 — Medium	Process completes correctly; behavior deviates from the requirement in a way users can absorb.	Fix or a dated commitment, agreed with the process owner.	Failed case re-executed before closure.
4 — Low	Cosmetic or documentation-level.	Recorded, batched, and not permitted to hold a release.	Verified at next convenient cycle.

Representative reconstruction — The severity policy and reporting shape. Counts are deliberately not shown: real figures belong to the employer, and inventing them would make the artifact worthless.

Sanitized actual artifactMailerClub and giMTA releases
Release-readiness checklist
Problem it solves
Release decisions made in a meeting drift towards optimism. A checklist makes the decision reviewable afterwards.
When it is used
Immediately before the go/no-go decision.
Decision it supports
Go or no-go, with the reason recorded either way.
Extract
- Scope confirmed: every change in the build is intended to be in it.
- Test evidence attached: unit, integration, end-to-end, and UAT sign-off.
- Defect position meets the severity policy, with any accepted workaround recorded.
- Every behavior change is behind a flag that defaults to off.
- Migration up and down paths both exercised.
- Rollback route stated, and the person who would execute it identified.
- Monitoring in place for the specific thing being changed, not just general health.
- Post-release verification defined: what will be checked, by whom, within what window.
- Stakeholders informed of the window and of what they should see afterwards.
- No-go criteria written down before the decision, not after.
Sanitized actual artifact — The checks actually applied before a release. Environment names, hosts and commands are omitted.

Representative reconstructionMoody's — technology program procurement

Vendor-evaluation scorecard

Problem it solves: Vendor selection defaults to the best presentation unless the criteria are agreed and evidenced before anyone presents.
When it is used: During procurement, applied identically across every proposal.
Decision it supports: Which proposal to recommend, and on what defensible basis.

Structure

Vendor-evaluation scorecard
Criterion	What is being judged	Evidence required
Functional fit	Coverage of the documented business requirements, not of the demo script.	Requirement-by-requirement response, with gaps stated rather than implied.
Operating-model fit	Whether the proposal works with how the firm actually operates.	Mapping to the target operating model, including where the vendor expects the firm to change.
Delivery credibility	Whether the plan can be delivered by the team proposed.	Named roles, sequencing, and comparable delivery evidence.
Integration and dependency load	What the firm has to build or change to make this work.	Interface inventory and the dependencies placed on internal divisions.
Cost basis	Whether the number can be reproduced and challenged.	Estimate method, assumptions, and what falls outside the price.
Risk profile	What happens if the vendor underdelivers.	Exit terms, transition support and single points of dependency.

Representative reconstruction — Criteria structure and scoring discipline. No vendor is named and no score is reproduced — the original evaluation belongs to the employer.

Want to see one of these in full?

The previews above are condensed. I am happy to walk through any of them in a conversation — including the requirements that turned out to be wrong and what replaced them.

Get in touch The case studies behind them

Product and Program Artifacts

Where these come from

On this page

Product artifacts

One-page PRD

Extract

Product requirements excerpt

Extract

User stories with acceptance criteria

Extract

Prioritization framework

Extract

Product roadmap

Extract

User journey and workflow map

Extract

KPI framework

Extract

Feature decision record

Extract

Launch checklist

Extract

Post-launch review

Extract

Program artifacts

Program timeline

Extract

Workstream map

Extract

Dependency map

Extract

RAID log

Extract

Stakeholder map

Structure

Steering committee update

Structure

UAT plan

Structure

Defect status report

Structure

Release-readiness checklist

Extract

Vendor-evaluation scorecard

Structure

Want to see one of these in full?