AI PM Bootcamp
I recently attended an AI PM Bootcamp with Dan Olsen from The Lean Product Playbook. The workshop consisted of: upfront theory on product management in the AI era, a hands-on workshop where we built working prototypes, and a panel discussion with AI product leaders. I walked away having learned a lot and am excited to put these skills to use.
The Theory: PM Fundamentals Don't Change
Dan started by walking through the fundamentals of product management. The core process hasn't changed: you need to understand your market, know your target customers and their problems, and only then build features that deliver value with the right UX. This is table stakes stuff, but it's easy to forget.
One of his cautions was: in the AI age, it's incredibly easy to jump straight to the solution space. You can start building features before you've actually validated that there's a problem worth solving. This isn't new, we've known for a long time that 80% of products fail, largely because teams build solutions before verifying the problems they're trying to solve. But AI amplifies this risk. It can help you test hypotheses much faster if you use it right, or it can hurt you by letting you build a ton of stuff very quickly that doesn't actually solve anything meaningful.
The Vibecoding Spectrum
One of the most useful frameworks Dan shared was his "vibecoding spectrum." This is a categorization of AI-powered building tools ranging from non-technical tools aimed at designers and PMs to very technical tools targeted at developers. He walked us through the purpose of each tool and who should be using it.
He also made an important distinction between vibeprototyping and vibecoding. Vibeprototyping is about using these tools to quickly create prototypes and UX flows that you can test with users. Making something they can look at, touch, and interact with to validate whether you're on the right track. PMs can then hand these prototypes to engineering teams to show "here's what I'm looking for." Vibecoding, on the other hand, is more about tools like Cursor or Claude Code that developers use to become more efficient in their actual development work.
The Return of the PRD
Another thing that really stood out was Dan's emphasis on PRDs (Product Requirements Documents). He shared his template for writing effective PRDs. For a while, PRDs were kind of falling out of fashion, teams were moving toward more lightweight specs or just working directly from user stories. But with these vibeprototyping tools, you really need to have a solid PRD again.
The more context and direction you can give to the AI, the better job it's going to do. So you want a detailed PRD, but even more than that, you want to write it in a way that's clear for AI tools to parse and understand. It's a subtle but important shift in how we think about documentation.
The Workshop: Building PM Compass
We then spent four hours hands-on (or hands-off thanks to AI) building a prototype. We could use any of the tools Dan had walked us through or any others we wanted to try. The goal was simple: build a product using AI to do as much of the heavy lifting as possible.
I built a Chrome extension for product managers called PM Compass. Here's the problem I was trying to solve: when I'm researching companies, I want to know more than just what's on their website. I want to know what the company is like: how old is it, have they raised funding, how many people work there? I want to understand the type of company that's building the product I'm looking at.
I also want to know who the people are who are building it, specifically, who's on the product team. And I'm curious about what they're hiring for right now. When I'm doing competitive research or company research, knowing what roles a company is hiring for tells me a lot about where they're headed and what they're prioritizing. And when I'm job hunting, I want to quickly find jobs at companies that are building products I'm interested in.
So when you visit a website my extension gives you a summary of what the company does, shows you the product team with their contact information, and displays open positions. It has some nice features specifically for product work: you can grab team members' emails, go directly to their LinkedIn profiles, and for job postings, there's an email option that uses the Claude API to draft a personalized outreach email. It even pulls in context about the people on the product team so the email can be properly addressed.
This scratches an itch I have all the time. Instead of going to Crunchbase to learn about the company, then to LinkedIn to find people, then to the company's jobs page to see what they're hiring for, I can do it all in one place. And while I built this for PMs, you could easily adapt the extension for sales teams or marketers by tweaking the context and focus.
You can watch a demo of it in action in this video:
Want to try it for yourself? Get the code here.
The Power of a Data Moat
One thing that became really clear while building this prototype (and this goes beyond just the workshop) was seeing the power of having a data moat. To get company information and people data, I needed to integrate with third-party APIs. I looked at ZoomInfo, Crunchbase, and ended up using Apollo.io.
All of these options are very expensive. Most have free trials or free accounts, but they're extremely limited in what information you can access and how many queries you can make per month. For the prototype, that was fine, it was enough to prove that it works. But to use something like this long-term, you're looking at spending $50 to $100 per month just to retrieve this information.
The licensing is also very restrictive. I can't just scrape a bunch of data and share it with others, it's only for my individual use. So for this extension to work long-term, each user would need their own API key, which makes it prohibitively expensive for most use cases.
But here's the interesting part: this was a great demonstration of the market value and pricing power you have if you can build a moat around proprietary data. If I had my own database of company information and team contacts, I could build products like this without being constrained by expensive API limits. The data is the moat, and it's a powerful one.
Building More, Learning Faster
The bootcamp reinforced something I've been feeling for a while: we're in a unique moment where the barrier to building functional products has never been lower. With the right AI tools and a solid understanding of the problems you're trying to solve, you can go from idea to working prototype in hours instead of weeks.
But the core lesson remains the same as it's always been in product management: start with the problem, not the solution. AI just makes it easier to validate your hypotheses quickly - or to waste time building the wrong thing faster. The difference comes down to discipline and focus on real user needs.
The tools are here. The techniques work. Now it's just a matter of building more, learning faster, and shipping products that actually solve real problems. That's what I plan to do next.