There’s a contradiction sitting at the heart of the screenshot story that nobody points out.
Steve Jobs refused to let David Pogue see Apple’s ugly, half-finished internal screenshot tool. He burned a summer of engineering time to keep the unfinished version hidden.
This is, almost word for word, the opposite of what The Lean Startup tells you to do.
Eric Ries’s whole point is that you ship the embarrassing version. You release the minimum viable product. You let real users encounter your half-built thing because their feedback is the only signal that matters. The cost of polishing in private is far greater than the cost of looking unfinished in public.
So who’s right?
Both of them. And the reason most enterprise AI programs are stuck right now is that they don’t know which mode they’re in.
Two different MVPs, doing two different jobs
The MVP Eric Ries wrote about was a learning device.
You don’t know if anyone wants the thing. You don’t know what they’ll pay for it. You don’t know which features matter. You ship the embarrassing version to learn. Every customer interaction is a data point. The embarrassment is the price of the data.
The screenshot tool Jobs refused to show Pogue wasn’t an MVP in that sense. Apple already knew what the iPhone was. They already knew customers wanted it. They already knew what mattered. The internal tool wasn’t there to learn anything — it was there to do an internal job.
These are two completely different artifacts that we’ve started calling by the same name.
When you’re trying to learn whether something should exist at all, you ship the embarrassing version.
When you already know it should exist and you’re just executing, you protect the idea fiercely until the visible version matches what it is.
Most enterprise AI programs are confusing the two.
Where AI programs get this wrong
I see it almost every week. A team is told to “build an MVP” of an AI assistant for, say, customer service.
They build a version that works some of the time. It handles roughly 60% of queries acceptably, 30% poorly, and 10% with answers that are confidently wrong. The leadership team says: “It’s an MVP — let’s launch it to a pilot group of customers and learn.”
Two things are wrong with that framing.
First — they’re not actually learning anything. They already know customers want faster service. They already know AI can help. They already know the technology will keep improving. There’s no real hypothesis being tested. They’re just shipping something embarrassing for the sake of shipping it.
Second — they’re contaminating the idea. The 30% poor responses and the 10% confidently-wrong ones are now setting customer expectations. Those customers will tell other customers. The brand will absorb the impression. Six months later when the system is genuinely good, it’ll still be carrying the reputation of the bad version.
This is the failure mode Jobs was guarding against.
It’s also a failure mode Eric Ries would recognize — because the MVP wasn’t actually generating learning. It was just generating risk.
The two-question test
Before you ship any AI capability, ask two questions.
1. What hypothesis am I testing?
If you can name it specifically — “we believe legal teams will pay for contract redlining if accuracy is above 95%” — you’re in Ries-mode. Ship the embarrassing version, get the data, decide.
If you can’t name a hypothesis, or if the hypothesis is something you already know the answer to (“we believe customers want faster service”), you’re not testing anything. You’re just shipping. Stop.
2. Who sees the embarrassing version?
Ries-mode works when the embarrassing version is seen by a small, contained, expectations-managed audience. Early adopters who know they’re early. Internal users who signed up to test. Customers who explicitly opted into a beta.
Jobs-mode applies the moment the audience is broad, brand-defining, or expectation-setting. The general public. Your enterprise customers. Your board. Your sales team’s prospects.
Most enterprise AI programs ship in Ries-mode to a Jobs-mode audience. That’s the trap.
What good MVP discipline looks like in AI
A well-run AI program runs both modes simultaneously, on different surfaces.
Internally, it’s aggressively Ries. Half-built tools. Embarrassing prototypes. Constant iteration. Nobody outside the team sees this. The point is learning.
Externally, it’s aggressively Jobs. Nothing customer-facing ships until the visible version matches the idea. The polish bar is high. The first impression is treated as a one-shot resource.
The bridge between the two is the work. The internal Ries-mode generates the learning that makes the external Jobs-mode possible. You earn the right to look polished in public by being relentlessly embarrassing in private.
Most organizations get this exactly backwards. They run Jobs-mode internally — endless polish on internal prototypes nobody will see — and Ries-mode externally, shipping rough versions to customers under the banner of “let’s iterate.”
That’s how you waste a year and damage the idea at the same time.
The closing thought
The Pogue screenshot story and The Lean Startup are both right.
Show the embarrassing version to the people whose feedback you actually need.
Hide it from everyone else.
The discipline isn’t choosing between the two. The discipline is knowing, every time you ship something, which mode you’re in and which audience you’re in front of.
That’s not an MVP question. That’s a leadership question.
And it’s the question most AI programs aren’t asking.
