Real world AI acceleration of Product Managers and teams: from idea to presentative solution to production
In a recent interview with Lenny, my go-to product management podcast, Albert Cheng, a product and growth leader at some of my favorite apps (Duolingo, Chess.com, Grammarly) talks about how beneficial prototyping is, getting from idea to representative solution. He also expresses some frustration at the lack of a complete workflow where PMs (and other functions) can make changes in the application that ship to production. I'm here to share how our product team goes from idea straight to production at Netlify and it's a workflow you can use, too.
In many ways, this echoes the original Stackbit vision, my startup that was acquired by Netlify and turned into a product called "Create", which strived to be the "edit" button for any custom built website or web app, making entire web teams able to collaborate seamlessly together.
Before we get into how we solve for this, let's talk about the issues Albert is raising.
Going from idea to representative solution provides a much clearer path for PMs (and other functions) to express the product ideas and specification than a written PRD. While having a PRD is still very important, being able to play around and "feel" a few product directions as early as possible is invaluable.
Many PMs don't have the luxury of a dedicated UX/UI designer with which they can quickly ideate and iterate. I remember my first "official" PM job trying to show my vision of how users can interact with a project roadmap using Axure. The ability to feel the interaction helped improve and simplify the spec greatly, as well as show the engineering team a much clearer vision of the end result. I ended up spending an obnoxious amount of time on fine tuning that Axure model, so much so that one engineer who saw it for the first time asked me what I wanted him to do since it seemed to have already been implemented.
Well, now with AI we can bridge that gap and instead of passing through just a representative mockup, many like Albert are jumping straight to a working prototype.
Albert's teams go a step beyond a representative solution to have a practical "shadow" application that's separate from production and has its own main components already implemented (skipping the mockup part I described above), allowing the product team to accelerate iteration with low risk.
Albert highlights that for many teams today moving from that prototype of the solution to having it actually live in production is still cumbersome:
Overall, it's a huge improvement over just a few months ago when even this process wasn't possible or was much more difficult, but it's still tantalizingly close to be able to have product people ideate and then have a production ready PR that's simply reviewed by the engineering team with the right guardrails.
A few months ago I was still using this same process from idea to just the representative solution. For example, having identified a problem with our upgrade flow I screenshotted the entire flow, got Cursor to reimplement those screens and flows and then asked it to showcase my proposed alternative. I was then able to hand over that mock and a video explaining the changes to our developer who implemented it (and moved conversion from the intent to upgrade to actually upgrading by about 41%). Today I'm making similar changes, only that an AI agent is working directly on our own codebase, in an environment that matches our production 100% and is able to show me a preview of the app with my changes running live. I can then create a PR that will be reviewed by design and engineering and merged into production.
So how are we achieving an end-to-end idea to production workflow?
At Netlify, we've been dogfooding Agent Runners, which spin up a production-parity preview and run a coding agent on the same preview server. That lets anyone propose changes with a prompt, have those changes implemented in the same codebase, using the existing components and design systems, see a live preview environment, and open a PR with our usual reviews and checks. In practice, this trimmed the 'handoff' time and kept iteration in the same environment we ship.
The moment the feature was ready for internal dogfooding, the entire team immediately started using it to improve the feature itself. A simple example to illustrate happened to me. When using Agent Runners on Netlify, I accidentally cancelled a pretty long running task, leading me to just ask the agent to "please use our existing confirmation dialog to ask whether the user is sure they would like to cancel this run", and after two iterations and ~15 minutes I had a PR ready for review. We naturally had to put a few workflow rules in place to make sure we're able to properly handle all those open PRs, but overall, we're shipping impactful changes faster than ever before.
While this is lightyears ahead of static representations or shadow prototypes, I'll call out a potential problem with this approach: product development works best when the whole team collaborates on the solution. The PM specifies user needs and requirements of the solution, designers transform those needs into the right UX and UI patterns and match the existing product's UI, and engineers choose the best implementations to deliver a quality product that matches the specifications on time, to name a few of the opportunities for more voices. Of course there are multiple other functions such as product marketing, documentation, support, sales, etc., involved in this process, and it's also much more collaborative, iterative and intermingled rather than a straight waterfall from product to design to engineering.
If the PM now jumps over that fence of requirements into already outlining the UX/UI, we'll miss a key part of the process. However, I believe there's a fairly easy solution to fix this. The best way is to probably work in collaboration from the very beginning. We're doing this by having a short meeting between all the cross functions take everyone's points of view into account before creating a solution outline. If this does start more of an individual operation, it's totally okay to treat this as a first iteration without a prescribed solution. Especially as AI makes generating such solution very quick, there should be no problem discarding it or trying several different ones.
If you're exploring similar paths from idea to production, I'd love to compare notes. And if you want to see more detail on the approach we've been testing, here's a straightforward overview of Agent Runners.