Hacker News new | ask | show | jobs
by narush 1509 days ago
I'm reading his book Build right now - it came out last week, so assuming that's why he's appearing all over all the feed). About 2/3rds of the way through currently.

My thoughts: 1. Lots of Steve Jobs talk. There's a whole chapter on the distinction between real assholes, and assholes that just really care about the product quality / customer. The distinction drawn was in motivation - but I wonder if it might just be a winner-writes-the-history situation. 2. Some advice goes heavily against current startup orthodoxy. He rejects fail-fast / figure it out later mentality, and argues for a lengthy product design process (for both atoms and bits!). 3. Lots of good details about how to think about managing people, managing and scaling team, and issues with scaling, etc, taken from his days building Nest.

Both (2) and (3) stand out to me as functions of his specific background. Building a company like Nest is obviously wildly (!) hard, but doing it after building the iPhone is a different game. I don't think his advice about lengthy design processes make a ton of sense for my startup [1], for example.

Generally, I always try and remind myself when I'm reading company-building advice books: this is probably good advice for someone in the same context as Tony Fadell (e.g. someone who is launching a second company after building... the iPhone). For me, it may or may not be relevant.

The good thing about failing fast is that you can use it at a strategy-level, aka fail fast _at_ failing fast, and switch to longer product cycles if you think that might work better. Starting with a long-product cycle doesn't give you much of a chance to try again if your first swing is a miss (which Mito's first attempt was...).

[1] https://trymito.io

4 comments

> My thoughts: 1. Lots of Steve Jobs talk. There's a whole chapter on the distinction between real assholes, and assholes that just really care about the product quality / customer. The distinction drawn was in motivation - but I wonder if it might just be a winner-writes-the-history situation.

He's been doing a lot of history rewriting.

Don't get me wrong: Building and shipping Nest was a great accomplishment. However, he was a famously terrible leader in many regards and drove a number of great employees away.

When Nest acquired Dropcam, a large number of the Dropcam employees left. Tony Fadell then went on to publicly disparage the Dropcam employees as being "not as good as we hoped" saying "unfortunately it wasn't a very experienceded team" ( https://www.businessinsider.com/nest-ceo-tony-fadell-has-dro... ) Predictably, that's a great way to drive away the rest of your knowledgeable employees and make the company toxic for hiring.

Nest didn't go on to revolutionize the space after Tony Fadell arrived with his hard-hitting management styles. Nest cameras haven't really evolved much and the Nest security system was abandoned.

I don't doubt that there are some lessons to be learned in his book, but in practice Tony Fadell hasn't been a great leader in the past decade. I'd take his book with a grain of salt.

> When Nest acquired Dropcam, a large number of the Dropcam employees left. Tony Fadell then went on to publicly disparage the Dropcam employees as being "not as good as we hoped" saying "unfortunately it wasn't a very experienceded team" ( https://www.businessinsider.com/nest-ceo-tony-fadell-has-dro... ) Predictably, that's a great way to drive away the rest of your knowledgeable employees and make the company toxic for hiring.

^^ This.

Aamir Virani, who was the co-founder of Dropcam, has his take on this here: https://aamusings.substack.com/p/who-lives-who-dies-who-tell... (also https://threadreaderapp.com/thread/1522280960984707072.html)

I worked on a team that spent months designing an API, database tables, architecture, etc before implementing a single line of code. It was quite a different experience and we ended up with a far better product than we would have otherwise (faster too!). We also took three weeks working on planned work and then one week to work on “unplanned work” between iterations. “Unplanned” was basically anything goes. Fix a bug that annoyed you, refactor code because you wanted to be able to extend it later, etc.

We had a git repo that /only/ contained design docs and recorded decisions as PRs. Nothing was discussed “offline” so everything was recorded. In meetings we would make the final decision and actually merge the said PRs.

It was so different from working on any other project, and actually more fun.

Seriously give a team at your startup to try that route. I think you’d be surprised after a few months to a year. The quality of the work we output was light years beyond any other team at the company, IMHO.

I'm also reading it. About done.

There's many good gems here and his philosophy hits close to home.

I don't think you need to be of his fame to apply it. Many of these tips are applicable. I find lots of his product & marketing advice to be very useful for new PMs to tech too.

As counter-balance to his book you should talk to some YC hardware founders about their experiences with Tony.
Not good?