AI Disclosure: This blog post was written with the help of Claude Code. Here is the prompt that drove it:
Prompt: “Take a look at the last 5 blog posts in content/posts. Especially the ones about the ASO. Write another blog post. The title is: The ASO - Product Managers to the rescue. The main idea/premise here is that the role of the PM has already changed (in the last 24 months). Today the AI-enabled PM is much more self-sufficient and independent than he/she used to be. The existing tooling (lovable, vercel, figma, … and the like) has already changed what PMs are doing and the way PMs work (one step closer to a feature fly-wheel). Please make sure the list of tools PMs use right now is complete and comprehensive (Top 10). The next step is to not only change how the PM is working, but to evolve the role itself. In that context we want to come up with a new name for a role that current PMs can play in the next better AI-enabled SDLC and write a job description for that role.”
I had lunch with a PM last week. She manages a four-person product team at a mid-sized SaaS company. We were talking about the last eighteen months, and she said something that stopped me:
“I haven’t written a PRD in six months. My job is completely different now. I’m building things.”
She was not talking about learning to code. She was talking about Lovable and v0 and Bolt. She was talking about going from customer conversation to working prototype in two hours — before ever involving an engineer.
This is not an edge case anymore. The PM role has quietly, fundamentally changed. And the change happened faster than anyone planned for.
What has already happened
Let me set some context for readers who haven’t followed the ASEO series. The premise of the AI-enabled Software-Engineering Organization is simple: AI has dramatically accelerated individual task execution, but most organizations are still running 2020 workflows with 2026 tools. The bottleneck has shifted. The constraint is no longer writing code — it is decision quality, problem framing, and organizational design.
In that picture, the engineering org gets a lot of attention. The debate about comprehension debt, about re-soloing, about who reviews AI-generated PRs — these are real and important. But there is a parallel transformation happening upstream that gets far less coverage.
The PM role has changed more in the last 24 months than in the previous decade. And unlike the engineering transformation — which is still contested, still generating more heat than light — the PM transformation is quietly producing results that are hard to argue with.
Here is what is different now.
The self-sufficient PM
The traditional PM’s core constraint was dependency. You had an idea. You wrote a spec. You got it prioritized. You waited for an engineer to build it. You waited for a designer to make it look right. You waited for feedback cycles that took weeks. The PM was orchestrating a value chain that moved at human speed, through human handoffs.
That constraint is gone.
The AI-enabled PM today can go from customer insight to interactive prototype in hours. She can run her own usability tests on that prototype before an engineer touches it. She can validate the riskiest assumption in the spec before it becomes a sprint ticket. And then — if the prototype survives validation — she can hand over something that is almost production code, not a Figma mockup.
The handoff has not disappeared. But it has moved. And what happens before the handoff is now entirely different.
The Top 10 Tools That Changed Everything
These are the tools driving the transformation. They fall into two categories: AI-native tools built from scratch for this new workflow, and established tools that have added AI capabilities substantive enough to change how PMs work.
1. Lovable Natural language to full-stack web app. Describe a feature in plain English, get working code. Lovable’s explicit mission is “redefining product development for PMs” — and it delivers. PMs can build shareable, functional prototypes without touching a terminal or an IDE. This is the tool my lunch companion was talking about.
2. Vercel v0 Prompt-to-UI. Converts natural language into production-quality React components with live preview and one-click deployment. A PM can go from “I want a dashboard that looks like this” to a live staging URL in under an hour. No IDE, no local setup.
3. Bolt.new Full-stack AI development environment in the browser. Builds, runs, and deploys complete applications from prompts — with real database connections and APIs. Bolt validates entire product ideas before a PRD exists. It removes the last excuse for speccing features nobody has actually tried.
4. Cursor AI-first IDE. Lenny Rachitsky’s newsletter ran a piece arguing that PMs should adopt Cursor not to write code, but to build intuition about AI systems they are responsible for. Cursor makes AI reasoning transparent in ways that consumer UIs do not. It is the tool that closes the gap between “PM who uses AI” and “PM who understands AI.”
5. Figma (with Make and AI) Figma’s AI layer converts static frames into interactive prototypes via natural language prompts — animations, responsive layouts, dynamic data — inside the collaborative environment where design already lives. The Figma MCP server bridges directly to Cursor and similar tools, so design intent flows into code generation without a handoff document.
6. Notion AI (with Agents) AI embedded across the entire workspace — agents that automate recurring workflows, semantic search across Slack, Google Drive, and GitHub, AI meeting notes. Notion AI agents operate with full company context, not in isolation. PMs automate standups, triage feedback, maintain roadmaps, and generate release notes from the tool where their work already lives.
7. Linear (AI features) Engineering-first project management with automated issue creation, work readiness checking, and contextual cross-referencing across your stack. Linear’s AI eliminates “work about work.” Its Work Readiness Checker ensures tickets are ready before engineering touches them — reducing the back-and-forth that consumes PM cycles.
8. ChatPRD AI-native PRD authoring with direct export to v0, Bolt, Notion, Confluence, Jira, and GitHub. PRDs become executable artifacts, not static PDFs. A PM writes a spec, and it can be pushed directly to Bolt to generate a prototype or to GitHub as a structured issue. This is “spec-driven development” made operational.
9. Productboard AI Converts the chronic PM problem — too much qualitative signal, too little synthesis time — into an automated flow. Auto-categorizes customer feedback, surfaces trends, links insights to feature ideas, generates spec summaries from aggregated needs. A PM can ask “what are customers saying about checkout?” and get a synthesized answer across thousands of data points in seconds.
10. Dovetail AI AI-powered research repository with contextual chat over all customer interviews and feedback. Dovetail democratizes continuous discovery: PMs no longer need a dedicated UX researcher to extract themes. You can query your entire research corpus in natural language — which is exactly what Teresa Torres means when she talks about keeping the opportunity solution tree alive between quarters, not just quarterly.
One step closer to the feature flywheel
What these tools collectively enable is something I want to name precisely: the feature flywheel.
The traditional product development loop looked like this: customer feedback → PM interprets → spec written → design → engineering → shipped → customer feedback. That loop had a latency measured in weeks, sometimes months. The handoffs between phases were expensive. Each one introduced distortion: the PM’s interpretation of the customer, the designer’s interpretation of the spec, the engineer’s interpretation of the design.
The AI-enabled loop is collapsing that latency and those handoffs. The PM who uses Lovable and Dovetail and Productboard together is running a tighter version of that loop — faster, lower-distortion, cheaper to iterate. The flywheel is spinning faster because more of the loop is under PM control.
But — and this is the crucial point — we are only halfway there. The tools have changed what PMs can do. The role itself has not yet caught up. Most organizations are still running AI-enabled PMs inside a job description written for 2018.
That is the gap. And it is getting wider.
The next step: evolving the role itself
Here is what Lenny Rachitsky’s March 2026 job market report showed: PM roles are at a three-year high, up 75% from the 2023 low. But the roles that are growing are specifically AI-native PM roles. Meta added “AI Product Sense” as a new PM interview dimension — the first change to their PM hiring loop in five years.
The market is signaling that the role is changing. But nobody has written the new job description yet.
The closest existing title is Product Engineer — a hybrid role pioneered by companies like PostHog, defined as a developer who builds for real users, owns the full product experience, and makes product decisions as a first-class responsibility alongside coding. The Product Engineer is real, is being hired for, and represents one end of the bifurcation: at AI-native companies, the PM and engineer roles are collapsing into a single person.
But that is not the right model for the majority of organizations, and it is not the transition path for existing PMs. The more important evolution is different.
I want to propose a new role — one that existing PMs can grow into, and that organizations should be explicitly hiring for in the next 24 months.
The Feature Flywheel Owner
The Feature Flywheel Owner (FFO) is what an AI-enabled PM becomes when you take the tools seriously and redesign the role around what those tools actually make possible.
The name matters. “Product Manager” is defined by management: managing backlogs, managing stakeholders, managing the spec process. The FFO is defined by outcomes: owning the full loop from customer insight to shipped feature and back again. She manages the flywheel, not the backlog.
The job description does not exist yet in any standard form. What follows is a synthesis of what the market is converging on, what the tools enable, and what the ASEO framework requires.
Feature Flywheel Owner — Role Definition
Mission: Own the full loop from customer insight to shipped feature. Minimize the time and distortion between “customer has a problem” and “customer experiences the solution.” Use AI tooling to make that loop faster, tighter, and more autonomous with every iteration.
Core Responsibilities:
- Discovery ownership. Run continuous discovery using AI-assisted research tools (Dovetail, Productboard). Synthesize qualitative and quantitative signals without waiting for quarterly research cycles.
- Prototype before spec. Build functional prototypes using AI tools (Lovable, v0, Bolt) before writing a PRD. Validate the riskiest assumption before it becomes an engineering ticket.
- Spec as executable artifact. Author specs (ChatPRD, Notion AI) that are ready to push directly to Bolt or GitHub — not PDFs that require interpretation. The spec is the first step in implementation, not a contract between departments.
- Agent orchestration. Define, configure, and evaluate AI agents handling recurring product workflows — feedback triage, roadmap updates, release notes, stakeholder summaries. Manage the agent fleet the way a previous generation managed junior PMs.
- Flywheel metrics. Own a feedback dashboard that closes the loop between shipped features and customer behavior. The flywheel is only spinning if you can measure it.
- Guardrail definition. Specify the acceptance criteria and quality boundaries that determine when AI-generated output is good enough to ship, and when it requires human judgment. This is the new “definition of done.”
What this role is NOT:
- A backlog manager
- A ticket writer
- A meeting facilitator who represents customer needs to engineers
- A project manager with a “product” title
Required skills:
- AI product sense: the ability to evaluate model outputs, understand failure modes, and design around AI limitations
- Functional prototyping: comfortable building with Lovable, v0, Bolt, or equivalent
- Research synthesis: able to extract actionable insight from qualitative data using AI tools
- Spec-driven development: writes specs that are structured enough to be executed by AI agents
- Agent management: can define, deploy, and evaluate AI workflows without engineering support
Preferred background: Current PM with 3+ years of experience who has actively adopted AI tooling in their workflow. Demonstrated examples of prototypes built independently, discovery loops shortened, or features shipped with reduced engineering dependency.
This is a transition, not a replacement
The Feature Flywheel Owner is not a new hire profile — it is where existing PMs are already heading. The ones who are thriving are not waiting for their company to redefine the role. They are already building prototypes. They are already querying their research corpus in Dovetail. They are already pushing specs that engineers describe as “the clearest tickets I’ve ever gotten.”
The gap is that organizations are not recognizing this, not promoting it, and not hiring for it explicitly. They are still measuring PMs on roadmap delivery and stakeholder satisfaction and on-time sprint completion.
That is not what the role is anymore. And if you are measuring for 2018, you will optimize for 2018.
What CTOs and product leaders should do now
If you run an engineering or product organization, here is the practical implication.
Audit your PM workflows. Which of your PMs are using Lovable, v0, or Dovetail today? What are they building with those tools? The answer will tell you who is already operating as a Feature Flywheel Owner — and who still thinks their job is writing Jira tickets.
Change the job description. Not for a future role — for the role you are posting right now. “Experience with AI-assisted prototyping” should be a required skill, not a nice-to-have. The ability to build a functional prototype before writing a spec should be expected, not exceptional.
Redesign the handoff. If your PMs are still handing Figma mockups to engineers, you have not closed the gap yet. The new handoff is a working prototype or a spec structured for agent execution — not a document describing what someone else should build.
Measure flywheel velocity. How long does it take from “customer reports a problem” to “customer experiences the fix”? That is the metric that matters in the ASEO. PM performance should be measured against it.
In the SOTU post I noted that most of the current discourse is still diagnosing problems, not prescribing solutions. Here is a prescription: the most leveraged thing a product organization can do right now is take its best PMs, give them the tools, redesign the role around the flywheel, and get out of the way.
The Feature Flywheel Owner is not a hypothetical. She is already in your organization. You just haven’t named her yet.