Back to selected projects

I turned a requirements maze into an agent that starts from your PRD

Every PM had to dig through a wiki, fill out a form, track down contacts, and create work by hand. In a three-day Microsoft hackathon, I built a package of skills and workflows that starts from the PM's PRD instead. The agent pulls out what it can, asks about the rest, and gives the PM a report to check. Nothing else happens until the PM says so.

WinnerBest Use of AI, for our three-person team
3 daysFrom idea to working proof of concept
SharedAcross the PM org, and fed into its skills and agents

The problem

Every time a PM wanted to turn a product idea into assigned work, they went through the same manual steps.

They searched a wiki with more than 50 required "fundamentals," filled out a form to figure out which ones applied, tracked down the right groups and contacts, and then created and assigned the work by hand.

The information was all there. But every PM had to find it, interpret it, and route it again from scratch. The form didn't save any of that work. It just told you where to go look.

My role

The idea and the plan were mine. I built the skills and workflows, wrote most of the agent instructions, designed the whole interaction, and made the demo video for our presentation.

Our PM teammate knew the domain. They walked me through how the wiki, form, requirements, routing, and contacts worked, wrote test PRDs, and helped hook the agent up to our runtime and work tracking.

So I was the designer and also the one driving the product. I defined the problem, decided how the interaction should work, and took it from idea to demo.

Don't fix the form. Skip it.

We looked at keeping the wiki as the main experience, simplifying the form, building a standalone app, and doing a different hackathon idea altogether.

A shorter form wouldn't have fixed much. The PM already had a PRD with most of the context in it. Making them type it all in again was busywork.

So we turned the wiki and form into source material for the agent. It starts with the PRD, figures out what it can, and only asks for what's missing. The PM goes from filling in data to checking it.

Start with what the PM already has. The PRD does most of the work. The agent asks only what's missing, then shows a report to confirm.

How the agent works

The agent reads the PRD and pulls out what it can: feature type, release stage, schedule, dependencies, what other teams need, and likely contacts.

When the PRD doesn't say enough, it asks a specific follow-up question. It never asks the PM for something it already found.

Then it writes a draft report with:

  • The fundamentals that apply
  • Where each one came from, or why it applies
  • Who to contact
  • The basics of each requirement
  • The follow-on work it can help set up

The PM can ask the agent for more detail on anything before confirming.

Product manager

Here is the PRD for a new feature in an upcoming release.

Agent

I found the feature type and release stage. Does this experience depend on an existing team capability?

Product manager

Yes. It uses a shared platform capability.

Draft reportApplicable fundamental

Requirement summary, rationale, responsible contact, and proposed follow-on work.

A redrawn example. The agent combines the PRD with one answer, then shows its reasoning and proposed work for review.

Approving the report isn't approving everything

How confirmation works was the most important safety call.

First the PM checks and confirms the full report. Only then does it get saved. After that, the agent asks about setting up work and other follow-ups one at a time.

Saying yes to the report doesn't let the agent go do everything. The PM decides each step that matters.

  1. 1Read PRDExtract available context
  2. 2InferFind fundamentals, dependencies, and contacts
  3. 3AskOnly what's missing
  4. 4ReportShow rationale, contacts, and proposed work
  5. 5VerifyPM reviews, corrects, and confirms
  6. 6ActStart follow-ups one at a time
Two checkpoints. The report is approved and saved before the PM picks any follow-on action.

Testing it in three days

We ran it against sample PRDs our PM wrote. We checked whether the agent pulled the right context, asked useful questions, and produced a report you could actually work from.

The judges said it could save PMs hours of wiki searching, form filling, contact hunting, and manual work setup. That's their read on the opportunity, not something we measured in production.

We won Best Use of AI.

What happened next

What we built in three days was a proof of concept. It's changed a lot since.

After the hackathon, it was shared across the PM org and fed into a bigger set of PM skills and agents. That work standardized more of the PM workflow across our business group, and multiple teams keep adding to it.

Our project didn't build all of that on its own. But it was an early piece of it. It showed a different way to handle the fundamentals and gave teams something real to build on.

01Proof of conceptWorking skills and workflows, tested in three days
02Wider PM sharingSomething real for teams to try and extend
03Evolving systemShared skills and agents, built on by multiple teams

What I learned

The big call wasn't putting chat on top of a form. It was changing where the work starts: begin with the PRD, ask only what's missing, and get a yes before anything important happens.

I think it also showed how fast you can get somewhere when the interaction is clear. Three days was enough because we stuck to one repeated problem, one good source of context, and one safe path from understanding to action.