Rob Dull/ Tools/ AI ProdOps/ Case study
Case study · Captured runs

One initiative through all nine tools

This page follows one fictional initiative through all nine steps, from a persona to a batch plan and a CSV file for Jira's bulk import. Each step passed its output to the next with one click, inside the browser, and each step links to the run it produced, so you can judge the output itself. Seven of the nine steps call an AI model to draft; the persona needs no AI call, and the journey map's AI fill is optional. In real use, people revise those drafts and approve them at each gate.

Evidence disclosure

PetHealth is fictional. The company, people, source records, metrics, approvals, and operating environment in this example were created for demonstration. The displayed artifacts use the structures produced by the tools and are intended for evaluation.

The example contains four kinds of information: scenario facts (fictional inputs intentionally supplied to keep the test coherent, such as the 22% support-contact baseline), fixture evidence (fictional records with source-like identifiers used to test provenance and propagation), model-generated content (draft requirements, assumptions, estimates, NFRs, risks, and narrative), and deterministic results (selected calculations and structural conditions recomputed in code).

A fixture citation shows that a generated claim was associated with a supplied record. It does not make the fictional claim independently true. The review gates shown in this case are modeled checkpoints, not records of approvals by real PetHealth employees.

The scenario

PetHealth is a fictional mid-size pet insurer with a common problem: members don't trust the claims process. Claim-status questions account for 22% of all support contacts, members describe the wait after submitting a claim as a black hole, and leakage (money lost to errors and fraud in claim adjudication) cuts into margin. The company context, evidence, and competing priorities stay the same across every tool, and each tool takes its input from the one before it, so no step gets a hand-tuned prompt.

Each artifact below is output captured from the tools themselves.

1 → 5
One funded initiative, split into five epics, each with its riskiest assumptions
8
Business requirements in the business requirements document (BRD), each traced to later steps
7 / 15
Features prioritized with MoSCoW, and ordered stories, in the backlog
8 of 8
Business requirements mapped to at least one feature, checked in code
01
Enterprise PersonaDiscover
The tool's built-in PetHealth sample: a job statement and role context with a prepared persona card. This step makes no AI call, and the tool doesn't build personas from new input yet.
★ What came out

Marcus Chen, a software engineer and PetHealth member, whose quote frames the initiative: "I just want to know it's working." The card carries his Jobs to Be Done statement, his comfort with each channel, key interactions marked with friction badges, and an estimate of what his unmet job costs the organization.

Handoff: the persona is the starting point for the journey map.
What to evaluate: Does the persona clarify the job and operating context, or merely add plausible detail? Which attributes would require real research?
Open the tool, which shows this example ↗ ✋ Human gate: the PM approves the persona before mapping
02
Journey Map BuilderMap
Marcus's journey across pre-enrollment, account management, claims, and renewal, with a sentiment curve you can drag and pain points for each stage. The lowest point falls in the wait after a claim is submitted, which matches the scenario's support data. Filling the map with AI is optional.
★ What came out

A stage-by-stage map whose clusters of pain points become opportunity seeds: short statements of where the experience breaks and what it costs, exported to the next step.

Handoff: the opportunity seeds go to initiative intake.
What to evaluate: Is the pain point actually supported by evidence, and does the map distinguish observation from interpretation?
03
Initiative IntakePortfolio tradeoff
Four AI calls weigh Claims Transparency & Leakage Reduction against two competing initiatives: Renewal & Pricing Experience Revamp and the Vet-Clinic Partner Portal, using cited strategy, budget, and demand evidence. The funded initiative is then split into five epics: customer-facing business work, and the architecture work it depends on.
★ What came out
  • EPIC-01 Auto-Adjudication Engine Modernization
  • EPIC-02 Reimbursement Payout Upgrade
  • EPIC-03 Real-Time Claim Status Tracking
  • EPIC-04 Vet-Clinic Direct Submission Integration
  • EPIC-05 Fraud & Leakage Analytics

Each epic lists its riskiest demand, feasibility, and viability assumptions, and a plan for measuring its benefits, including the tracking that would need to exist first. The main benefit target: claim-status share of support contacts falls from 22% to ≤12%.

Handoff: each epic goes to Business Cases, one case per epic, with its demand, feasibility, and viability risks.
What to evaluate: Are the alternatives and epic boundaries credible? Which assumptions are useful risk framing, and which are invented context?
View the captured run ↗ ✋ Human gate: the PM and stakeholders approve the intake
04
Business CasesJustify
One case per epic, drafted by AI: value, cost, strategic alignment, cost of inaction, and a rough effort estimate. The prioritizer uses that estimate as its job-size input, so the ranking and the funding discussion work from the same number.
★ What came out

Five business cases in a standard format, including the Real-Time Claim Status Tracking case that the rest of this page follows.

