Skip to main content
Back to catalog
Lesson April 14, 2026 4 min read

The Prototype Always Wins the Argument


During COVID lockdown, Blue Cross needed to bring people back into the office. Mandatory health questions, vaccination documentation, HIPAA compliance — the works. Multiple teams were discussing solutions. Requirements were being gathered. Vendor evaluations were starting.

I built a chatbot in days. Used Azure’s out-of-the-box capabilities, made it HIPAA compliant, and shipped something that let every returning employee answer the mandatory questions and submit their documentation. Security used it at the door to validate during temperature checks. It went to production.

Nobody asked me to build it. I just did — using AI-assisted development — because I knew a working prototype would answer every question a committee was still debating.

The Pattern: Why Prototypes Beat Slide Decks

This keeps happening. Not because I’m reckless — because I’ve learned that nothing gets a zero-to-one initiative funded faster than something people can touch.

At Ford, I championed an ML model to optimize data center cooling. The concept sounded expensive and risky in a slide deck. When the team could see it working — watch it reduce energy costs in real time — the conversation shifted from “should we invest?” to “where else can we apply this?” That model saved $1.6 million a year.

At Blue Cross, an engineer and I prototyped an indoor navigation feature — using customers’ app location to guide them to the right care provider, including precise navigation inside the building. I drove the concept and testing, the engineer built it. The prototype worked well enough to demonstrate the idea. Then it hit reality: we needed building maps and physical hardware installed at every site. The infrastructure requirements made the approach impractical at scale. We didn’t go forward. That was the prototype doing exactly what it should — killing an idea in weeks instead of letting a full team discover the same limitations in months.

When Prototypes Kill Your Own Ideas

I call this the build-first approach: when the debate is theoretical, make it tangible. A strategy deck invites abstract objections that can continue indefinitely. A prototype invites specific feedback that makes the product better.

But prototypes also kill bad ideas faster — including your own. I’ve built things that proved my hypothesis was wrong. That’s not failure. That’s the prototype doing its job. Better to learn in week two that your assumption was off than to discover it in month six after a full team has been building on it.

The COVID chatbot didn’t wait for a vendor evaluation. The ML cooling model didn’t wait for a full business case. The navigation prototype didn’t wait for a feasibility study — and when it hit reality, it killed the idea cleanly. Building maps and hardware at every site wasn’t practical. We learned that in weeks, not months.

That indoor navigation prototype is the one I think about most. Not because it shipped — because it didn’t. An engineer and I built it, tested it, and walked away knowing exactly why it wouldn’t scale. No months of planning. No committee discovering the same limitations after a full investment. Just two people, a prototype, and an honest answer.


Facing a similar challenge?

Let's talk →