AI-assisted workflow · For evaluators
Evaluate the tools in one sitting
This page is for leaders deciding whether the tools are worth their team's time: Product Management leaders judging the quality of the documents, Product Operations leaders judging consistency and governance, and Delivery Systems leaders judging what lands in their tools. It points you to the three examples that matter most for your role, says what is built and what is only proposed, explains how your data is handled, and ends with an invitation to try the tools with fictional, public, or disguised material.
Positioning
What this is, and what it is not
Nine tools that take one initiative from customer research to a batch plan and a CSV file for Jira's bulk import, each passing its main output to the next inside the browser. AI drafts most of the documents, code runs the checks, and people revise the drafts and record a sign-off at each review point.
It is
- AI-assisted Product Management that covers three of six Product Operations areas: data collection, feedback management, and roadmap alignment
- A connected workflow: persona, journey map, intake, business cases, WSJF ranking, roadmap, BRD, backlog, batch plan
- Structured documents built on standard frameworks: Jobs to Be Done, demand/feasibility/viability assumptions, WSJF, RICE, MoSCoW, Given-When-Then acceptance criteria, and RAID logs
- Checked in code: requirement coverage, batch load, and dependency order are computed, with visible warnings
- A feeder for the systems you already use, ending in a CSV file for Jira's bulk import
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 how the work splits between PM and Product Operations ↗
- A replacement for Jira, Productboard, or Aha!: it drafts and checks the documents those systems track
- A team workspace: today it is single-practitioner, one browser at a time
- A finished product: live data connections and scheduled agents are proposals on the Proposed Architecture page, and none are built
- A black box: the sample runs are captured output (the Business Cases gallery is a worked example), and every computed check shows its work
Three roles, 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 does the math hold up?"
The batch plan sample run ↗
Batch loads and dependency ordering are recomputed in code, with visible warnings when a batch is over capacity or a story is placed in the same batch as, or an earlier batch than, a story it depends on. Baseline and worst-case estimates, a RAID log, and a build prompt for each story in a batch.
The backlog sample run ↗
Features prioritized with MoSCoW, with feature-level non-functional requirements; ordered stories with Given-When-Then acceptance criteria and dependencies; and a coverage check in code back to every business requirement.
The Jira handoff ↗
A bulk-import CSV with Summary, Issue Type, Epic Link, Priority, Original Estimate, Sprint, Acceptance Criteria, and Issue Links. Import is by CSV today; a direct write-back is specified on the Proposed Architecture page but not built.
System status
What is built, in development, and proposed
The Proposed Architecture page describes what a production version would add. Here is where each part stands today, so you know before you spend an hour.
Built and live
The nine-step workflow (persona through build planner), with handoffs between steps inside the browser; the Hoshin Kanri and V2MOM tool; captured sample runs; and the CSV file for Jira's bulk import at the end. Nine tools call the Claude API from your browser with your own key; every tool also works without one.
In development
The Product Ops Health Radar, a self-assessment of how well the product operations system is working.
Proposed
Live, read-only evidence connections (research repositories, support tickets, analytics, strategy documents),
approvals with sign-in and an audit log, the
direct Jira write-back,
post-release outcome checks, and
scheduled agents (signal synthesis, competitive monitoring, release notes). The
Proposed Architecture page ranks them; none of them 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 captured output, so you can judge the documents without typing anything.
More interested in how it is built? 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 you should know before you start
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 on the roadmap, with no date.
Jira integration is CSV import only
The workflow ends in a CSV file for Jira's bulk import. A direct write-back is specified but waits until approvals with sign-in and an audit log exist.
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 prototype built by one practitioner, with no service-level agreement. That's 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 their demand, feasibility, and viability 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 batch 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 tools to a small group of product management, product operations, and delivery leaders who'd like to try them on a fictional, public, 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 batch 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 say in what gets built next, including which proposed additions come first
- A direct line to the builder while the tools are still easy to change
- 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 role, 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.