Shipping Greatness: Practical lessons on building and launching outstanding software, learned on the job at Google and Amazon

the best way to discover edge cases is by “taking a slow walk through the functionality.” The slow walk is a great way to approach the problem because you really need to take time to reflect creatively on ways that users will break your software or use it in a manner other than you intended. As you take this slow walk, write down all the potential

To remove some of the arbitrariness from this stage of the project, I check to ensure that the team feels proud. Your team must be proud of the software they build, and the bugs you have in the product shouldn’t embarrass you.

Ries defines the minimum viable product as the smallest fraction of your product that a sufficient number of customers will use in order to validate an assumption. You may only need a handful of customers to know you’re on the right track, and you may only need to validate one assumption at a time. Regardless of how big your minimum viable product

The design problems I ask are all very interesting to me; great candidates get excited about the problem with me and can explore the problem space.

It’s important not to say, “Make the login button less prominent.” We also didn’t say, “Move the ‘What’s your favorite team?’ promo up to the top.” Rather, we empowered the design team to make a collection of optimizations based on our prioritized business objectives, which we clearly stated.

I honestly believe Eric Schmidt both espoused and lived to this principle. I heard him say, “Thank you for ignoring me; that’s why we hired you.” Sadly, he said this about someone else — I didn’t have the guts to ignore Eric because he was really much, much smarter than I.

a good rule of thumb is to optimize for usability and solve the abuse problems when they become real. I’ve rarely seen this approach fail, and I have seen products stumble by trying to solve abuse problems that might never occur.

embody. Similar to my previous suggestions, Maeda advocates “simplifying” features so they do only what they absolutely must. For advanced features that are used occasionally or by users of secondary importance, “hide” those more complicated features. One way to hide complexity is to put power-user features into an “advanced options” dialog or coll

Risk is the enemy of shipping.

THE USER EXPERIENCE IS not just what your product looks like, it’s how it works, too.