Amazon's Panay Tells Founders to Fail, Learn, and Hold the Vision
Panos Panay, Amazon SVP of Devices, Alexa, and Leo, told founders they have to be willing to fail and learn from failure when building products. He spoke onstage at TechCrunch Disrupt in San Francisco, an event held Oct. 13-15 in San Francisco. TechCrunch
The session was billed in advance as a discussion of what comes after the smartphone, with Panay making the case for Amazon's direction. TechCrunch That framing put his current remit at the center. He leads Amazon's devices, Alexa, and Leo organizations.
Panay spoke from more than 19 years at Microsoft before joining Amazon. He pointed to the launch of Surface RT, Microsoft's first tablet computer, as a significant failure during his tenure there. The product resulted in a nearly $1 billion write-down.
His prescription was not to retreat from an idea after that kind of miss. Panay said founders should retain their vision after failure and adapt rather than abandon it. Adapt the implementation, keep the intent.
The comments land in the middle of a longer transition for Panay. Amazon was set to hire Microsoft's departing product chief in September 2023. Reuters Since then his portfolio has centered on connected hardware and assistants. In February 2025 he discussed rebooting Alexa with AI, and in a Sept. 30, 2025 interview he discussed Amazon's hardware overhaul involving Echo and Kindle devices. Bloomberg
Hardware does not forgive. Inventory is unforgiving. Tooling locks, component commits lock, and a miss shows up as a write-down rather than a rollback.
The broader context here is why device builders talk about failure differently than software builders. A cloud service can ship behind a flag, measure, and revert. A tablet, a speaker, or an e-reader carries silicon choices, power budgets, antenna performance, thermal envelopes, and supply chain commitments that cannot be reverted once they ship in volume. Learning has to happen earlier, in EVT and user testing, and it still sometimes happens in public.
In my view, Panay's distinction between vision and implementation is the useful part for technical founders. Retaining vision does not mean retaining the bill of materials or the interaction model. It means holding the user problem constant while allowing the architecture to change. That is familiar work for anyone who has carried a platform through a failed form factor and into a workable one. The discipline is deciding what was wrong, the thesis or the execution, without the benefit of clean telemetry.
Looking at what this means for teams working beyond the phone, the tolerance for public iteration may matter more than any single device. Ambient systems combine far-field audio, on-device inference, cloud models, and tight cost constraints. The integration surface is wide. Founders in that space will ship compromises on latency, accuracy, or battery, learn which compromise users reject, and revise. Panay's argument is that the revision is the job, not a deviation from it.
