How to Start With AI When You've Already Decided It's Too Hard (13 Year Google Veteran POV) - w/ Aishwarya edited transcript

Aishwarya spent thirteen years at Google across several internal pivots, including YouTube monetization, before becoming a principal product manager at an AI-focused travel company. Around her twelfth anniversary, she began asking what work outside Google looked like and whether she could explore AI without limiting herself to one company's products and processes.

Leaving was difficult because Google still offered sophisticated AI work. Her immediate role, however, was in YouTube monetization, and switching internally into the most desired AI teams required several competitive steps. She concluded that the broader market might offer a faster route to direct AI ownership than constraining her search to the Google ecosystem.

Model choice also mattered. At work she used Gemini, while outside she wanted to experiment with Claude and other tools as their relative strengths changed. She wanted an environment where she could select the model that fit the task rather than wait for internal permission or platform support.

Aishwarya graduated during the 2009 recession and did not begin with a perfectly mapped career. An analytics company in Chennai gave her a foundation in data and machine learning when those fields were only starting to become mainstream job categories. That experience led into Google and shaped how she approached later technology shifts.

At Google, she joined a group handling long-tail operational problems that larger teams lacked bandwidth to solve. She and a colleague tested whether a small amount of code and machine learning could make decisions at human quality but greater scale. Early successes showed her that automation's value was not novelty; it was applying consistent judgment across volumes people could not handle manually.

She had not studied analytics or machine learning formally because the field matured after she graduated. Learning on the job therefore became normal. The same underlying discipline still applies with generative AI: a person must know what good and bad output look like, review the result, and understand whether it is reasonable before using it.

In AI-role interviews, Aishwarya considers storytelling and communication underrated differentiators. Candidates often treat STAR as a checklist, but an interviewer usually asks because the team has a live problem or a painful past experience. A strong answer builds a story arc around the challenge, the candidate's decisions, and the impact relevant to that team.

Impact answers the interviewer's 'so what?' Launching a dashboard, model, or process is not self-explanatory. Candidates should connect what they built to a decision, customer, cost, risk, or measurable outcome, then relate that evidence to the role under discussion. The same principle that strengthens a resume bullet also strengthens a spoken answer.

Roles are blurring as AI gives more employees access to capabilities that once required a specialist. Hiring teams are therefore testing resilience, tradeoff judgment, negotiation, and the ability to learn from failure. A story that includes a mistake, the lesson, a correction, and a better result can be more credible than one where every decision was supposedly perfect.

A product manager may now perform lightweight analysis that previously required a data scientist, particularly for low-risk decisions. Higher-stakes choices can still require expert review. The change is not that domain specialists disappear; the threshold for when another team must become involved can move as self-service tools improve.

Large organizations also employ people whose work includes carrying context between many teams. AI agents can listen to meetings, summarize updates, and surface dependencies that previously required repeated manual follow-up. Aishwarya treats this as an emerging operating model rather than a settled prediction about headcount or organizational design.

A former Google and Meta colleague built agents for technical program management. They collected project updates, reminded owners when trackers had not moved, and prepared executive reporting. According to the colleague, the system cut roughly 80 percent of the time spent on those coordination tasks, while she remained responsible for judgment and escalation.

An automated reminder works only when the surrounding process gives it consequence. If missing an update means the project will appear at risk in a vice president's report, owners have a reason to respond. The technical agent was only one piece; guardrails, incentives, communication, and change management made the workflow legitimate.

Aishwarya does not recommend anchoring a career to one model or coding assistant. Her own preference moved from Gemini toward Claude as capabilities and integrations changed. Tools that feel dominant can be replaced within months, so durable skill comes from understanding the workflow, evaluating output, and moving between products as the market evolves.

Agent orchestration was not yet a requirement for every technology job in her experience. Some employers asking for AI skill only mean that candidates can use a chatbot beyond search and create repeatable workflows. Building multi-agent systems is further along the spectrum. It can differentiate a candidate, but claiming it is mandatory for all roles would overstate the market.

Candidates should examine whether an employer requesting agentic skills actually has the culture, data access, guardrails, and processes to use them. A person hired into an immature environment may spend as much time advocating, negotiating, and managing change as building technology. That can be a good role, but only if the candidate expects the human work.

Even among product and program managers, adoption varies. Some build agents that operate across meetings and trackers, while others use AI for analysis, drafting, or one repetitive task. Aishwarya sees orchestration as useful and relatively uncommon, but she does not equate traditional PM work with being obsolete.

Her advice to someone who has delayed learning AI is to build something hands-on. Reading and videos can establish vocabulary, but comfort comes from using the tools on a real task. She organizes that learning into four levels so beginners do not compare their first prompt with a fully autonomous agent system.

Level one is learning to make a general chatbot produce useful output, such as an email that actually sounds like the user. That requires context, examples, and revision rather than accepting the first generic draft. The exercise teaches that output quality depends on the instructions and information supplied.

Level two turns a repeated task into a reusable workflow, such as a custom GPT for resume polishing or a recurring communication format. The shift is from one successful conversation to a process that works consistently. Repeatability exposes which instructions, source materials, and quality checks the task really requires.

Level three connects multiple tools. A resume workflow, for example, might read the latest source document from Google Drive, adapt it to a job description, and return the revision. Connectors or protocols such as MCP reduce copy-pasting and teach how information moves between systems.

Level four delegates a more complex decision-making sequence to an agent while retaining human review where the risk requires it. Beginners often imagine this final level first, decide it is too difficult, and never practice the first two. Aishwarya recommends progressing through the levels instead of using advanced demos as the entry requirement.

A personal problem is often a stronger learning project than an artificial portfolio assignment. When the task genuinely causes friction, the learner has a reason to refine the workflow until it works. The useful question is not 'What AI project looks impressive?' but 'What repeated problem do I understand well enough to improve and evaluate?'

After leaving Google, Aishwarya defined three job criteria: direct work in AI, more customer-centered responsibility than her previous finance-and-strategy role, and enough ownership to see a project from beginning to result. She also explored content creation and entrepreneurship rather than assuming another corporate role was automatically the answer.

A friend referred her to one company she was excited about, and she treated it as the only job she wanted. Not getting it made the layoffs and difficult market feel immediate. The rejection forced her to broaden the search and avoid attaching the entire transition to one employer.

Aishwarya then networked extensively and spoke more openly about the work she wanted. Conversations helped her reject poor fits as well as find opportunities. Because the outreach was exploratory rather than a sequence of direct asks, people were more willing to introduce her to others. That network ultimately led to her current role.

Her current position satisfies another important criterion: strong colleagues and mentors. She wanted a stretch opportunity with people who would challenge and support her. The travel industry also contains legacy processes that AI may help redesign, giving her a chance to work on infrastructure and workflows rather than adding a superficial chatbot.

The work reminds Aishwarya of early machine learning at Google, when tools were immature and everyone learned while building. Failure feels different in that environment because experiments are expected to reveal constraints. What excites her is not using AI for its own sake, but helping define systems that can support the business for the next decade.

The episode closes with a practical message: foundational judgment remains valuable even as tools and titles change. Learn through real use, communicate impact as a story, understand the human system around automation, and do not wait until you can build an advanced agent before taking the first useful step.