When everyone on the payroll loves your prototype

You've just finished a prototype or an MVP.

It looks great. You've used AI for the first pass, and maybe you even ran it past your UX friend.

You're excited. You hold the meeting and invite your boss, their boss, and team members. You tell them how much time it took to build. Everyone slaps you on the back and tells you what a great job you did, except that one guy who points out that the shade of teal that you're using doesn't match the corporate branding guide.

What I've just described happens a lot with how people use AI, but it doesn't reflect how to build products customers are willing to pay for.

A prototype does two jobs; teams default to the one they get credit for

Building something is real. You can see it and experience it.

Fidelity helps here. A high-fidelity prototype removes ambiguity from a handoff in a way a written spec never will. Engineers love it because it gets them to work more quickly and keeps them from attending as many meetings to clarify what you meant.

The second job is learning. You put something in front of a person who doesn't work for you and find out whether the thing you're about to spend two weeks, months, or quarters working on is worth building. That job has almost nothing to do with fidelity.

Most teams do the first job well and then claim credit for the second. The prototype gets refined, reviewed, approved, and shipped, and at no point does it leave the org chart. Maybe some support tickets are reviewed, or a salesperson corners you, and you relent and include a feature because it is easy enough to show off a slick new design. What you've built is a very good internal agreement.

Whether customers (remember them?) are actually willing to pay for what you've built is another story.

The research has been there for thirty years

I could speak to my own experience, but I'm not the first to look into this, and while AI has helped to exacerbate the issue, the challenge has been around longer.

First, AI prototypes are great for creating a higher-fidelity view of what is to come. They help to set up the story that you're building. That said, spending a lot of extra busy time to build doesn't buy you a lot. Jeff Sauro's summary at MeasuringU walks through the record: Wiklund et al. in 1992 found no differences in errors or subjective ratings between paper prototypes and actual products. Virzi et al. in 1996 found no substantial difference in the usability problems surfaced by paper versus high-fidelity prototypes. Catani and Biers in 1998 tested three levels of fidelity and found no difference in problem detection.

Thirty years of people trying to prove that polish buys you better answers, and mostly finding that it doesn't.

I'm not saying don't do AI prototypes at all. One study found paper testing ran about 30 percent longer than a computer-based version and participants prefer the polished one, which matters when it comes to customer engagement.

Why we all stay inside the building

That shade of teal I mentioned earlier as being the biggest problem?

That's not an exaggeration. I was in the room when another product manager was showing what they were going to build. Unfortunately, neither the product manager nor designer on that project could defend their decisions, not even the shade of teal, because they hadn't talked with a customer in a month.

Prototypes left unvetted by the people who will use the end product only lift half the load. You can put it in a deck, walk your SVP through it, and get a decision. A customer conversation produces a story, a hunch, and contradictory quotes you couldn't have guessed.

Brad Dunn surveyed product managers on this and reported that at least half of respondents hadn't spoken to a customer recently. He's careful to say it isn't because they don't want to. I completely believe that for the most part.

The one thing I've never let go of

I've worked in fintech, insurance, compliance, enterprise BI, and generative AI, and the roles have looked wildly different. I've never dropped in any of them is the meaningful conversation with a customer. I mean an actual conversation with a person who uses the thing, where I shut up long enough to be surprised. A survey won't get you there and neither will an NPS score. Those are legit tools, but they're nothing like a conversation or watching a customer work in their natural setting.

Early in my career, I inherited an enterprise BI product that was being given away as a bundle sweetener. Internally, it was understood as a throw-in. Nobody had a prototype problem, because nobody was investing in it at all. Instead, I had a hunch somebody out there actually wanted it, so I went and found them. It took years, and it's not clear how many thousands of dollars were spent only for the new guy (me) to decide to pick up the phone to find what customers really valued.

What to do with this on Monday

Before your next prototype goes into a review, write down the question it's supposed to answer. If the answer is "so engineering knows what to build," good, that's a legitimate job, and fidelity is your friend.

Now ask yourself the other question: "How does the customer feel about what we're building?"

If that's not a comfortable question to ask or it's going to make you release slower, then take a step back and recognize that you're building the product for your customer.

Build a prototype the customer can meet up close and personal. Be comfortable with something ugly. A spreadsheet, a clickable mess, a conversation with a whiteboard behind you. The research says you'll find most of the same problems. The customer will not judge you for the typeface. (That teal, however. Ick. THE WORST.)

If we were building together, I'd ask you this: in the last month, how many hours did your team spend improving the prototype, and how many did it spend with someone who isn't on the payroll?

I'd also ask, What's the last thing a customer told you that changed a design decision, and how long ago was that?

Sources

MeasuringU, Does the Fidelity of a Prototype Affect Results?

Nielsen Norman Group, UX Prototypes: Low Fidelity vs. High Fidelity

Singularity Hub, Don't Guess, Learn: Rapid Prototyping with Tom Chi

TED Blog, Google Glass: prototyped using binder clips and clay

Brad Dunn, The Great Silence: Why have Product Managers stopped speaking to customers?

If you're reading this because something in your own product or team is stuck, that's usually where I come in. I work with founders whose product exists, but the revenue doesn't. The first step is always a conversation, not a contract.

NEED HELP WITH YOUR PRODUCT OR TEAM?

A free 30-minute call to discuss your product challenge and see if it really requires a regular consulting engagement to work through.

Consulting

Coaching

© 2026. All rights reserved. Terms of Service Privacy Policy Contact me