These days innovation is commonly thought of as the job of the small Sillicon Valley startups that have no respect for the status quo. The "Lean Startup" has become the de-facto rule-of-the-land and every enterpreneur has mention "leanness" on their slide decks to be taken seriously. To innovate, you need to be fast, take creative risk and iterate.
Yet real veterans of the craft, like Amazon, prove that innovation has nothing to do with being lean or small or iteration. Amazon has repeatedly entered new markets and out-innovated incumbents, seemingly violating every rule of the "playbook".
The phrase “innovation playbook” sounds like a contradiction to begin with. If innovation were a defined process, wouldn't everyone "innovate"? In practice, it's closer to a decision-making framework, best understood in contrast to alternatives.
Sillicon Valley thought leadership has gotten innovation completely wrong. The “Lean” framework is, at its core, a way to operate under extreme constraints. Amazon, as I will show below based on my personal experience, has a much richer understanding of what it really takes to do it.
The contrast
Sillicon Valley preaches: “build an MVP, ship fast, measure and validate, iterate, stay efficient.” Amazon aims for a Minimum Lovable Product. Where others “measure and validate,” Amazon “dives deep” and “invents and simplifies.” “Customer obsession" often comes at the expense of efficiency. It’s not a deliberate rebuke to Valley dogma, but it does invert the usual iterative paradigm.
1) MLP vs. MVP
A groundbreaking product can't be beta-tested into existence, it has to start with an uncompromising vision. To illustrate the point, MVP is a tactic for sharpening focus in a resource constrained world, while MLP is all about focusing on a great user experience. Two very different decision-making frameworks with serious ramifications.
When the first Kindle was built, Jeff Bezos insisted on cellular connectivity even though the default pattern was syncing through a PC. An MVP-focused team might have cut wireless to ship on time. Wireless was the riskiest part, and much of the team saw it as nonessential to basic viability. Bezos kept it because the “magic moment” depended on it.
2) Process vs Outcome
As anyone who’s worked on a complex project knows, ambiguity shows up no matter how crisp the vision. Amazon equips its people with tools that reward analysis and judgment, rather than mindless execution.
Instead of “ship quick and fail fast,” Amazonians “insist on the highest standards.” Instead of “incorporate user feedback,” Amazon “invents and simplifies.” Instead of “iterating” it “dives deep.”
Intellectual rigor is the point, and it’s enforced through a writing-first process best exemplified by the PRFAQ—a ritual that can feel brutally nitpicky. A good PRFAQ forces clarity of thought. Ideas get shaken around until they land as a cohesive whole. That same writing culture shows up in technical designs, security reviews, and operational readiness. The bar is incredibly high.
3) Speed vs. quality
Quality is non-negotiable, but it doesn’t have to slow execution. 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.
Teams inside Amazon 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 experience worked as intended. Occasionally data surfaces an outlier that deserves a strong response, but the vision doesn’t swing with every experiment. Product-market fit is not "found", it's forged. As Jeff Bezos likes to point out, when the data and the anecdotes disagree, trust the anecdotes.
4) Nimble at scale
A common theme in growing organizations is better communication and code re-use across teams. The Amazon approach is counterintuitive: in the short term, even teams building similar things should often duplicate. Coordination costs and external interfaces drag more than duplication does. It's important to realize that duplication is expensive. Yet, the investment is fully worth it. Costs can be consolidated later, organizational and technical inefficiencies can be fixed, but disappointed customers rarely come back.
What does this all mean?
One striking conclusion is that this kind of innovation is expensive. Many of the tools above spend money to buy clarity, quality, and speed. The question is: can you innovate like this as a resource-constrained startup? A company chasing the next milestone ahead of a funding round rarely has the slack to apply this level of rigor and dedication to the vision.
What is absolutely true about startups—and what justifies the “Lean” framework—is that they operate under extreme information asymmetry. Startups tend to proliferate around technology cycles that enable new markets. New markets come with information gaps that you can only close by putting product in front of users and learning from their behavior. In that model, speed and cost efficiency are essential.
But that’s the key point: lean is optimized for discovery under constraints, not for invention under conviction. Lean assumes the primary risk is building the wrong thing, versus knowing what to build and doing it the right way. Use the right framework for the right job.