What I heard about AI and prototyping at INDUSTRY 2025

Last week I was at INDUSTRY 2025 and took copious notes on all of the presentations. My main motivation for doing that was because I was the “official” note taker for the conference.

I also take on that assignment because it forces motivates me to pay attention to all the sessions. I find that I often pick little nuggets out of almost every session, which I many not have had I not had the responsibility of taking notes for others.

After being back from the conference for a few days, I’ve had the time to reflect on the things I heard and I realized there were a few themes of relevance to people working on internal products that I thought I’d share. Over the next few weeks I’ll share those observations.

I’ll start the series of posts with an AI topic. Specifically AI and prototyping.

AI can help you prototype to build shared understanding

There were a lot of sessions about AI.

A lot.

In fact, half of the sessions I took notes on focused on some facet of AI and its relation to product management. A couple of presenters in the other half even took pride in not mentioning AI.

Fortunately, none of them mentioned the title “AI Product Manager”.

The sessions generally focused on how to use AI to be a more effective product manager or things to consider when incorporating AI into your product.

One thread that I picked up discussed using AI to create prototypes – not necessarily your actual product – to build shared understanding.

Get to code faster

Oji Udezue, Partner at Product Mind, discussed the three speed trap and pointed out that the speed of building is increasing much faster than the speed of discovery and go-to-market. One way to address the difference in rates of acceleration is to change how you build shared understanding amongst the product team.

As Oji put it, you need to figure out how to get to code faster. More specifically, use AI to create a prototype so that “Your PRD is now in the form of a full code prototype with annotations.”

Build to learn

Vrushali Paunikar, Chief Product Officer at Carta, explained how Carta builds great product teams. One of her four pillars is build to learn, which means creating prototypes and using that prototype to get feedback from users. In Vrushali’s own words:

You can learn so much by spinning up prototypes, putting them in front of real users, validating interaction patterns, and more. Prototype. Build. Learn. And do it fast.

Based on some of my own experiences, recent and not so recent, this makes a lot of sense. You’re going to get a lot more useful feedback from users if they have something fairly close to your product to play around with. Much more so than handing them some sort of requirements document.

Don’t forget the people

Prerna Singh, CPTO at Avaaz, explained how to use AI for rapid prototyping by describing how she created a prototype of an app that would help organizers be connectors.

Prerna noted that AI prototyping is not about perfect code or shiny tools. It’s about giving you a faster way to learn from humans, to test with humans, and to build for humans.

She stressed that even if you use AI tools as a product manager, the best part of building a product is the human side: your judgement, your creativity, and your product sense.

Know what you’re trying to accomplish when you use AI

Shortly after ChatGPT came out, folks started promoting the use of generative AI to write their user stories. I always thought that suggestion missed the point about the actual purpose of user stories. Still, I get that people who made that suggestion saw writing user stories as a chore and relished the opportunity to automate it.

When I heard these different perspectives about using AI for rapid prototyping, and then using those prototypes to interact with people, I realized it could be the best of both worlds.

So if you find yourself in a situation where you want to use AI to generate your user stories, consider using AI to build a prototype instead. Annotate that prototype and use it to get feedback from your users and to build shared understanding with your product team.

Of course you may want to make sure your product team will find the prototype a helpful source of information for collaborating about your intended solution.

Thanks for reading

Thanks again for reading InsideProduct.

If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, let me know.

Talk to you next time,

Kent