Rob Dull › Tools › AI ProdOps › Document Flow
AI-assisted workflow • Nine tools, shared records

The document flow, tool by tool.

What each of the nine tools takes in and produces, and where its output goes next. The tools share records stored in this browser: each one saves its output, and the next one picks it up. A step's primary inputs and outputs are the ones the next step depends on; secondary ones are used or produced alongside them. Most steps link to a saved sample run you can open without an API key; the Persona Generator is its own demonstration.

Proposed architecture: network diagram ↗ · New here? Start with the overview ↗
Toolchain: a record saved by an earlier tool
Sample evidence: fictional PetHealth records, no live connection
Human-supplied: entered by the person running the step
Recommended, not built
★ One of the four main outputs
Checked in code: recalculated by the tool, not asserted by the model
The four main outputs
STEP 06
Roadmap
Release windows over up to 18 months, funded epics first.
STEP 07
BRD
Standard-template business requirements for one funded epic.
STEP 08
Feature list
Features prioritized with MoSCoW, plus ordered stories.
STEP 09
Jira export
Bulk-import CSV: priority, estimate, batch, dependency links.
01
Four sample persona cards show the structure: JTBD statement, org context, key interactions, and relationship friction. No AI call; the tool doesn't build a persona from your own input yet.
Inputs
Primary
Human-supplied
Job statement (when, I want to, so I can) Role and organizational context
Outputs
Primary
Persona

Primary risk: A plausible composite can be mistaken for research.

Required review: Confirm which attributes are supported, inferred, or invented.

↗ Open tool No dedicated sample-run page: the tool itself is the demo.
02
A stage-by-stage canvas for actions, goals, touchpoints, emotions, and pain points, seeded from a persona, with an optional AI fill. Produces opportunity seeds for intake.
Inputs
Primary
Toolchain
Persona
Secondary
Sample evidence
Research repo (Dovetail/Notion) Customer support (Zendesk)
Outputs
Primary
Opportunity seeds
Secondary
Journey map (JSON / Copy for AI)

Primary risk: Team assumptions can be rendered with the visual authority of research.

Required review: Separate observed evidence from hypotheses.

03
Four AI calls: weigh one initiative against competing ones, break it into business and architecture epics, record each epic’s demand, feasibility, and viability assumptions, and propose how to measure benefits.
Inputs
Primary
Toolchain
Opportunity seeds
Secondary
Sample evidence
Internal comms Financial tracking External comms (NPS, reviews) Analytics
Recommended
Strategic KPIs
Outputs
Primary
Epics (business + architecture)
Secondary
D/F/V assumption map Benefits-realization plan

Primary risk: Missing portfolio context may be filled with plausible competitors, budgets, or benefits.

Required review: Validate the comparison set, epic boundaries, assumptions, KPIs, baselines, and proposed instrumentation.

04
Business Cases Justify
One business case per epic: value, cost, strategic alignment, and a rough effort estimate the Epic Prioritizer uses for job size.
Inputs
Primary
Toolchain
Epics (business + architecture)
Secondary
Sample evidence
Financial tracking External comms
Outputs
Primary
Business Case per epic

Primary risk: Generated cost, benefit, and effort statements can appear more certain than the evidence supports.

Required review: Replace unsupported estimates and financial precision with sourced values or explicit unknowns.

05
Two AI calls propose WSJF and RICE inputs for every epic from its business case. The tool ranks the epics and draws a funding cutoff. Changing a weight re-ranks the board at once and can move an architecture epic to #1.
Checked in code: every WSJF and RICE score is recalculated, and job size comes from the business case’s effort estimate.
Inputs
Primary
Toolchain
Business Cases (candidate records)
Secondary
Sample evidence
Internal comms (leadership weighting) Customer support (reach/severity)
Outputs
Primary
Epic Ranking + funding line
Secondary
RICE alternative scoring

Primary risk: Correct arithmetic can lend false authority to weak input values.

