Panos Panay on Failure, Surface RT, and Life After the Smartphone
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 focus put his current job 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 advice was not to drop the idea after that kind of miss. Panay said founders should keep their vision after failure and adapt rather than abandon it. Change 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 work 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 in the same way software does. Inventory piles up. Factory tooling locks in, component orders lock in, and a miss shows up as a write-down rather than a rollback.
The broader context here is why device makers talk about failure differently than software makers. A cloud service can ship behind a flag, meaning only some users get the new code, then measure results and revert if needed. A tablet, a speaker, or an e-reader carries choices about chips, power budgets, antenna performance, heat limits, and supply chain commitments that cannot be undone once devices 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. Keeping the vision does not mean keeping the same bill of materials, or list of parts, or the same interaction model, or way users control the device. It means holding the user problem steady while allowing the technical design to change. That is familiar work for anyone who has carried a platform through a failed form factor and into one that works. The discipline is deciding what was wrong, the thesis or the execution, without the benefit of clean telemetry, or precise usage data.
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, or microphones that listen across a room, on-device inference, or AI processing done on the gadget itself, cloud models, and tight cost constraints. The integration surface is wide. Founders in that space will ship compromises on latency, or delay, 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.
