Delivery leader at Google shares how agentic workflows change PM models
Anshumani Ruddra explains how agentic workflows help delivery teams build faster while making human judgment, validation, and decision-making even more important.
Anshumani Ruddra
Product Leader at Google
Agentic Shift: Agentic workflows replace linear handoffs with parallel, cross-functional delivery anchored in shared code and documentation.
Human Judgment: AI handles coordination and drafting, while leaders retain responsibility for quality, creativity, prioritization, and trust.
Start Auditing: Teams should audit weekly time sinks before selecting tools, avoiding generic adoption and flashy but ineffective stacks.
Rituals Matter: Faster AI delivery still requires clear scope, stakeholder alignment, rigorous validation, and disciplined checklists to maintain product quality.
Leadership Model: Successful AI adoption combines leaders changing their workflows with teams experimenting and sharing improvements across the organization.
Anshumani Ruddra is a product leader at Google, working on delivery within its payments products. He is also an educator who has held C-level delivery roles.
We sat down with Anshumani to learn how AI is changing delivery at companies like Google. Here's what he said.
Building products at Google
I'm Anshumani Ruddra. I've spent 22+ years building consumer products at the intersection of technology, storytelling, pop culture, and human behavior — starting as a children's book author, then as a game designer on global social hits like Mafia Wars and Café World, then scaling Hotstar into one of the world's largest streaming platforms during the IPL years.
Create a Free Account to Read More
Unlock this piece and join a community of forward-thinking leaders discovering tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Over the last five years at Google, I've led product management for the hugely successful GPay app in India, run the entire Google payments product offering for APAC, and built consumer-facing AI products. Currently, I lead an end-to-end AI product development effort to build a completely new product.
Additionally, I teach product leaders and executives how to build with AI through my Maven course, Level Up to Product Super IC. I hold two roles simultaneously — operator and teacher — and both shape my approach to product delivery: less about coordination and approvals, more about going from insight to working prototype without waiting for permission.
How AI enables humans to do more of what they're best at
I try not to think of AI as just another, better tool. That framing traps you into thinking it's only about efficiency. AI is a multiplier — possibly a once-in-a-century one.
It allows me to spend far less time on the connective tissue of delivery: meeting synthesis, drafting PRDs, status and stakeholder updates, and first-pass research. I've pushed a lot of that into a personal "agentic OS," allowing it to largely run itself.
So now, I spend my time on the 10% that's hard and human, not the 90% of coordination that used to eat the week. I focus more on the actual craft. The thinking, judgment calls, and prototyping.
Speaking of prototyping, that's a huge shift in itself. I can now validate a vision by building a functional prototype myself before assigning anyone to it. The barrier to building is gone. If I can think of it, I can get a first draft working.
When to use AI vs. when a human is required
The most automatable work is the synthesis and administrative layer:
- Turning raw meeting audio into decisions and action items
- Generating first-draft PRDs and research
- Triaging incoming signal
- Handling stakeholder updates
You implement this with personal agents that watch your inputs, surface what needs a decision, and draft the rest.
Customer intelligence is hugely underused here, too: Tools now exist that tell you which features to build and estimate the ARR impact, yet most teams still hand-aggregate feedback from Slack and support tickets.
But humans must still define what “good” means. As a leader, defining quality is your job, which is why I think evals matter so much.
Humans must also handle taste and product judgment, genuinely creative zero-to-one leaps, and the high-trust human work of coaching teams, navigating politics, and making the hard prioritization calls.
AI gives you more throws at the dartboard; a human still has to decide where the board is.
Why tech stacks should begin with an audit
AI tools are exactly like a great video game — easy to play, brutally hard to master. The seductive first-time experience makes people assume it's all smooth sailing, so they're shocked when complexity hits. Many give up. The real skill isn't prompting; it's the willingness to persist and learn at your own speed, faster than feels comfortable.
At work, my stack is primarily the latest Gemini models, with Antigravity as an agent hub. Antigravity's agent manager is underappreciated. It is truly innovative. As far as project management, Google uses its own custom tools, equivalent to Jira and GitHub in the outside world.
For my personal projects and teaching activities, my core stack is:
- Claude Code for coding. This is the standout. I run multiple agents in parallel. It's the closest thing to a real assistant, not just autocomplete.
- Replit for prototyping. Its plan-first approach and parallel agents set it apart.
- NotebookLM plus Obsidian for research and writing.
- Codex and Claude Cowork handle many scheduled tasks and automations, integrating email, calendar, cloud drives, and meeting notes.
- Granola and Wispr Flow round out the stack. I strongly advocate for speech-to-text and using voice as input.
Over the last 6–12 months, the stack evolved from "using AI to draft things faster" to a genuine personal agentic OS — less about one-off prompts and more about standing agents that own recurring workflows end-to-end.
My advice on building a stack: Don't start with the flashiest tool. Audit how you spend your week, find your biggest time sinks, and pick the specific tool that eliminates them. Generic adoption strategies don't work.
How agentic workflows streamline project delivery
We deliberately focused first on the shared foundation that makes these workflows possible, because everything either holds together or falls apart there.
Almost all our processes now run as agentic workflows, across design, product management, and engineering execution. Agentic workflows manage the strategy and thinking behind what needs to be built, the design of components, screens, and layouts, and how both backend and frontend code come together. This is not an isolated experiment in one corner of the team; it is how work happens end to end.
We deliberately focused first on the shared foundation that makes these workflows possible, because everything either holds together or falls apart there. Practically, this means building common infrastructure for the entire team, a common set of agent skills, and a common harness everyone works through. The most important piece is documentation that is not just human-ready but agent-ready. If your documentation only makes sense to people, your agents will drift, so we invest heavily in writing for both audiences at once.
Concretely, this looks like clearly marked knowledge files, PRDs, and engineering design documents. We typically keep these in Markdown, very crisp, and write them so they make sense to both humans and agents. Crucially, humans validate all these files before we start building anything. Human validation of inputs keeps the agentic workflow clean because agents are only as good as the documents and skills you point them at.
We also maintain very clear checklists, and we ensure agents work through them. An agent only marks a step complete when its checklist is genuinely satisfied; only then do we move to the next step. This discipline of clear documentation, human-validated inputs, shared skills, and step-by-step checklists turns agentic work from a novelty into something reliable.
The payoff is real once the foundation is in place. The hard part is the upfront investment in shared infrastructure and agent-ready documentation. Teams that skip that step get a flashy demo and then watch it fall apart as complexity grows. Teams that put in the work get genuinely fast, parallel execution across design, product, and engineering.
How AI changes traditional project management models
The old-school waterfall model simply doesn't work anymore. Traditional project management was relentlessly linear: step one led to step two, then to step three, with rigid handoffs between disciplines. Product wrote the spec, design created the mocks, engineering built it, and then design reviewed the polish — each stage waited on the one before it.
That linear chain has broken, which is a wonderful thing. The steps are now interchangeable, and the lines between design, engineering, and product have blurred. For example, designers have already built the design system directly into the codebase — the right components, layouts, and specific color tokens. Engineering can then build an entire feature flow, and design fixes all UI issues directly in code to complete the polish. Nobody is waiting on a Figma handoff. Design is operating in the same medium as engineering.
The same blurring happens upstream. Product can write many more PRDs in parallel, unblocking engineering. Engineering can generate deep, detailed engineering design documents without product gating every step, because AI lets each discipline produce work that previously required a specialist.
Different team members can now do different parts of the job. So, instead of a linear relay race where batons are dropped at every handoff, a small, high-agency team emerges where everyone can move into adjacent territory to unblock work.
In practice, this means lightweight systems over heavyweight processes: fewer status meetings and approval gates, more working prototypes. PRDs and engineering design documents are generated fast and treated as living artifacts rather than frozen specs. A shared codebase — with the design system baked in — serves as the single source of truth where product, design, and engineering all meet.
The result is velocity — teams validate vision by building, not by coordinating, and ship polish that previously took several handoff cycles in a fraction of the time.
Why AI cannot remove the need for project rituals
All of the usual rituals still exist, and several become even more important with AI, not less. People mistakenly assume that faster building means looser discipline. The opposite is true.
Defining scope is as critical as ever. A team still needs a crystal-clear definition of what it is trying to build. What has changed is what becomes possible within that scope. If a team efficiently builds with AI, many things that were low-priority or stuck in a backlog forever can now be prioritized and shipped. So, you can build a more meaningful, more complete product than before. The ambition of the scope can grow, but the need to define it clearly remains.
Teams still require full alignment. Stakeholders still require alignment. When working across multiple teams, you must still deliberately align both within your team and across those teams. AI does not align people for you.
Validating work matters even more. When building at a large company, your products reach millions, not just tens or hundreds of users. Products must still be excellent, work very well, and perform at that scale. AI helping you build faster does not lower that bar. So validation remains non-negotiable.
What has changed is that the process is no longer so hard and slow. The rituals themselves — clear scope, real alignment, and rigorous validation — remain true and even grow in importance. We need to rethink the processes that traditionally hinder faster execution. AI lets you strip down the ceremony and friction around these rituals, while you protect their substance.
Why judgment will become even more important in AI-first organizations
In the near term, more technology companies will adopt AI in end-to-end product development and delivery. The bolder prediction, however, is where it spreads next. It will not stay within tech. It will spread to large enterprises, then to non-technology companies, and eventually to traditional businesses.
Once these gains move from individuals to small teams to whole organizations, the dynamo effect will drastically reshape teams and workflows. The structure of how delivery teams are built and how work flows through them will look very different from today.
But the importance of good decision making will not disappear; in fact, it will become more important because you now make decisions far more often. When overall delivery was slow, you only made a few key decisions, perhaps once every few weeks or months. Now, you must make high-quality decisions multiple times a day, sometimes multiple times an hour.
AI-driven development must be adopted both top-down and bottom-up.
Therefore, focus must shift to human decision making. Each area of expertise will need to define a clear set of lenses through which to view every decision, enabling crisper, faster calls. Equally important, those decisions must be recorded so agents understand and can refer back to them.
Winning teams will treat high-quality, well-documented human judgment as a scarce resource, because AI makes it both more frequent and more valuable.
Why delivery leaders must adopt AI and encourage experimentation
The critical meta-point is that AI-driven development must be adopted both top-down and bottom-up. It cannot be one or the other.
The top-down half requires leadership buy-in. If senior leadership does not buy in, experiment, and try to change its own workflows and delivery systems, the organization will find it very difficult to adopt AI meaningfully. You cannot mandate a transformation you are not personally living. Leaders who delegate AI to a task force while keeping their own ways of working untouched send a clear signal that this is optional, and the organization reads that signal accurately. So, my first piece of advice to fellow delivery leaders is to change your own workflows first, before you ask anyone else to change theirs.
The bottom-up half is just as important. Junior employees and individual teams must have the freedom to experiment, challenge conventions, and challenge existing workflows. They need room to try things, question how delivery has always been done, and then bring what they learn to leadership's attention. If that channel does not exist, if people lack that freedom and their findings never travel upward, then the whole thing falls apart just as surely as it does when leadership is absent.
The single most useful thing a delivery leader can do right now is hold both ends at once. Lead from the front by visibly rethinking your own delivery systems, and simultaneously create conditions for your teams to experiment freely and bring what works back up to you. It has to be both top-down and bottom-up.
When only one end engages, adoption stalls. When both do, the change takes hold.
Follow along
You can follow Anshumani Ruddra's work on LinkedIn. You can also check out his blog and his courses.
More expert interviews to come on The Digital Project Manager!
