Skip to main content

Deals You Can't Miss

1 Year Subscription

Lessons from Steve Jobs by Guy Kawasaki

Guy Kawasaki shares his top 12 lessons that he learnt from Steve Jobs as below:
  1. "Experts" are clueless
  2. Customers cannot tell you what they want
  3. Action is on the next curve
  4. Big challenges beget the best work
  5. Design counts
  6. Use big graphics and big fonts
  7. Changing your mind is a sign of intelligence
  8. Value is not equal to Price
  9. "A" players hire "A+" players
  10. Real CEOs demo
  11. Real entrepreneurs ship
  12. Marketing = Unique Value



My take on some of the above points:

Experts are clueless. The way I read it is there really isn't a know-all person/entity in any subject area. A reason why I think in the Agile world of software development there is a great importance to collaboration. You are safe and happy to assume that everyone makes mistakes on and off and prepare accordingly.

Customers cannot tell you what they want, at least not always. It helps to work with the customer to understand, validate and most importantly reason requirements. Think about the times in your project that lead to deviation and distress which could have been averted by asking "Why".

Big challenges beget the best work. This statement personally is so inspiring to me. Big challenges are usually intimidating; but that's for the rational man. Life stories of real heroes time and again shows that, they succeed because their perception of "big challenges" were different. To successful men big challenges drives best work in them. Thank you Guy, for bringing out this point.

Design counts. I think these days there is a lot of importance given to the design and user experience. And all credits to Steve Jobs who believed in the importance of design aesthetics.

Use big graphics and big fonts. Enough has been said by many on the importance of this one. I'm not sure though as to how many have really embraced this guiding principle. Classical example is go to a conference, and see how many of the presentations are littered with tons of textual content. Similarly, there are umpteen web-sites even today that has more text dumped into the page only to turn off the visitor.

Changing your mind is a sign of intelligence. When the world thinks that changing ones mind is a sign of stupidity, Steve Jobs thinks the opposite. Nearly all of us in our everyday lives think that changing our mind is a sign of stupidity and not intelligence. We don't want to look like a fool in front of others, and so non-desirous of changing our mind. Interestingly, by not changing our mind quickly, we only postpone the delay of becoming a fool in front of the world. We're wise to look like a fool in front of a small set of people by changing our decisions early on when we see the need. Watch the video embedded above especially for this one, to Guy's example of how Steve Jobs changed his mind in a years' time on the importance of introducing 3rd party application on the iphone platform.

"A" players hire "A+" players. I've had direct experience witnessing this. "A" players hire "A or A+" players. "B" players hire "C" players. And guess what, "C" players hire "D" or "E" players. The organisation quickly sees a downward spiral in quality hires. This sooner than one realizes turns a productive organisation to a political organisation. Don't believe me on this? Your company is most likely in the downward spiral of quality hiring if you see something like below in the hiring advertisements:
  • Mandatory requirements in Certification in any of the following areas: Scrum, Kanban, Java, Database, Testing, etc.
  • Mandatory requirements in the ivy league kind of institutions the candidate is graduated from
  • Mandatory requirements in the area of specialisation in the graduation of the candidature
  • Mandatory requirements in the number of years of experience that the candidate has for the role fitment.

My Popular Posts

Ten Commandments of Egoless Programming

We are nothing but the values we carry. All through my life thus far, I tried to influence people around me with the virtues I value. Thanks to some good reading habits I had inculcated, and the fortune of being in good community of peers and mentors alike, I managed to have read some real good books. This post is about the 10 commands of egoless programming in Weinberg's book. I shall explain the commandments based on my experience here. So very many decades ago, Gerald M. Weinberg authored  The Psychology of Computer Programming . In it, he listed The Ten Commandments of  Egoless Programming , which remains relevant even today for us as not just programmers but as team-members. Weinberg is regarded as a pioneer in taking a people-centric approach to computing, and his work endures as a good guide to intelligence, skill, teamwork, and problem-solving power of a developer. When they appear to inspire and instruct, we find that they can apply to just about every business area, and e

Should I buy refurbished laptop from Amazon?

This post is based on my experience with amazon.in and guess it to be true on all other platforms as well. At least you can check out and verify for these pointers before you make that decision to buy renewed/refurbished laptop on Amazon with your hard earned money. I see this question propping up in several forums and on many different occasions. In the recent past, I had my 5 year old dell laptop that gave up because its motherboard failed. One of the options that I had in my mind was to re-use the HDD and the 16GB DDR4 RAM of that old laptop in the one that I purchase next as secondary.  I had come to a conclusion that it is not worth buying a refurbished/renewed laptop at all. Why? For the following reasons, most of which I see as BIG #RedFlags: You got to remember that Amazon provides a platform for 3rd party sellers to sell their products as well. So in your search for refurbished laptops you wouldn’t want to choose some random 3rd party seller who Amazon doesn’t endorse. You cou

Multi-tenant Architectures

  Multi-tenancy Application Deployment Architecture could be modeled in 4 broad ways: Separate Apps & Separate Databases Shared Apps & Shared Databases Separate Apps & Shared Databases Shared Apps & Separate Databases There is no right or wrong here. It's about choice and consequence that you should consider taking into your business context and constraints. In this post I intend to jot down a some key points to keep in mind for each of these multi-tenant architecture. These are more of quick notes for my quick reference, a cheat-sheet of sorts when I have to make choices. And I guess this can come handy to you too in your wise decision making. Separate Apps & Separate Databases Easiest to implement from development and deployment stand-point. Just automate the deployment infrastructure for every tenant for quick set-up. Most expensive of all the models from infrastructure cost stand-point. Relatively longer deployment t