Handoff: the cases become the prioritizer's list of candidates.
What to evaluate: Would the case support an investment conversation after correction, or does its format overstate the quality of its evidence?
View the example gallery (Claim Status tab) ↗ ✋ Human gate: the sponsor approves each case
05
Epic PrioritizerRank
Two AI calls propose WSJF and RICE inputs for all five epics, and code calculates the scores, with customer-facing and infrastructure work on the same board. The weights are editable and the board recalculates as you change them: raise the weight on risk reduction and an architecture epic can move to the top without another AI call. Someone still has to own the weights.
★ What came out

A ranking with a funding cutoff. Real-Time Claim Status Tracking falls above it, so it becomes the epic the rest of the workflow plans.

Handoff: the ranking and the funding cutoff go to the roadmap.
What to evaluate: Are the inputs defensible? Does one board improve the funding conversation, or create false comparability?
06
Roadmap & MilestonesSchedule
One AI call places every prioritized epic in release windows over up to 18 months, funded epics first and the rest as capacity frees up. It keeps dependencies to a minimum, only named approvals and architecture work an epic truly needs, so the roadmap stays easy to read for stakeholders.
★ What came out

A roadmap, one of the workflow's four main outputs.

Handoff: the roadmap decides which epic gets a business requirements document.
What to evaluate: Does the roadmap preserve priorities and dependencies without implying knowledge of capacity that was never supplied?
07
Business DocumentsSpec
Two AI calls draft a BRD for the funded epic: scope, prioritized business requirements, and high-level non-functional requirements (NFRs), plus an executive package (summary, objectives, stakeholders, cost-benefit, sign-off). Each requirement is marked explicit, inferred, or assumed. Code refuses to write a BRD for an epic below the funding cutoff.
★ What came out

The BRD for Real-Time Claim Status Tracking with eight business requirements (BR-01 through BR-08), an assumptions section, and the executive sign-off package.

Handoff: the BRD is the main input to the backlog.
What to evaluate: Which sections are reviewable, which need correction, and which should be omitted until evidence exists?
View the captured run: BRD with Assumptions ↗ ✋ Human gate: architecture, security, and business review
08
Backlog BuilderPlan
Five AI calls turn the BRD into draft delivery documents: features, stories, a solution outline, security and user-acceptance test plans, and developer and user documentation. Requirement coverage is checked in code: every business requirement has to map to at least one feature, and the tool flags sizing that differs from the earlier estimate. It also won't accept a BRD until a named person confirms or defers each assumed requirement.
★ What came out
  • 7 features prioritized with MoSCoW (FEAT-01 to FEAT-07), with feature-level NFRs and refined sizing
  • 15 ordered stories with Given-When-Then acceptance criteria, builder-day estimates (no story above 8 days), and dependencies
  • Coverage checked in code: 8 of 8 business requirements mapped to features, with the difference between refined and rough sizing flagged
Handoff: the backlog, with its dependencies, goes to batch planning.
What to evaluate: Does identifier coverage reflect meaningful satisfaction of the requirement? Would engineering consider the stories sufficiently grounded and testable?
09
Build Planner & Jira ExportDeliver
Three AI calls turn the backlog into a delivery plan: MVP scope from the Must-have features, a batch-by-batch plan, baseline and worst-case estimates with what drives the difference, a RAID log (risks, assumptions, issues, dependencies), and a build prompt for each story in one batch (the sample shows Batch 1). A batch is a regular delivery cycle of 2 days to 2 weeks; this run uses the 2-week default. Code rechecks batch load and dependency order: an over-capacity batch, or a story placed in the same batch as, or an earlier batch than, a story it depends on, raises a visible warning wherever the plan is used.
★ What came out

The delivery plan, plus the workflow's last handoff: a CSV file for Jira's bulk import, with Summary, Issue Type, Epic Link, Priority, Original Estimate, Sprint, Acceptance Criteria, and Issue Links columns. A person reviews it and imports it into Jira. The stories in the chosen batch carry their build prompt in the description: context, the requirements and acceptance criteria copied from the plan, dependencies, a suggested approach, checks, and what to leave alone.

What to evaluate: Are the estimates credible? What work or constraints are missing? Would the CSV import cleanly and preserve the intended relationships?
View the captured run ↗ ✋ Human gate: the product owner (smaller work) or product manager (feature work and larger) approves the plan before import

What this run demonstrates

  • Each tool used the previous tool's main output, unedited, passed along inside the browser
  • Traceability holds across the workflow: a support-contact figure from the scenario shows up as a benefits target in intake, a requirement in the BRD, and covered stories in the backlog
  • Business and architecture work are ranked on one board
  • The code checks worked: the funding-cutoff refusal, the coverage check, and the batch-load and dependency warnings all triggered where expected

What it does not claim

  • PetHealth is fictional. This shows the workflow running end to end; it is not a customer deployment
  • No one approved anything at the gates; they are modeled checkpoints. In real use, people revise the drafts and approve them at each gate
  • Model output varies from run to run; the code checks are the repeatable part
  • There were no live data connections: the run used a supplied set of sample evidence. Live, read-only connections are a proposed addition (see Proposed Architecture)

Known corrections and open questions

I'll update this list as outside evaluations come in. Current issues visible in the example: