## How would you explain your field to a college student just starting to explore tech? 3 elements to the job: Figure out the right problems to tackle Get the right resources to tackle the problem Solve the problem ## What kinds of problems do you work on in your role? I'm a PM on AI inference at Google Cloud — the work of actually serving AI models at scale. How do we make responses faster, cheaper, and more reliable across billions of requests. It's a mix of product strategy and infrastructure economics, where shaving 50 milliseconds off a response or a fraction of a cent off a query can unlock entire product categories. Outside of work I build smaller things in the same vein — Tracer for tracking illegal guns through my work with Everytown, and an agent-friendly version of my product playbook on GitHub. ## What skills have been most important that you didn't fully learn in college? Saying no and getting people aligned on a plan. College taught me computer science. The Marines taught me how to lead people through hard things. Both turned out to matter more than I expected. The CS degree gets you in the door, but most of the job is figuring out how to move a group of smart people toward a shared decision when the answer isn't obvious. ## Common mistakes students make when trying to break into tech? Two big ones. First, waiting until you feel "ready." I enlisted in the Marines right after high school and a lot of the best decisions in my career have come from saying yes before I felt qualified. Second, optimizing for logo prestige over learning. Your first job matters less than whether you're surrounded by people who'll stretch you. Go where the work is interesting and the people are sharp. ## What made the biggest difference for you getting your first internship or job? Building things and being specific. Back in 2011 I built FastTrack to help track H1N1 vaccine distribution — not glamorous, but it was real and shipped, and it changed every conversation I had afterward. Generic applications get lost in a pile; a targeted message that shows you actually understand the team's problem gets read. Almost every meaningful job I've had came through a warm intro or something I could point to. Put your work somewhere people can find it. ## How do you continue learning and keeping up with changes in your field? In AI you don't have a choice — the field moves monthly. I keep a public notebook called Practice of Product because writing forces me to figure out what I actually think. I read papers, follow a small set of sharp people, and most importantly I build with the models. You learn more shipping one weekend project with an LLM than from a month of reading about them. ## How do you balance technical understanding with user and business needs when building AI products? In AI inference, the technical and the business sides are the same problem looked at from different angles. A 100ms latency improvement changes whether people trust the product. A cheaper inference path opens up use cases that weren't economical the week before. The risk is treating "technical" as a separate lane from "product" — in this space, they're not. Having written code for years helps me ask engineers the right questions without slowing them down. ## What skills or experiences should students build if they're interested in large-scale AI systems from a product perspective? Three things. Get comfortable with systems thinking — take distributed systems, take an ML class, learn how to reason about latency, throughput, and cost together. Actually build something with an API like Gemini's or Claude's until you've felt the constraints firsthand. And practice writing. PMs in AI write constantly — specs, memos, launch docs — and a clear one-pager will move a team faster than ten meetings. Code, writing, and decision-making with incomplete information — if you have all three, you're ahead of most people trying to break in.