For most of my career, the product management job had a shape everyone quietly accepted. I had the ideas, other people turned them into things, and in between was a gap where ideas went to wait. A good idea on Tuesday might become a working prototype in six weeks if it survives the process, reshaped by every handoff and every re-scope along the way.
That gap is now collapsing, and it’s changing the job in fundamental ways.
Now, product management teams are increasingly functioning within what I call the AI Development Life Cycle (AIDLC). It’s how the loop runs now: idea to specification to working prototype to something you can put in front of a person and learn from with AI as a full participant at every step. It can now read the real codebase and build the real thing.
The distance from the sticky note to the shipped feature now gets measured in days, not quarters, smoothing the translation process from idea to a tangible end product.
The bottleneck was never ideas
No product organization I’ve been in was idea-constrained. Every whiteboard has three years of good ideas on it. One of the constraints was translation: turning “what if users could push media straight to multiple social endpoints” into something concrete and grounded enough that an engineer could pick it up and run without a week of correcting my mental model first.
That translation used to be manual, and it leaked value at every step. Half my “requirements” were impossible; half the genuinely hard problems I never mentioned because I didn’t know they existed. What’s changed isn’t that AI writes faster. It’s that it writes grounded—reading the actual repository alongside me, using the real components and the real names.
Distribution Center: an idea I could actually hold in my hands
The clearest example is the Distribution Center I prototyped for Veritone Digital Media Hub (DMH). The sticky-note version: let a user send their media straight from DMH out to a destination like YouTube, and see what happens.
Old me would have written ten pages of aspiration and drawn some boxes. Instead, in the AIDLC loop, we built the thing with a:
- real provider catalog, with connection states
- “Send to destination” dialog with per-platform publish forms.
- simulated backend that validates server-side, returns a tracking handle, then fires a fake vendor webhook that flips the activity row to publish with a real YouTube-style URL.
- recent-activity feed and an OAuth connect dialog.
It wasn’t a mockup of the feature. It was the feature, running, minus the production wiring. I could click it, feel where it dragged, and hand-engineer something that was more tangible. But that was only the first constraint solved. There’s another issue that this new lifecycle solves.
The prototype found the real problem that a mockup never would
Here’s the part that actually changed my mind about the job.
Once the Distribution Center worked, the hard question surfaced on its own: where should Google OAuth actually live? So we wrote the decision doc: three placement options, a scorecard, a proposed architecture, all grounded in signals from the existing code, and a list of files to anchor the design review.
And that’s where the real insight fell out: the other bottleneck isn’t the code at all. It’s the application verification process; the org-and-paperwork gauntlet you have to pass before real users can OAuth into a YouTube integration. No amount of UI polish makes that faster. So the document’s most valuable section wasn’t the architecture; it was the four ways to reduce verification costs.
I wouldn’t have found that by drawing screens. You only trip over the load-bearing constraint when you try to build the actual thing. The prototype didn’t just show me the feature; it showed me the part of the feature that was going to hurt while it was still cheap.
What the job actually becomes
If translation is no longer the bottleneck, and prototypes uncover the true cost of development, what’s product management for? It has taken on an even more important role, except it’s just further up the stack.
When you can generate a working prototype and a grounded decision doc in a week, the scarce skill isn’t production anymore. It’s judgment. For instance, I needed to answer questions like:
- Is OAuth verification worth it for YouTube alone, or do we need a destination that clears the bar faster?
- Which failure mode do we own?
- Is this even the right problem?
The AI will happily help me build the wrong thing beautifully and fast. Deciding it’s the wrong thing is still the job more than ever, because the cost of not noticing dropped right alongside the cost of building.
The other half is taste at the seams. The AI is great at “here’s a working version of what you described.” It’s still on me to insist that the activity feed tells the truth when a publish fails, that a broken OAuth connection reads as an error, not a spinner forever, and that the unhappy paths are where trust is actually built.
A few principles I keep coming back to
Here’s a sticky-note version, since I can’t resist one:
- The bottleneck was translation, not ideas: AI collapses translation, so optimize for judgment rather than idea generation.
- Ground everything in the real system: a prototype that names the real files and states beats ten aspirational specs.
- Prototype to decide, not to ship: the point of building fast is learning fast so you can find the constraint that hurts while it’s still cheap.
- The AI builds the happy path; you defend the unhappy ones: seams, failure states, and taste are where human judgment still lives.
Final Thoughts
The interesting part is that the gap—the waiting room between the sticky note and the shipped thing—is disappearing. When it does, the job stops being about packaging ideas for a handoff and starts being about making good calls quickly, with a real thing in your hands instead of slideware.
Distro Center went from a line on a sticky note to a clickable prototype that told me exactly where the hard part lived in an afternoon. The sticky note used to be the start of a long wait. Now it’s the start of a short loop, and I’d rather run ten short loops than survive one long wait.
Further Reading:
The Artist and the Algorithm: Why Human Storytellers Are More Important Than Ever in the AI Era
Stop Managing Your Media and Start Asking It Questions
One Pipeline, Infinite Possibilities: The Case for Domain-Specific AI in Media
