Garima Goel

New city. Chicago to San Francisco. 🌉 Graduated in May, packed up, and landed here two days ago with two suitcases and a lot of opinions about what I want to build next. The last few years were split between building a company from a dorm room and shipping products inside big tech. Selling to customers, shipping things that broke, fixing them, then walking into a large org and learning how software gets made at scale. Two very different speeds. Together they taught me more than any classroom did, and made the decision to come here pretty easy. What I keep coming back to is AI safety infrastructure. Mostly because the building part feels underbuilt compared to how fast everything else is moving. I'm looking at founding roles and early team seats, and I'm most interested in companies still small enough that everyone does a bit of everything. If you're building something like that, or you just moved here too, I'd love to grab coffee. My calendar is unusually open and I'd like to spend it on good conversations. Writing this from Corgi Cafe. Come say hi if you're here, or anywhere in the city really.

I didn't get into Y Combinator Startup School. Thousands of people applied and there was only so much space. The email said I was one of the most promising people who applied and put me on a last-chance waitlist. I've decided to read that as a note about trajectory rather than arrival. The shape is right. The distance isn't closed yet. Both halves are useful to know. Here's what I keep coming back to, though. What I wanted from Startup School was never a syllabus. It was the room. Other people building at the same moment, at roughly the same stage, close enough to compare notes with. YC is unusually good at assembling that, and two days of it in one city is a hard thing to replicate. But the ingredient was never the venue or the speaker list. It's people showing up. Rooms get built, not granted. Three people making something, showing up consistently, being useful to each other. Nobody has to admit you to that. So I'll keep building mine in the meantime. If a seat opens up, great. If not, I keep working. That's the plan. If you're building something right now, I'd like to know what it is.

Not every problem needs AI. In one of my projects, the goal was simple: make an internal workflow more efficient. So of course, the first instinct (including mine) was: “Where can we add AI?” Automation, predictions, smart suggestions – all of it. I sketched out what an AI‑driven solution could look like. But when I dug into how people actually used the system, something didn’t add up. The friction wasn’t intelligence. It was structure. People weren’t stuck because the system wasn’t “smart enough.” They were stuck because information was spread out, unclear, and hard to scan. So instead of building an AI layer, I simplified the workflow. The final solution? - A structured Excel layout - Clear fields and labels - Logical grouping - Much less ambiguity Same team. Same goal. But instead of a “smart assistant,” they got a spreadsheet they could understand, adapt, and own. And it improved efficiency more than the AI approach we had initially explored. That experience changed how I think: Sometimes adding AI brings more complexity, less predictability, and harder failure modes. Sometimes the most responsible AI decision…is deciding not to use AI yet. The real skill isn’t finding somewhere to use AI. It’s knowing when not to. AI is a powerful tool. But if everything “needs AI,” your product probably needs clarity first. Curious: what’s a time you replaced a fancy solution with a boring one and everything got better? #ProductManagement #ProductThinking #AI #BuildInPublic #ProductStrategy #PMLife #ResponsibleAI

We didn’t ship a feature, we deleted it a week before release. "The roadmap said build it. The data said don’t." This feature had been planned for weeks. It was in sprint plans, demos, and internal updates, so over time it stopped feeling like a decision and started feeling like a commitment. Then we looked closer at user behavior. The friction wasn’t where we thought it was. Users were getting stuck earlier before they would ever reach the thing we were about to ship. But instead of questioning the roadmap, we tried to “save” it: smaller scope partial rollout reduced polish All ways of protecting a decision we already knew was outdated. Eventually we removed it entirely. Not postponed. Not moved. Deleted. And the smaller fix we shipped instead improved adoption more than the original feature ever projected to. That’s when I learned: Roadmaps fail when they pretend decisions don’t change. They aren’t plans, they’re bets placed with limited information. The real PM skill isn’t defending the roadmap. It’s rerouting before the team builds yesterday’s understanding. A roadmap isn’t credibility. Updating it is. #ProductManagement #ProductThinking #PMLife #ProductStrategy #DecisionMaking #BuildInPublic

The hardest PM skill isn’t prioritization. It’s saying no. In one of my AI projects, we had momentum. The system was improving. Metrics were trending up. Stakeholders were excited. And that’s when the requests started. “Can it also handle this edge case?” “Can we expand it to higher-risk scenarios?” “Can we add one more layer of intelligence?” None of them were unreasonable. In fact, they were good ideas. But we were still stabilizing core behavior. I had to decide: Add more capability or protect clarity? Every new feature meant: more failure modes more monitoring requirements more surface area for mistakes more operational risk Saying no didn’t feel innovative. It felt restrictive. But over time I’ve learned: Every “yes” adds complexity debt. And complexity debt compounds quietly. Velocity feels good. Focus scales better. What’s a feature you’re glad you didn’t ship? 💬 #ProductManagement #ProductThinking #PMLife #ProductStrategy #DecisionMaking #TechLeadership #AIProduct