Cezar Babin’s Blog

OpenAI launched an Apps SDK on Monday (see here). This effectively means that developers can now build apps inside ChatGPT:

Amazon is an outlier in how it enters markets, ships products, and builds flywheels. You might assume it embodies “lean startup” dogma. After two years inside, I can say it doesn’t. The advantage comes from doing almost the opposite of what the Silicon Valley echo chamber preaches.

There is no “build an MVP, ship fast, measure and validate, iterate, stay efficient.” We aim for an MLP—a Minimum Lovable Product. Where others “measure and validate,” Amazon “dives deep” and “invents and simplifies.” Where others chase efficiency, Amazon is “customer obsessed.” I can’t speak to whether this was designed in opposition to SV, but I can tell you the Amazon way starts with an uncompromising vision and then figures out how to execute it.

MLP vs. MVP

We don’t try to prove an idea is viable; we try to delight the customer. You can’t beta-test your way into a product—you need vision. MVP thinking strips anything that threatens viability. MLP thinking asks what we can add to make the experience unmistakably great.

When the first Kindle was built, Jeff Bezos insisted on cellular connectivity even though the accepted pattern was syncing via a PC. An MVP would have cut wireless. Wireless was the riskiest piece and could have sunk the program. It stayed anyway, because the vision required it.

This is the opposite of hypothesis-testing your way to a product. Customers shouldn’t carry the burden of our viability experiments. Our job is to innovate on their behalf, not hand them half-baked ideas.

“Measure and validate” vs. “dive deep” and “invent and simplify”

Every product starts with a crisp vision, ruthless execution, and good judgment. Instead of “ship quick and fail fast,” we “insist on the highest standards.” Instead of “incorporate user feedback,” we “invent and simplify.” Instead of “iterate,” we “dive deep.” We focus on inputs we control to solve the customer problem, not just outputs.

The PRFAQ is famous; what’s less known is how many brutal revisions it goes through. You sharpen clarity by rewriting and debating until the story is airtight. That written culture extends to technical designs, security reviews, and operational readiness. The bar is high on purpose.

Speed vs. quality

Quality is non-negotiable, but it doesn’t have to slow you down. The one-way door vs. two-way door framework keeps decisions fast when they’re reversible and careful when they aren’t. “Disagree and commit” turns debate into forward motion.

We still run segments, VOC, user studies, alphas/betas, and A/B tests. They’re tools for refinement, not for steering the product away from its vision. A/B tests pick the button that converts better; CSAT confirms the app worked as intended. Occasionally data exposes an outlier that deserves a strong response, but the vision doesn’t swing with every experiment. We don’t “find” product-market fit; we forge it.

Nimble at scale

A common argument for “lean” is that shared components and tight efficiency keep you fast. I thought so too. When our team grew from 10 to 100, I pushed hard on shared infrastructure and libraries to boost reuse across sub-teams. It slowed us down. Growth got gated by the slowest dependency.

The Amazon answer is counterintuitive: in the short term, even teams building similar things should often duplicate. Coordination costs and external interfaces drag more than duplication does. At Amazon’s scale, any service might serve millions, and the engineering bar is high; duplication feels expensive. What actually kills products is being late and getting bogged down. Duplication is an investment in speed you can consolidate later. You can fix organizational and technical inefficiencies; you can’t buy back time with customers you failed to delight.

Startup lessons

Should startups copy this? Sometimes. It’s easier to run “fat” when your survival doesn’t hinge on a single bet. Many startups throw ideas into the world to see what sticks. That can be necessary, but speed and leanness are not substitutes for vision and execution. Limited resources don’t force you to abandon a point of view.

There was a phase in the digitization cycle where moving offline workflows to the browser was enough. Adoption risk was low; the risk was speed and distribution. In that world, iterating quickly made sense. When you’re actually inventing, vision matters more than velocity theater.

Building products

Culture moves like fashion, and Silicon Valley isn’t immune. You won’t win an argument with a VC about the “right” way to build; the dominant culture reinforces itself. What does endure is craft, vision, and the timeless rules of customer choice. If you’re looking for an alternative to lean orthodoxy, here’s a live data point: Amazon commits to a strong vision, sets a high bar, duplicates when it buys speed, and forges product-market fit. It’s another way to build—and it works.