Limited Evaluation Beta Runbook

Use fictional, public, or sanitized information only

This is a single-user proof of concept, not a secure or production system. Do not enter confidential strategy, customer personal data, proprietary financials, source code, security architecture, or regulated or export-controlled information. A realistically disguised initiative, with names and numbers changed, works just as well for evaluating the tools.

Before you start

What to bring

Two tiers. Tier 1 is enough to run the chain end to end and judge the mechanics. Tier 2 makes the run a fair test of output quality, because a few of the steps below make up plausible-sounding detail when you don't give them specifics. Bring what your time allows; more specific input gives a fairer test.

Tier 1 · Minimum

~5 min prep

One initiative, one paragraph

A problem from your organization with the names and numbers disguised, or a fictional or public one: what's broken, who it hurts, and one number that shows it matters.

An Anthropic API key (optional)

From console.anthropic.com. No key? Walk the same path through the captured sample runs instead; you'll evaluate output quality, just not on your own initiative.

One browser, kept open

The chain hands work between tools inside your browser's storage. Stay in one browser for the session. You can download your whole run as a file at any point (see below), so nothing is lost if you stop early.

Tier 2 · Recommended for a fair test

+15–20 min prep

Without the items below, Initiative Intake (step 03) will invent plausible-sounding competing initiatives and a budget assumption to fill the gap, because that's what the prompt is designed to do when it's given nothing specific. That's a reasonable fallback for a five-minute look, but it isn't a fair test of the quality of the tool's draft and structure. With specific input you're testing the tool; without it, you're mostly testing what the model makes up.

Two named competing initiatives, each with a one-line reason they lose the capacity to yours. This gives the portfolio-tradeoff step something to weigh instead of letting it improvise.
A quote, figure, or budget line (disguised if needed), pasted below your paragraph as an evidence line so the model cites it with provenance instead of assuming it. The format:
[REF-SUPPORT-01 support-ticket] "Members message support asking where their claim is; we can't tell them anything past 'still processing.'"
Any short id and kind works, e.g. [REF-BUDGET-Q3 financial-tracking] or [REF-NPS-091 external-comms]. This format isn't shown in the tool itself (the evidence chips you see are sample data), so your own evidence only works if you paste it this way. A citation like this associates a claim with the record you supplied; it does not verify that the record itself is accurate.
A one-line budget ceiling or OKR the initiative should support, so the tradeoff has something specific to work from.
If you'll reach Backlog Builder (step 08): a sanitized excerpt of your organization's Definition of Ready or Definition of Done, a style-guide snippet, and one general line about your current architecture (no security details). All three are optional fields in that tool and make the non-functional requirements and solution outline noticeably more specific.
If you're starting from the top (steps 01–02): persona or interview notes for the Journey Map input, with names and personal details removed, rather than a cold start. As the tool's own placeholder text says, the more specific the notes, the better the suggestions.

The path · 60 to 90 minutes

Intake to batch plan, seven stops

This is the recommended beta path. It starts at Initiative Intake (step 03) rather than the very top of the chain: personas and journey maps are worth a look later, but the stretch from intake to the Jira file is where the tools do most of their drafting. Each stop names what to watch for, because where the output falls short of your organization's standards is the feedback this beta is for.

Initiative Intake · ~15 min

Paste your one-paragraph initiative and run the four-step chain: portfolio tradeoff, epic decomposition, riskiest assumptions, benefits realization. Review each step before running the next; edit anything that's wrong before it flows downstream.

Watch for Would the demand, feasibility, and viability assumptions hold up with your stakeholders? Do the epics fit your initiative, or are they generic? What did the model introduce that was not in your input?

Business Cases · ~10 min

One click on a framed epic pre-fills the case form. Generate a case for one or two epics; you're judging quality, so you don't need all of them.

Watch for Would you put this case in front of your sponsor? Is the rough effort estimate credible enough to anchor prioritization? What did the model introduce that was not in your input?

Epic Prioritizer · ~10 min

Run the two AI calls that propose WSJF and RICE inputs for your cases, then adjust the weights. The board recalculates as you go, including the funding cutoff.

Watch for Does the ranking hold up when you raise risk-reduction? Would the ranking hold up in your funding discussion? What did the model introduce that was not in your input?

Roadmap & Milestones · ~5 min

One click carries the ranking here, and one AI call places the funded epics in release windows with a short list of dependencies.

Watch for Are the dependencies real blockers? What did the model introduce that was not in your input?

Business Documents · ~10 min

Generate the BRD for your funded epic. The tool refuses epics below the funding cutoff; that refusal is a deliberate check.

Watch for The requirements core and the executive package: which sections would your organization keep, cut, or argue about? Flag any NFR threshold, financial figure, stakeholder name, or sign-off that reads as more certain or more approved than the evidence supports. What did the model introduce that was not in your input?

Backlog Builder · ~15 min

The BRD becomes features prioritized with MoSCoW and ordered stories with Given-When-Then acceptance criteria. Requirement coverage is checked against the BRD in code, and the tool asks a named person to confirm or defer each assumed requirement before it accepts the BRD.

Watch for Would your engineers pick up these stories? Are the acceptance criteria testable or vague? What did the model introduce that was not in your input?

Build Planner · ~10 min

MVP scope, a capacity-and-dependency-checked batch plan, baseline and worst-case estimates, a RAID log, a build prompt for each story in one batch, and the CSV file for Jira's bulk import that ends the workflow.

Watch for Do the batch loads and the worst-case gap reflect how delivery actually goes where you work? What did the model introduce that was not in your input?

If you have another 20 minutes

Start from the top instead: open a sample persona (01), build a journey map from it (02), and let its pain clusters seed the intake. That's the full chain, research to Jira.

Data handling

Where your initiative goes

Your browser to Anthropic and back; nothing else

Your key lives in session memory and clears when the tab closes. Your inputs travel from your browser to Anthropic's API and back; there is no server of mine in the path, no account, and no database. All saved artifacts live in your browser's localStorage. If your initiative is sensitive, disguise the names and numbers; the chain works just as well on a realistic fiction. The full statement, including what is and isn't verifiable, is on the technical notes page.

Saving and sharing your run

The run file: your save button and your feedback channel

Download early, download often

At the bottom of every tool there's a Run file row with Download and Load buttons. Download snapshots everything the chain has saved, from any tool, into one JSON file. Load restores it in any browser, on any machine. Download whenever you finish a stage; if a cache clear or a browser switch would otherwise lose your session, the file gets it all back.

It's also how you can send me your run: attach the JSON to your feedback email and I can load your exact state, see what you saw, and debug or improve from your actual run instead of a screenshot. The run file can contain everything you entered and everything the chain generated, so review it before sending and remove anything you wouldn't otherwise share. Notes alone, without a run file, are a complete response too.

What to note as you go

Useful feedback

You don't need a structured report. A few honest sentences on any of these is a full contribution:

Where a document would pass review in your organization as is, and where it would be sent back for rework. Name the section.
Anywhere you stopped trusting the output, and what triggered it.
Anywhere you got stuck, confused, or hit an error. A run file plus one sentence is better than a formal bug report.
The one thing that, if added or fixed, would make you run a second initiative through it.

Done? Send it in.

Email your notes, with the reviewed run file attached if you're willing, with subject "PDLC beta". I read and reply to everything, and a single pass with a few honest reactions is exactly what I asked for.

rob.dull@gmail.com

This is a working proof of concept suitable for portfolio review and limited evaluation with fictional, public, or sanitized information. It is not suitable for confidential enterprise work or production use.

The beta runbook: one initiative, one sitting