Agentic PDLC · For PM, ProdOps & Delivery Leaders
Evaluate the system in one sitting.
This page is for leaders deciding whether the toolchain is worth their team's time: Product Management leaders judging artifact quality, Product Operations leaders judging standardization and governance, and Delivery Systems leaders judging what lands in their tools. It routes you to the three strongest proof points for your seat, states plainly what is built versus planned, explains how your data is handled, and ends with an invitation to try it on something real.
Positioning
What this is, and what it is not
Nine tools that run one initiative from user research to a Jira-ready sprint plan, each handing its primary output to the next through real, same-origin handoffs. It is the agentic drafting-and-gating layer of the product development lifecycle: AI drafts every artifact, code computes the checks, and a person signs off at every gate.
It is
- AI-assisted Product Management: three of the six Product Operations practice areas — Data Collection, Feedback Management, and Roadmap Alignment
- A connected chain: persona, journey map, intake, business cases, WSJF ranking, roadmap, BRD, backlog, sprint plan
- Structured artifacts on standard frameworks: JTBD, D/F/V, WSJF, RICE, MoSCoW, BDD acceptance criteria, RAID
- Guardrailed by code, not vibes: requirement coverage, sprint load, and dependency order are computed, with visible warnings
- A feeder for the systems you already own, ending in a Jira bulk-import CSV
It is not
- Full Product Operations: Release Operations (feature flags, beta testing, deployment comms), Enablement and Training, and Performance Analytics are out of scope — see the full PM vs. ProdOps breakdown ↗
- A replacement for Jira, Productboard, or Aha!: it drafts and gates the documents those systems track
- A team workspace: today it is single-practitioner, one browser at a time
- A finished product: the MCP integrations and scheduled agents in the network diagram are designed, not built
- A black box: every sample run on this site is captured real output, and every computed check shows its work
Three seats, three evaluation paths
Start with the question your role asks
Product Management Leader
"Would I put these artifacts in front of my exec team?"
Product Operations Leader
"Does this make my PMs consistent, and can I audit it?"
Delivery Systems Leader
"What lands in my systems, and will the math embarrass anyone?"
The sprint plan sample run ↗
Sprint loads and dependency ordering are recomputed in code, with visible warnings when a sprint is over capacity or a story lands before its dependency. Baseline and worst-case estimates, plus a RAID log.
The backlog sample run ↗
MoSCoW'd features with feature-level NFRs, ordered stories with BDD acceptance criteria and dependsOn sequencing, and computed coverage back to every business requirement.
The Jira handoff ↗
A bulk-import CSV with Summary, Issue Type, Epic Link, Priority, Story Points, Sprint, Acceptance Criteria, and Issue Links. Import is CSV-only today; a Jira write-back MCP is designed but deliberately not built yet.
System status
What is built, what is in development, what is designed
The network diagram shows the full target architecture. This is the honest snapshot of where each layer stands today, so you can calibrate before you invest an hour.
BUILT · LIVE
The nine-tool chain (persona through sprint planner) with real same-origin handoffs, Hoshin Kanri + V2MOM alignment, captured sample runs for the chain, and the Jira bulk-import CSV at the end of it. Nine tools call the Claude API from your browser with your own key; every tool also works without one.
IN DEVELOPMENT
The Product Operations Health Radar: the off-chain measurement layer that scores the health of the ops system itself.
DESIGNED · NOT BUILT
The MCP integration layer (research repos, support tickets, analytics, strategy docs), the scheduled and triggered agents (signal synthesis, win/loss, release notes, ROI validation), and the Jira write-back MCP. These appear in the network diagram as the target state; nothing on this site pretends they run today.
Data handling
Where your data goes
Your browser, your key, no middleman server
The AI-powered tools call the Claude API directly from your browser using an API key you provide. The key lives in session memory and clears when the tab closes. Your inputs go from your browser to Anthropic's API and back: there is no server of mine in the path, no account, and no database. Tool state and handoffs live in your browser's localStorage.
Want to evaluate without entering a key or any real data? Every tool has a no-key mode, and the sample runs linked above are fully captured output: you can judge artifact quality without typing anything.
Evaluating the engineering judgment behind this rather than the product itself? The technical notes cover the build system, the shared package, the versioned data contracts between tools, and this same trust boundary from the code's side.
Known limitations
What a candid vendor would tell you
Single-practitioner, per-browser
No accounts or shared workspaces. State lives in one browser's localStorage; clearing site data clears your runs. Team workspaces are a roadmap item, not a promise.
Jira integration is CSV import only
The chain ends in a bulk-import CSV, not a live connection. The write-back MCP is designed and deliberately deferred until the governance model around it is right.
Output varies run to run
Drafting is done by a large language model, so two runs on the same input will not be identical. The computed checks (coverage, load, dependency order) are deterministic; the prose is not.
Built and maintained by one person
This is a working system by a practitioner, not a funded product with an SLA. That is exactly why the beta feedback below matters.
Who I'm looking for
The first cohort is small, on purpose
The first cohort is limited to approximately 5–10 evaluators with experience in one or more of the following: Product Management, Product Operations, Technical Product Management, engineering or delivery operations, business analysis or requirements, architecture/security/QA/UAT review, portfolio prioritization, or Agile delivery/technical program management.
You do not need to endorse the concept. Skeptical feedback is more useful than encouragement.
Appropriate evaluation material
Use fictional, public, or sanitized information only
This is a single-user proof of concept, not a secure or production system.
Use one of these
- A fictional initiative
- A public product scenario
- A realistically disguised initiative, with names and numbers changed
- The supplied PetHealth scenario
Do not enter
- Confidential strategy
- Customer personal data
- Proprietary financials
- Source code
- Security architecture
- Credentials other than an API key entered into the designated key field
- Regulated or export-controlled information
Suggested evaluation path
About 60–90 minutes, starting at Initiative Intake
- Frame one initiative and two alternatives.
- Review the proposed epics and D/F/V assumptions.
- Generate one or two business cases.
- Compare the prioritization views and adjust the weights.
- Review the roadmap proposal.
- Generate the BRD for one funded epic.
- Review the backlog and requirement mapping.
- Review the sprint proposal and Jira CSV.
Starting with the Persona and Journey Map adds approximately 20 minutes. The beta runbook walks each stop in more detail, including what to watch for at every gate.
An open invitation
I'm opening the chain up to a small group of PM, ProdOps, and delivery leaders who'd like to try it on a real (or realistically disguised) initiative and share what they notice. Wherever the output would hold up in your organization, and wherever it would struggle, that's the read I'm hoping for.
What it looks like
- An hour or so, whenever it suits you: run one initiative from intake through sprint plan, with your own key or the sample mode
- Along the way, note where an artifact would pass review in your org and where it would fall short
- Share it however you like: a short call, an email, margin notes
What you'd get
- A real say in what gets built next, including which MCP integrations graduate from the diagram to reality
- A direct line to the builder while the system is still shapeable
- Early access to the team-workspace and integration work as it lands
Email me: rob.dull@gmail.com
Subject line "PDLC beta" and a sentence about your role is plenty. I'll reply with a suggested evaluation path for your seat, and a single pass with a few honest reactions is already a full contribution. Ready to start right now? The beta runbook is the step-by-step operator guide.