(Note: this post also appears on Medium)

I think the single most impactful thing a PM can do right now is to learn to use AI to build great prototypes.

I’ve always been a fan of prototypes over static designs or requirements documentation. When I coach product teams, I often say that I hate PRDs, which surprises most people since they didn’t really know there was an alternative.

Laying out high level concepts and “why us/why now” sort of stuff is fine in a document — I personally like the Opportunity Assessment idea popularized by SVPG — but when you are actually trying to build something, I think a well constructed lo-fi prototype with a story map is by far the best way to express your intent for that build.

Let’s do a quick bakeoff:

Pros of prototypes:

• Prototypes are useful inputs to the hi-fi design process, and offer opportunities for UX/design/engineering collaboration
• You can test and validate your prototypes with real users!
• Your prototype and story map are living documents — you can update them as your product evolves, more so than with PRDs (IMHO)
• PRDs contribute to the perception that product managers are paper pushers, not part of the creative process in the same way design and eng are — whereas prototypes can put PMs on even footing

Cons of prototypes:

• No common toolkit across roles — PMs might use Balsamiq, designers Figma, engineers might just branch the existing app code
• Prototypes are perceived as expensive, relative to documentation — it can be hard to pull resources away from design and dev for prototypes
• Change is scary! People understand PRDs and what to do with them — prototypes don’t always fit as neatly into existing processes, and threaten some of the traditional role separation between team members

TL;DR: Prototyping can help the team collaborate better (esp product and design), and get more quickly to usable data and/or inputs to the build itself. But most teams don’t do it because it seems expensive, and because most delivery processes presume hard handoffs from product to design and again to developers, which makes sense given that each role brings a different skillset and toolkit.
AI removes or reduces some of the major items on the Cons list:

• There’s been a Cambrian explosion of AI powered no-code and low-code tools; to mention a few, there’s bolt.new, v0.dev, create.dev, Replit Agent, etc. It’s easier than it’s ever been to convert high level requirements or ideas to visual designs, and/or real code.
• These new tools are both inexpensive by any measure, and accessible across roles — PMs, designers, and engineers can all use them and get great results.
• It’s even possible (although this is graduate level work!) to wire this prototyping process directly into your production process in many situations. But there’s value in prototyping even if you still have to lift and shift your validated features into production code.

So why am I going on about this? Prototypes are cool, they’re cheap now, AI AI AI, blah blah blah.

The reason is: I think the single most impactful (and job security enhancing) thing a PM can do right now is to learn to use AI to build great prototypes.

Here’s my rationale:

In small/nimble teams, AI is already enabling people to a) get more done with less effort, and b) rethink team size and structure. I’ve always recommended the power trio to my coaching clients — a PM, designer and engineer working in close contact discovering and validating the product backlog — but increasingly I think you’re going to see those roles combine to reduce overhead. Maybe it’s a pair, with one design-minded product person and a producty engineer — or maybe you have one person delivering full stack with fractional help on devops, growth, design, etc.

Side note: Arguing for more headcount is going to be increasingly hard going forward when tiny teams are kicking ass — maybe you just remove all distractions and invest in giving that team more space, since scaling almost inevitably slows you down, at least in the short term. This would have sounded crazy 2 years ago, but here we are!

So for these small teams, learning to prototype is a step in the direction of learning to design and/or code, and this makes PMs the true triple threats — blending product sense with practical delivery skills. You may still depend on engineers or designers — that’s OK! But you will collaborate better the fewer PRDs and more prototypes you produce.

In medium size companies, there’s going to be a ton of pressure to cut costs, full stop. I’ve heard anecdotally about CTOs being told that their budgets are going down 10% per year, every year, forever — both because AI improves productivity but also because the age of growth at all costs, and stockpiling engineers as a scarce resource, is officially over.

Shrinking teams are never fun. You’re asked to do more with less, while the ground shifts beneath your feet. For PMs specifically, learning to use AI tools to prototype is a way to cope with these changes and resource constraints by increasing your creative capacity, and as tools and models improve, it’s likely that you’ll be able to orchestrate increasingly complicated builds with less and less external help. But to be blunt, I don’t think most people in this situation are going to be having much fun as the walls start to constrict.

In larger teams and companies, I think there’s a much wider range of possibilities. The outcomes will range from a) almost no change at all to business as usual, largely because of regulations on the use of AI or corporate mandates, to b) Game of Thrones politics like you’ve never seen, where you’ll just have to figure out what the org values, retool in real time, and cross your fingers, to c) transformation efforts which are well intentioned but may deliver their first results sometime in the early 2030s.

But in each of these cases, it is going to be hugely valuable for PMs to learn to use AI to prototype. In the absence of real workflow changes, PMs can still get much better at their jobs by delivering prototypes (and story maps — anything but a PRD!) as their version of requirements. Again, the main objection to prototypes has historically been cost and the implied workflow changes — but the cost is now radically reduced, and by delivering prototypes as requirements, you as a PM aren’t asking everyone else to change how they work. You’re just making your own work more efficient and effective.

Of course, your mileage may vary with all of this. If you’re a PM who really only interacts with your team through the occasional backlog ticket and spends a lot more time interfacing with the business, you may think this is all insane. It depends on your situation, and on the expectations your team has of you (and vice versa). But I strongly believe that the way we build software is going to change so radically in these next years that we will probably all have to come up with new job descriptions, which use parts of our current expertise but demand a lot of novel skills, mostly AI powered. Learning to prototype is the first and easiest step on that journey for almost anyone with Product Manager in their title.

Bonus link: Lenny’s Newsletter just ran a great piece on specific tools and tactics to get started with PM prototyping — highly recommend checking it out.

Thanks for reading! Would love your feedback.