• Out of Scope
  • Posts
  • 🚀 AI Prototyping Is Magic. Here's the catch.

🚀 AI Prototyping Is Magic. Here's the catch.

Building something is now incredibly easy. Building the RIGHT thing? That’s still incredibly hard.

Before we begin, shout-out to Roshni for being the first reader to reply with the correct answer to last week’s riddle!

One of the worst feelings is missing out on something. When I was young, all my friends had Heelys and I felt lame still having to walk places while they rolled around. I remember being incredibly sad and telling my parents. For my birthday, my parents—not wanting their son to be a loser—got me shoes that convert into roller skates. Not Heelys, mind you, but shoes where you could pop off the bottoms and pull out wheels and turn into actual roller skates.

There's an important lesson here: there are many different solutions to a given problem, but only one might actually solve YOUR problem. And that I’m still waiting for a pair of Heelys.

Right now, there's a massive shift happening in product management. A director of product at Google recently stated they're moving from a writing-based culture to a building-first one: "Writing was a proxy for clear thinking, optimized for scarce eng resources and long dev cycles - you had to get it right before you built. Now, when time to vibe-code prototype ≈ time to write PRD, PMs can SHOW not tell."

AI prototyping tools like Lovable, Bolt, Vercel, and Replit can turn text prompts into working software in minutes. It feels like magic—and honestly, it kind of is. Like discovering you're a wizard at Hogwarts, except instead of casting spells, you're shipping products. “You’re a PM, Harry.”

But here's the thing about magic: it's powerful, but it doesn't solve every problem. And just like my parents' well-intentioned roller skate shoes, the wrong solution—even a working one—can leave you still walking while everyone else rolls by.

What AI Prototyping Excels At

For this newsletter post, I built a tool called PackWise (check out those vacation vibes) that helps you figure out what to pack for vacation based on the weather at your destination. From idea to working prototype in about 5 minutes. At tendercare, we've discovered three killer use cases for this approach:

1. Getting team buy-in on ideas. Nothing beats showing over telling. When you can demo a working version of your feature, stakeholders immediately understand the vision.

2. Uncovering blind spots in your thinking. When I had Lovable build PackWise, it added a dropdown for "type of trip"—something I'd never considered. The AI filled gaps I didn't even know existed.

3. Getting user feedback without engineering investment. You can test core assumptions and user flows before writing a single line of production code. You can quickly figure out what parts of the feature work or don’t work.

This is where prototyping absolutely dominates traditional approaches. For the solutioning and designing part of the product process, it's genuinely 10x better.

Building vs. Building Right

But here's where things get tricky. While PackWise looks and works great, the weather data is completely fake. When I asked Lovable why, it explained it had hardcoded the data—I'd need to integrate a real weather API for accuracy.

This perfectly illustrates the limitation: building something is easy, but building the RIGHT thing is still hard.

If you jump straight into prototyping without defining the problem space, you narrow your solution set immediately. You get a solution fast, but not necessarily the best solution. It's the product equivalent of getting roller skate shoes when you needed Heelys.

Sequence, Don't Replace

This is why I'm not throwing my PRDs in the trash yet. The beginning of the product process—discovery, problem definition, exploring solution spaces—still benefits from good old-fashioned thinking and writing. We write to gain clarity, not just to produce documents, contrary to popular belief.

Here's the workflow that I’ve been using recently. 

Step 1: Start with problem definition (traditional PRD approach)

  • What problem are you solving?

  • What is informing this problem?

  • What's the hypothesis?

Step 2: Generate solution options. Feed your problem definition into ChatGPT with this prompt: "Based on this problem definition [paste PRD], generate 5 different solution approaches. For each approach, explain the core user flow and key features."

Step 3: Choose and prototype. Select your best solution concept and ask ChatGPT: "Turn this solution concept into a detailed prompt I can use with [Lovable/Bolt/etc] to build a working prototype. Include specific UI elements, user flows, and key features."

Step 4: Test and iterate. Use your prototype to validate assumptions with users and stakeholders, then refine.

The Bottom Line

AI prototyping isn't going to replace strategic thinking—it's going to supercharge it. The PMs who figure out the right sequence (think, then build, then iterate) will run circles around those who go straight to prototyping or those who stay stuck in document land.

Just remember: there can be many different solutions to one problem, but there's still only one Heelys. As a PM, always make sure you're building the right thing, not just the first thing that works.

The Riddle

What has a head but no brain?

First person to reply with the right answer gets a shoutout in next week's newsletter!

The Meme

Still less vague than 99% of job postings