The Beauty and the Beast

Hello everyone. I'm Michael, and welcome to Elgizmo.

[Pause]

There’s a line from Elon Musk that has stayed with me for a while:

“Everything looks great on PowerPoint.”

And the more I build things, the more I understand what he meant.

Because a beautiful presentation can make an idea look finished.

But an ugly prototype tells you whether the idea is actually alive.

[Pause]

I’ve been thinking about this because, at different points in my life, I’ve been attracted to both sides.

The beauty is the pitch deck.

Clean typography. Carefully chosen colors. Nice diagrams. A market chart going up and to the right. A product mockup where nothing crashes—because, well, the product doesn’t really exist yet.

The beast is the prototype.

It’s rough.

Something breaks.

The spacing is wrong.

Half the features are missing.

There are shortcuts everywhere, and you know exactly where they are because you put them there.

But it does something.

And I’m increasingly convinced that this matters more.

[Pause]

My relationship with computers started long before I knew anything about startups.

Around 1995, I first used what I remember as a 386-era PC running DOS.

At the time, I didn’t know anything about processor generations. It was just…the computer.

I played Prince of Persia.

I experimented with turtle graphics, typing commands and watching lines and shapes appear on the screen.

And there was something magical about that.

But I think the magic came from the interaction.

You typed something.

The computer responded.

Sometimes it worked.

Sometimes it didn’t.

Then came newer PCs. The Pentium era. Legend computers—the brand that later became Lenovo.

And then years of Windows.

Windows 95.

Windows 98.

Windows Me.

Windows 2000.

XP.

Later Vista and Windows 7.

I installed operating systems. Reinstalled them. Installed software. Changed settings I probably shouldn’t have changed. Broke things. Tried to fix them. Sometimes I learned which files mattered only after deleting the wrong one.

[Laughs slightly]

That was how I learned. Not by understanding everything first. By touching the thing. Breaking the thing. Then trying to understand why it broke.

[Pause]

I remember playing Rayman too. At the time, it felt incredibly rich and alive compared with a lot of the games I had seen before.

And somewhere in those years, I spent hours practicing typing with a really simple program.

I can’t even remember what the software was called. I barely remember what it looked like. But I remember what happened.

I got faster.

And that’s interesting.

Because that little program wasn’t memorable because it was beautiful. It was memorable because it worked.

None of this came from a slide deck. The thing was there in front of me. And I learned by using it.

[Pause]

Years later, I applied for a job at Apple because I genuinely wanted to help people. I liked technology, but what interested me most was what happened when technology stopped making sense to someone—when something broke, when they felt stuck, or when they just needed somebody patient enough to explain it.

So I applied to Apple. And I brought an IBM ThinkPad to the interview.

[Pause]

Looking back, that is pretty funny.

My presentation was about helping Windows users transition to Mac. There was one obvious problem. I had never really used a Mac.

I didn’t own an iPod either.

I was applying to Apple without really being an Apple person.

But I understood Windows users because I was one of them. I knew what it felt like to install software, dig through settings, troubleshoot something that suddenly stopped working, and try to figure out why the machine was behaving differently from what you expected.

I didn’t know the Mac yet. But I understood the person who might be nervous about moving to one.

And that was really why I wanted the job in the first place—not because I already knew every Apple product, but because I wanted to help people feel more confident with technology.

Working at Apple later reinforced something I had already started learning:

technology becomes real when another person touches it.

A feature can make perfect sense to the person who designed it and still be confusing to the person using it. A solution can be technically correct and still fail to solve the problem.

Reality keeps editing the design.

[Pause]

Much later, I studied entrepreneurship through Wharton. And I learned another side of building.

How to identify a customer problem. How to describe an opportunity. How to think about markets. How to position a product. How to tell a story. And, of course, how to build a pitch deck.

These are useful skills. I still think storytelling matters enormously.

A useful idea that nobody understands may never get the chance it deserves. A founder needs to explain why something matters. A team needs a shared picture of where it is going. Investors, partners and customers need enough clarity to decide whether they want to come with you.

So presentation matters.

But while learning to pitch, I discovered something slightly uncomfortable.

It is remarkably easy to make a product that doesn’t exist look convincing.

I did it myself.

I created the pitch deck before I had the product.

The customer journey looked logical. The diagrams connected beautifully. The value proposition fitted neatly onto the slide. The future looked surprisingly organized.

And nothing crashed.

Because nothing existed yet.

[Pause]

PowerPoint is an extraordinarily forgiving development environment.

[Laughs]

And that brings me back to that Elon Musk comment.

His point was simple. If you’re starting something, try to build a working prototype. Even if it’s primitive. Because everything can look great in PowerPoint.

But once something actually works—even badly—you’ve crossed into a different kind of conversation.

And I think the word primitive matters.

The first prototype doesn’t have to be beautiful. It doesn’t have to contain everything you eventually want to build. It needs to expose the idea to reality.

