A product manager at a faith-tech startup asked me after a workshop: “Are AI prototyping tools worth the hype? Should my team jump in?” My answer was direct: they can be genuinely useful — but only if your team has already done the discovery work that tells you who you’re building for and what they actually need. Without that, AI prototyping doesn’t accelerate your work. It accelerates your mistakes.
I’ve watched this play out on a curriculum tool I worked on for children’s ministry volunteers. We had AI tools that could generate wireframes and mockups overnight. The output was slick and fast. What we didn’t have was a clear picture of how volunteers actually used the product — that they were prepping lessons in seven-minute windows, on their phones, while something else was happening in the background. Once we spent time with real users, everything changed. The prototypes we’d built before that conversation were solving for the wrong constraints entirely.
The Discovery Gap That AI Prototyping Can’t Fill
The promise of AI prototyping is speed — faster wireframes, faster iteration, faster path from idea to testable artifact. That promise is real. The problem is that speed only creates value when it’s pointed at the right problem. Teams that skip discovery and reach for prototyping tools first end up with a faster path to the wrong answer.
Teresa Torres’ continuous discovery framework makes this argument precisely: product teams need to be constantly testing assumptions with real users, iterating on outcomes rather than outputs. AI prototyping can accelerate the artifact side of that loop, but it cannot generate the user insight that makes the artifact worth building. That insight only comes from talking to users — and most teams are doing far less of that than they think.
The tell that a team has skipped discovery: their prototype feedback sessions produce surprises. Users don’t understand the flow. The feature solves a problem the team assumed existed but users don’t recognize. The navigation makes sense to the team and nobody else. These aren’t AI prototyping failures — they’re discovery failures that AI prototyping revealed faster than a slower process would have. The tool surfaced the problem. The problem was upstream.
When Speed Becomes a Liability
There’s a specific failure mode I’ve seen in teams that adopt AI prototyping without strengthening their discovery practice first: they ship faster, get feedback faster, and — because they haven’t grounded the feedback in clear user outcomes — misread what the feedback means. They iterate on surface signals rather than structural problems. The prototype improves visually while the underlying user need goes unaddressed.
On a cross-functional team I worked with, we used AI tools to generate a series of mockups for a new feature in rapid succession. The PMs were hitting deadlines. The designers were producing great work. The engineers were ready to build. And the users, when we finally got in front of them, had no idea what the feature was for. We’d built consensus within the team about what to build, but we’d never built consensus with the users about the problem we were solving.
Torres’ framing is useful here: teams that do continuous discovery are constantly checking their assumptions against reality. Teams that don’t are building confidence in a direction without checking whether the direction is right. AI prototyping accelerates confidence-building. It doesn’t check whether the confidence is warranted.
How to Use AI Prototyping Correctly
The right sequence is discovery first, prototyping second. That means before any AI tool generates a single wireframe, the team should be able to answer three questions: Who is the specific user this prototype is for? What decision or task are we trying to make easier for them? What does success look like for that user, in their terms?
When those three questions have answers grounded in actual user conversation — not assumption — AI prototyping becomes a genuine accelerant. You know what to build. You have a clear evaluation criterion. User testing produces signal rather than surprise. The tool is pointed at a real target.
The teams I’ve seen use AI prototyping most effectively treat it as a way to test specific hypotheses faster, not as a way to generate options when direction is unclear. That distinction matters. Options without direction produce more meetings. Hypothesis tests with direction produce learning.
Your Turn: Apply This Today
Before your team runs another AI prototyping session, make sure the discovery foundation is in place. Here’s how:
- Answer the three questions before opening the prototyping tool. Who specifically is this for? What task or decision are we making easier for them? What does success look like in their terms? Write the answers in the meeting doc before anyone opens Figma or any AI design tool. If the team can’t agree on the answers, that’s a discovery gap — not a design problem.
- Schedule user interviews before your next major prototype. Not after — before. Even two 30-minute conversations with real users will surface assumptions you didn’t know you were making. The time cost is real. The cost of prototyping in the wrong direction is higher.
- Run a “who is this for?” check on every active prototype. Look at your current prototyping work and ask: can we name a specific real user whose life this will improve, and can we describe specifically how? Prototypes that can’t pass this check are building team alignment, not user value. Both have their place — but they’re not the same thing.
- Separate exploration prototypes from validation prototypes. Exploration prototypes are for generating team ideas. Validation prototypes are for testing specific user hypotheses. AI tools are excellent for exploration. They’re only useful for validation if the hypothesis is already sharp. Know which mode you’re in before you start.
- Debrief on what you learned from the users, not just what you’ll build next. After every user test, the first question in the debrief should be: what assumption turned out to be wrong? Not “what should we change in the prototype?” — what did we assume that the user didn’t confirm? That learning is the asset. The updated prototype is the output.
- Read one chapter of Torres’ “Continuous Discovery Habits” with your team this month. It’s the clearest articulation I’ve found of what a disciplined discovery practice actually looks like in a product team. Pick one chapter, discuss it in your next team meeting, and identify one habit to adopt. The investment pays back faster than most product tools will.
AI prototyping and discovery are both part of the broader question of how teams stay grounded in user reality as AI capabilities expand. Why Teresa Torres’ Continuous Discovery Cadence Is Breaking Down in the AI Age addresses how the discovery framework itself needs to evolve when AI is part of the solution space. And How AI Prototyping Can Break Silos in Faith-Tech Products covers the team alignment dimension of prototyping that this post focuses on the discovery dimension of.
Trying to build a stronger discovery practice in your product team so your AI investment is pointed at the right problems? I consult with product leaders on user research systems, discovery cadences, and the habits that close the gap between what teams assume and what users actually need. Let’s talk.