Steve Jobs Rigged The First iPhone Demo By Faking Full Signal Strength And Secretly Swapping Devices Because Of Fragile Prototypes And Bug-Riddled Software
The late Steve Jobs, renowned for his innovative vision at Apple Inc., faced a unique challenge in 2007 with the first iPhone presentation. The device was a groundbreaking concept, but it wasn't ready for a public debut. Jobs, known for pushing boundaries, orchestrated a presentation that was more o...
• Steve Jobs faked full signal strength and swapped devices during the first iPhone demo due to fragile prototypes and bug-riddled software.
• Engineers got drunk during the presentation to calm their nerves.
• Despite the challenges, Jobs successfully completed the 90-minute demonstration without any noticeable issues.
Well that’s where I’ve been going wrong in my career. I have worked for 2 startup companies, who faked product demos, in software.
I’d come from corporate background, where it was all fairly standard off the shelf software we sold and implemented. Not above the odd white lie, but the products could do what they claimed.
In the startups, the first occasion I did a presentation on a laptop. I was new to the company, had a couple of days training. The demo went great, the client loved it. Since I would also be managing the systems integration, I asked the devs how exactly x talked to y - and they said it didn’t yet, I’d just shown a simulation. Looking back I was naive, but I quit at the end of the week . I had no idea it was not uncommon.
I think people outside tech have no idea how common place this is.
My company was hired to consult on a startup in the financial industry, a product for banks, that was having bad tech debt and dirty code problems.
We were on site for a couple of months, pairing with the engineers and interviewing management.
One of the rules we recommended they implement was that the CEO (who was the sales staff) was not allowed to sell features that weren’t working yet.
The eliminated ultra tight surprise deadlines on new features, and enabled the engineering team to take it easy and produce better code at a deliberate pace.
Another rule was that there was one release per week, and no more.