Required review: Own every input, weight, and funding decision.

06
One AI call sequences the ranked epics into release windows over up to 18 months, funded epics first. The dependency list stays short: named approvals, and architecture work another epic is waiting on.
Inputs
Primary
Toolchain
Epic Ranking + funding line
Secondary
Sample evidence
Delivery systems (sprint velocity) Internal comms (approvals)
Outputs
Primary
Roadmap

Primary risk: Release windows can imply capacity knowledge the workflow does not possess.

Required review: Confirm capacity, runway, dependencies, commitments, and rollout assumptions.

07
Two AI calls draft a standard-template BRD for one funded epic: scope, prioritized business requirements, high-level non-functional requirements, and an executive package. Each requirement is marked explicit, inferred, or assumed, and a named person confirms or defers each assumed one.
Checked in code: refuses epics below the funding cutoff.
Inputs
Primary
Toolchain
Roadmap
Secondary
Sample evidence
Internal comms (stakeholders, sign-off) Analytics (what's instrumentable today)
Outputs
Primary
BRD

Primary risk: NFR thresholds, costs, stakeholders, and sign-offs may be inferred or invented.

Required review: Confirm scope, requirement quality, evidence, assumptions, NFRs, financials, stakeholders, and approval authority.

08
Five AI calls turn the BRD into features prioritized with MoSCoW, stories with acceptance criteria and a dependency order, a solution outline, security and user-acceptance test plans, and documentation.
Checked in code: which business requirements each feature covers. A BRD with an unresolved assumed requirement is refused.
Inputs
Primary
Toolchain
BRD
Secondary
Sample evidence
Customer support (edge cases → acceptance criteria)
Organizational
DoR / DoD Style guide Current-state architecture
Outputs
Primary
Feature list (extended backlog)
Secondary
Security & UAT plan Developer & user docs

Primary risk: Identifier coverage can be mistaken for adequate design or requirement satisfaction.

Required review: Engineers, architecture, security, QA, and product stakeholders must assess substance.

09
Build Planner Deliver
Three AI calls draft MVP scope, a batch-by-batch plan, baseline and worst-case estimates, a RAID log (risks, assumptions, issues, dependencies), and a ready-to-use build prompt for each story in one batch, then export a CSV for Jira’s bulk import. A build prompt is an instruction written for whoever builds the story; the facts in it are copied from the plan in code, and the model writes only the short parts. A batch is a regular delivery cycle of 2 days to 2 weeks; the default is 2 weeks.
Checked in code: batch load against capacity, and dependency order. A story placed in the same batch as, or an earlier batch than, a story it depends on raises a warning wherever the plan is used.
Inputs
Primary
Toolchain
Feature list (extended backlog)
Also carries the Definition of Ready and Done from step 8. No sample evidence of its own yet.
Outputs
Primary
Jira bulk-import CSV
Terminal: downloads a CSV you import into Jira yourself; no further handoff.
Secondary
Batch Plan RAID log

Primary risk: The plan can only check the estimates and dependencies it was given. It cannot discover missing work or hidden capacity constraints.

Required review: Delivery leadership owns the plan and must inspect the CSV before import.

When something upstream changes

Each tool saves its output in this browser, newest first, one record per persona, initiative, or epic. The next tool lists the saved records, and you pick the one to build on. Each record also notes the exact version of every record it was built from.

A production version would add a history for each saved record, so an earlier version could be compared or restored, carry a person’s edits across a rerun, and share records across a team instead of one browser.

Outside the numbered steps
An experiment in laying a V2MOM onto a Hoshin Kanri X-matrix. It sits outside the steps because strategy is what the whole portfolio traces back to.
In development. A self-assessment of delivery and product operations health across nine dimensions, outside the steps because it looks across every initiative.
For technical evaluators: each handoff is a record in your browser’s local storage, which you can inspect in the developer tools after a run. Storage keys, data contracts, and the code checks are documented in the technical notes.