And reality is much less polite than PowerPoint.

[Pause]

A pitch deck can tell you what a product could do. A prototype starts telling you what it actually does.

Does somebody understand the interface without you explaining it? Does the feature that sounded obvious still make sense when you actually build it? Is the workflow too long? Is it too slow? Will anyone use it twice? Does the AI give a useful answer? What happens when the API fails? What happens when there’s no network? What happens when someone uses the product in a way you never imagined? What happens when your beautiful architecture diagram meets one very ugly edge case?

The prototype starts asking questions. Sometimes uncomfortable ones. That’s its job.

A presentation tends to confirm the story you are trying to tell. A prototype argues with you.

And that is much more useful.

[Pause]

Now, I don’t want to turn this into an argument that ugly products are somehow better. They’re not.

I care deeply about design. Typography. Interaction. Responsiveness. Accessibility. Trust. All those small details that make technology pleasant to use.

A rough prototype should not become an excuse for a careless final product.

Eventually, the beast needs some beauty.

The problem isn’t beauty. The problem is beauty too early.

Because polish can create the illusion of progress. A beautiful mockup can look almost finished even when the hardest questions haven’t been answered yet. A polished presentation can make assumptions feel like decisions.

And once something looks finished, it becomes psychologically harder to change. We start defending it.

That’s one advantage of the ugly prototype. Nobody mistakes it for the final answer.

[Pause]

I’ve made this mistake myself. I’ve spent time making pitch decks for ideas before I had tested whether the underlying product should even exist in the form I was proposing.

At the time, it felt productive. And some of it was productive. Writing a pitch forces you to articulate what you believe. It can expose gaps. It can clarify who you’re trying to help.

But there’s a point where thinking needs to collide with making. Otherwise, the presentation becomes a beautifully organized collection of assumptions.

And when I think back to the way I learned computers as a kid, it was almost the opposite. There wasn’t much presentation. There was just the machine.

Try something. See what happens. Change something. Run it again.

Somewhere between those two worlds is probably the right way to build.

[Pause]

And today, building has become much easier. A single person can create something surprisingly capable using APIs, cloud platforms, open-source software, AI models and coding tools.

Things that once needed a large engineering team can sometimes be demonstrated by one person in days.

That changes the meaning of a pitch.

If it’s increasingly possible to build a small version of your idea, then the obvious question becomes:

Why are we only showing slides?

Of course, not everything can be prototyped cheaply. Hardware, biotech, energy, infrastructure—those are different.

But for a lot of software and AI products, we can move much closer to the real thing before asking other people to believe in it.

And I think that’s incredibly powerful.

[Pause]

This is also changing how I approach the things I’m building now.

Through Elgizmo, I increasingly want to start with experiments rather than declarations.

Make something small. Let somebody touch it. Watch where they hesitate. See what breaks. Find out what I misunderstood. Change it. Then try again.

Some experiments might become products. Some might remain prototypes. Some might simply teach me that the original idea was wrong.

And that’s still progress.

A failed prototype can save months of building the wrong thing. A beautiful presentation of the wrong thing usually can’t.

[Pause]

But I also don’t think the beautiful pitch and the ugly prototype are enemies. Eventually, you need both.

The prototype answers:

Can this work?

The presentation answers:

Why should anyone care?

The prototype creates evidence. The story gives that evidence meaning.

The prototype helps you discover what the product actually is. The presentation helps other people understand where it might go.

Building without communicating can leave a good idea invisible. Communicating without building can leave you selling an idea you haven’t really understood.

So for me, the order matters.

I’m increasingly suspicious of this sequence:

Imagine.

Polish.

Pitch.

Believe.

Build.

I prefer:

Imagine.

Build.

Test.

Learn.

Explain.

Refine.

[Pause]

The second one is messier. There’s more failure. The first version usually looks worse.

Good.

There’s information in that ugliness.

[Pause]

When I think back to that old 386-era PC running DOS, I realize that a lot of what I now believe about building technology was already there. I just didn’t have the language for it.

Type something. See what happens. Make a mistake. Try another command. Change something. Run it again.

The feedback loop was immediate. There was no pitch. There was barely an interface. But there was curiosity. And there was something real to interact with.

Three decades later, the tools are unimaginably more powerful. The screens are more beautiful. The software is more sophisticated. AI can now even help us write the code.

But perhaps one of the most useful habits hasn’t changed very much.

Get the idea out of your head. Make something. Let reality answer back. Then improve it.

[Pause]

So…

The beauty and the beast.

Which one comes first?

For me, the answer has changed.

Build the beast.

Let it be primitive.

Let it expose the awkward parts of the idea.

Let people use it before you have finished explaining why they should love it.

Listen to what it tells you.

Then refine it.

Design it.

Tell the story.

Make it beautiful.

Because the best pitch deck is much easier to create…

when there is something real behind it.