I treated AI like two very different teammates; one as a product manager to clarify the requirements, and one as a junior engineer to write the code. That simple shift not only sped up the project, but it also completely changed how I think about my role as an engineer.
The Problem
My wife needed a Gravity Forms plugin that could:
- Take a UK postcode.
- Zoom to that location on a map.
- Let the user draw a boundary on that map.
- Save it as an image.
- Attach it to the form submission.
I know the Google Maps API pretty well, and I’ve built plenty with Gravity Forms.
The challenge wasn’t learning; it was stitching it all together without drowning in documentation, API quirks, and bug-hunting.
That’s usually a day’s work.
Step 1: AI as a Product Manager
I started with ChatGPT, but I didn’t tell it to write code.
I told it to act like a product manager and create a Product Requirement Document (PRD).
It didn’t just dump a spec.
It did what a good PM would do: ask for clarity.
- What format should the image be saved in?
- Should the map library be replaceable?
- Should the image be visible in admin view or just stored?
By the end, I had a PRD that nailed:
- The what.
- The why.
- What’s not included (critical for avoiding scope creep).
It was faster, sharper, and easier to hand off than any PRD I’ve written manually.
Step 2: AI as a Junior Engineer
That same day, GPT-5 launched.
I opened Junie in PhpStorm (think Cursor, with the JetBrains IDEs), set it to GPT-5, and fed it the PRD with the following prompt:
“Build this plugin based on the requirements in the PRD. Ask if something doesn’t make sense.”
For this part, I treated AI like a junior engineer, capable but reliant on my clarity and occasional corrections.
The results of this were astounding:
- First pass: functional, but the map polygons weren’t saving to the image.
- After five short clarifying prompts, it worked perfectly.
Total time from PRD to working plugin: two hours.
The Product-Driven Influence
I’ve been reading Product-Driven by Matt Watson, and it’s shifted my thinking.
Watson’s core message is “context over code, outcomes over output“, which fits this experiment perfectly.
The PRD-first approach gave AI the same clarity and reasoning I’d give to any human teammate. That’s why it worked.
The Bigger Shift: Engineers as Product Managers for AI
Here’s my personal view: As AI gets better at coding, and as we get better at guiding it, we’ll spend less time writing code ourselves.
We’ll spend more time acting like product managers:
- Understanding the problem.
- Defining outcomes and constraints.
- Giving AI the clarity to deliver the right solution.
We won’t just “write code”, we’ll shape solutions.
And that shift could unlock huge efficiency gains for us as an agency.
Takeaways
- Use AI in two roles: product manager for requirements, junior engineer for code.
- Lead with a PRD: it forces clarity and context.
- Think product-first: our value lies in defining the solution, not just typing it out.
This isn’t about AI replacing us. It’s about us redefining our role and spending our time on the work that matters most.
Here’s everything I used in this experiment:
The PRD – View here
The full Product Requirement Document, generated by AI, including scope, reasoning, and exclusions.
The Finished Plugin – View here
The working Gravity Forms plugin that lets users draw a boundary on a map and submit it as an image.
The PRD Prompt – View here
The exact prompt I used to guide AI into acting like a product manager and asking the right questions.