The best way to understand this project is to see it work: the two links above step through one real run and the finished assessment it produced. Both show the saved output of a genuine run. No live inference here, the process is token-intensive. But if you want to try it, reach out and we can make something work!
The problem
Product management is shifting from producing artifacts to orchestrating and editing them. The scarce PM skills are taste, evaluation criteria, and applying product strategy while balancing cross-functional constraints, not typing documents. Recruiters are saying this out loud now. Senior product hires at founder-led companies are expected to be self-serve, to generate and pressure-test what’s next, prototype it, and drive the decision conversation while maintaining speed (this can lead to burnout of PMs, but that’s a different conversation for another day).
In the past, the zero-to-approval phase of feature development could take weeks of a cross-functional team’s time. I wanted to see how much of that roundtable process could be compressed into one artifact that drives the conversation about value, trade-offs and risks, so you get to a build decision much faster.
What changes in the process
Today, most good teams already run product, design and engineering as a triad, so solution exploration has technical voices in it from the start. What slows things down is not the collaboration, it is the serialized milestones around it: each one has its own owners, meetings and dates to hit, and the full technical assessment usually waits until the PRD firms up, because it makes no sense to spend engineering cycles on something that might not survive. This prototyped engine collapses that coordination overhead into a single artifact that every function can review async, turning weeks of process into less than a day. The team’s time gets spent on one alignment conversation about next steps, anchored on the recommendation, instead of on assembling the inputs across six calendars.
The disciplines don’t disappear, and neither does the decision. They stop being meetings and queues that ultimately bottleneck progress.
What I built
A pipeline of 15 agents that takes an existing product plus a stated opportunity (a feature, an improvement, a hunch) and runs it through the proper product process end to end. Each agent is built on research into its own discipline: what that function actually cares about, and which parts of a product it owns. This cuts down on personal bias and blind spots and, with periodic updates, can keep them up to date on the latest trends, news, and systems available.
The input is deliberately small: a form with two required fields, plus optional screenshots and context. This is everything the engine needs to start:
From there, five stages run in a fixed order:
- Context: a product analyst and a design-language analyst build the ground truth, including reverse-engineering the product’s design system from screenshots
- Discovery: competitive research and user research, run in parallel
- Definition: a PM writes the PRD, then a designer, a prototyper, and a tech architect work from it in parallel
- Risk sweep: six independent auditors (business viability, legal, accessibility, ethics and trust/safety, privacy and security, operational readiness) attack the artifacts, not the idea
- Synthesis: a final agent assembles the risk register, preserves the disagreements between agents, and writes a one-page verdict
Every run produces the same structured package, so a reviewer always knows where to look:
NOTE: I built this engine to be product agnostic. Ideally in an organization, this engine would be hooked up to existing company context to produce the most accurate output (documentation, design systems, code, infrastructure, etc.)
The judgment layer
Agent scaffolding is a commodity. Anyone can prompt fifteen personas. What makes this worth showing is the opinionated layer on top:
- Rubrics. Every agent has an explicit definition of done, and of what lazy output looks like.
- Kill conditions. Every agent is licensed, and instructed, to return negative verdicts. A pipeline that never says “don’t build this” is a toy.
- A shared risk contract. Every agent, artifact-owner or not, ends its output with risks in one format, with severity and confidence and a named owner. The register assembles mechanically from those blocks, so nothing depends on an agent remembering to be honest at the end.
- Handoff contracts. Every artifact ends with open questions for the team that would own that discipline. These are inputs to collaboration with design, engineering, and legal, not replacements for it.
- Disagreements are preserved, not averaged. When the business-viability auditor and the PM agent reach different conclusions, the synthesis states both positions and takes a side with reasoning. That tension is the most valuable thing the pipeline produces as it sets the stage for an active discussion.
The worked example: Claude’s mobile menu
To test it, I fed the engine a small but potentially flawed improvement: the Claude mobile app’s default open on launch is ‘Chat,’ and the navigation drawer assumes what matters most to a user, with no way to change it. The entire input was two paragraphs and these two screenshots:
About 500KB of assessment came back, including draft versions of product, design and technical specs, as well as a live prototype. This is the actual file the prototyper agent produced, playable here: open the menu (top left), tap Edit, and drag.
What’s in it is the reason I’m showing this publicly:
- It cut a third of my request before writing a line of requirements. I asked for reorder, hide, and a default-landing setting. The research showed default-landing had no positive precedent anywhere and had triggered real backlash in comparable products, so the PRD killed it, with the reasoning shown.
- The agents argued, on the record. Business viability said fund only the cheap validation, since all three success metrics were UX proxies and “none of them is a dollar.” The PM, designer, and architect endorsed build sequencing. The synthesis kept both positions and added a churn metric as the build gate. Design recommended free-drag; competitive research and tech architecture recommended pin-to-top; the synthesis picked pin-to-top for the beta with the upgrade path named.
- The verdict on my own idea was “don’t fund the build yet.” Instrument first, prove the target cohort exists, then run a retention experiment. 7 high-severity risks, each with a named owner and next step. The engine correctly sized a nav-drawer tweak as “ship an experiment, not a research program,” and a process that recommends proportionate effort is more credible than one that treats every idea as a moonshot.
The deliverable reads like a real proposal package, verdict first, severity counts on top:
Step through the full run, including the intake form exactly as I filled it, or read the finished assessment the way a stakeholder would receive it.
How I measure success
Not by whether the artifacts look impressive, but by whether the process behaves like a real one:
- Does it say no? The test run’s verdict was a conditional no. Every agent filed real risks; none returned “looks great.”
- Does it surface disagreement instead of consensus mush? Five distinct on-the-record disagreements survived to the summary.
- Is the output proportionate? A small feature got a small recommendation: a one-week instrumentation task, not a quarter of roadmap.
- Would the receiving teams recognize their own discipline? Each artifact ends with the open questions a real designer, engineer, or counsel would ask next. That’s the bar, and it’s also the honest limit: this passes the sniff test as a starting point, not as their finished work.
Product takeaways
- The PM role in this loop is editor, not author. My real work was the rubrics, the kill conditions, and deciding what the synthesizer was allowed to average away (nothing). The typing was never the scarce part.
- The disagreement view is the product. One model asked for a PRD gives you smooth, confident, unexamined output. Fifteen agents with different rubrics give you an argument you can inspect. That difference is exactly the difference between a document and a decision process.
- It trades meeting overhead for async review. The package lands with each function’s open questions already framed, so the PM walks in prepared to argue for, argue against, or drop the proposal entirely without having to ping a single soul. Design, engineering, and legal get their priorities cleanly in writing and can react on their own time. The one meeting that still has to happen is the one that matters: deciding what to do next.
- This is a showcase, not a production tool. This proves understanding of the process. Deploying it for real product decisions would require the actual company context and domain experts to help build it. Some of the risks are visibly based on generalized knowledge, not company know-how or experience.
- Ideally, the real version is one where each function’s owner authors their own agent. Legal writes what good legal review is. Engineering writes what good architecture review is. Design writes what good critique is. The PM then has a standing council to run any proposal through before it reaches a human decision, carrying the organization’s real standards instead of a model’s generic ones. That turns this from a clever personal tool into an operating model a company could adopt.
What’s next
- One clear miss is how the solution ties to product strategy. Technically, this can be added ad hoc in the ‘Why Now’ section. However, embedding the company strategy, individual goals, and measurable targets into a tool like this could enhance the assessment by including quantitative targets that become the basis of feature evaluation if the idea is shipped. This could easily be done by adding another agent that acts as the product exec or expanding the role of the business viability agent.
- Hook this up to an existing company’s context and evaluate its performance. This tool will need a set of evals to determine if it is actually saving time and improving decision-making, but test data makes that difficult, so the true test would be in a live environment.
- See if the output can assess feature size and complexity and adjust output based on risk. For example, if it is a simple two-way door UI change, the output should be much smaller and geared towards a test that most folks can get behind due to low risk. If the change is a large complex solution that touches the primary product surface and could have adverse impacts to the business, the output should reflect that severity. I have observed teams spending too much time debating the small stuff and not enough time digging in on the large consequential decisions. The rigour shown through the output should reflect that.
- If someone is interested in trying it, a passcode-gated live run, handed out per conversation, so someone can drop in their own feature idea and watch the pipeline execute for real with the cost bounded.