A single AI-generated prototype saved our startup 2 weeks of design time and prevented a $50K engineering mistake.

📊 Results at a Glance:

Here’s how we used AI to solve the eternal product dilemma: how do you validate complex features without overcommitting resources up front?

The $50K Product Decision Dilemma

In my last role as Head of Product & Design at a Series A startup, I held a weekly checkin with product, design, and engineering to align on priorities, challenges, and coming roadmap items.

When discussing an upcoming feature, we would outline what it was for and needed to accomplish. These conversations would help both engineering understand the business case and help product understand the technical implications of these requests, as effort is a key input into prioritization. It also gave engineering the ability to propose entirely different solutions – a super helpful exercise, but is only possible if they fully understand the desired outcomes.

Prod/Eng, as we called it, was really powerful and helpful to build alignment. But collaborating on future roadmap features was challenging when trying to explain a concept using only words. PRD’s were often not read ahead of time, if at all.

Engineering estimates are hard enough as it is. Too frequently, we learned too late that we didn’t have actual alignment or understanding once the feature starts to get built. That misunderstanding is expensive, leading to scope creep, re-work, delayed releases and limited capacity for subsequent features.

I’m a big believer in showing vs. telling (thanks, high school English!). My teams over the years have heard me repeat ad nauseam my mantra – “Nobody can imagine anything,” – which is a rude way of saying that most people need a visual aid to understand and react to a concept.

Why Visual Prototypes Beat Requirements Documents

In the past, we’d present these ideas by providing any context we could. What the feature is, why we are doing it, whats the business value, etc – as a PRD, voice over, or a slide. But the harder part was often describing the feature or functionality without a clear visual representation, as these features were frequently ahead of the design stage. This created a chicken and egg problem – we didn’t want to assign limited design resources to create these visuals because we weren’t sure if we were going to prioritize it. But, it was hard to prioritize it if we couldn’t accurately estimate how hard it would be, which requires visuals!

This created a chicken and egg problem – we didn’t want to assign limited design resources to create these visuals because we weren’t sure if we were going to prioritize it. But, it was hard to prioritize it if we couldn’t accurately estimate how hard it would be, which requires visuals!

Building an Approval Flow in 1 Hour

We needed to add a user approval workflow for a specific kind of customer data. In the product, data would flow into the customer environment, and the customer would need to approve this data before it became “live.”

For this feature, I prototyped a proposed approval flow in v0.dev. It took an hour – and most of that time was spent confronting my own assumptions about how it should work. But at the end I had a clickable coded prototype of the proposed interaction that I could present and share during the Product/Engineering meeting. Everything worked, including the math.

What We Learned About Engineering Estimates

The prototype let everyone see a version of the end goal along with my voiceover explaining the why. It was now immediately clear what we were trying to accomplish. The prototype clarified use cases, data needs, and product areas impacted. It also surfaced early updates we could make to the infrastructure to support these changes.

Additionally, engineering loved it. They could clearly see what was being asked, and their questions got more pointed and tactical. Where previously we might have spent half the meeting setting up the idea, this approach made an opaque ask much more transparent.

The Business Impact

In the case of this approval flow, it was a decent size lift, but actually smaller than the product team anticipated due to the way the data model was originally designed. A pleasant surprise! But it did require some updates to that model. For example, we needed an additional column of data that the current experience did not have. We could prioritize this part of the feature in advance, so it was ready when it came time to build the full experience – plus there is incremental value to the user in the meantime. There are often small steps like this that can be taken early that set us up for success down the road.

Having this level of clarity on the overall lift helped us slot it into the roadmap, which we could then communicate to the larger business, especially to those who had customers waiting for the feature.

We de-risked the unknown, preventing $50K in unwanted engineering spend that would have resulted from miscommunication. We calculated this by analyzing our historical cost per story point, re-open rates, and the estimated size of this epic.

Challenges

This isn’t a silver bullet, and has challenges of its own.

First, make it clear that this isn’t the final execution, but just a prototype and thought starter. Keeping it lower fidelity helps with that. Often engineers will react directly to the design and think of what it would take to build exactly that. You have to contextualize it.

And in terms of workflow, this wasn’t production ready by any means. Once we had alignment, we used the prototype as a starting point for the designers to use as an input. From there, they would create the design in Figma using our component library, while accounting for the full spectrum of edge cases built into complex enterprise workflows. It then slot into our normal development process.

However, these are small prices to pay for what we got out of it.

Lessons for Product Leaders

The goal here isn’t to fully design the feature, think of every edge case, or add design polish, but rather to give enough context as to be a substantive thought starter. Think of it as a wireframe on steroids. It lacks some visual and interactive polish, but gives a rough idea of what the content, user flows, and architecture of the experience will be. It surfaced the relevant data, the general workflow, and the desired product outcome of the feature.

It took a concept that might have been difficult to explain, and allowed the team to build alignment on how to tackle it, how much work it would be, and when we could do it. The product team could then communicate this confidently to other stakeholders.

By using prototypes to make abstract ideas concrete, we empowered our teams to move faster, align earlier, and build with more confidence.

---

How to create your prototype – a tactical guide:

For teams ready to implement this approach, here’s the step-by-step guide:

1. Create a PRD for your feature or functionality using ChatGPT/Claude.
2. Have ChatGPT/Claude turn that PRD into the prompt for v0 (or your tool of choice)
3. Feed the prompt into v0, have it make the first pass at your prototype
4. Update prototype with incremental improvements and edits as you start to use it
5. Upload existing application screenshots to v0 and ask it to update the prototype using those styles (it shouldn’t be perfect, but should look like it lives in the same universe as your real application).

I personally like v0, but you can use Bolt, Lovable, Magic Patterns, or whatever tool you fancy and/or have company access to.

Ready to cut your feature validation time by 90%? I help product teams implement AI-powered prototyping workflows that eliminate costly misalignment. Let’s discuss how this could work for your team.

---