What other companies should learn from Apple and Google

Those two seem to have got everything perfectly correct.....happy customers, great cash flow, great brands, pretty decent future, etc. So what do they do differently?

• Understand what the customer wants, before the customer understands it
• This is similar to the idea generally conveyed, when people talk about visionary product, market research, being ahead of the market, being ahead of the technology curve, etc
• This comes by taking a long hard look at how people behave and use products.. thats it

• Provide what the customer wants in a no-nonsense manner
• Google.com does not have a help link for a very important reason... it is not needed
• Ensure that using your new product does not require the customer to climb a steep learning curve

• Tell a consistent and simple story for the product
• Remember those Mac Vs PC ads.... Mac is cool, Mac is simple.. that is the story

• Great product does not guarantee great money
• Even great products have to be marketed correctly, priced correctly , sold correctly and phased out correctly

• Deliver on your promises
• Classic example of how not to do it is Windows Vista... delayed launch, stripped away features, and a bad product too
• In the current environment, when you delay a launch, you not only lose market share, buzz, etc but also the WOW effect. Your prized features end up being common when you eventually release.

5 Visible symptoms of bad project management in IT

I think there are many, but, the below 5 are the easiest to recognise:

1. Politically correct team meetings
The whole team claps for the "best employee of the month", everybody agrees to work harder for the customer and to improve the customer satisfaction index.

• No open thread-bare discussion happens on the last escalation/schedule slippage/fire fighting.
• No meeting agenda
• Team goals are not clear
• No action items with responsibility, accountability & deadlines (esp. a strong NO to follow-ups)

2. Huge gap between estimation and execution
Classic example of this would be:

• Why did 3 guys slog it out in the weekend? 
• Because we had some "production issues" and next version release in the week. 
• Wasn't this known when the project started? 
• How many times has this happened before and what did we learn from it? 
• How are we ensuring that this doesn't happen again?

3. "Perennial resource constraint" because wrong people are doing the wrong job


4. Inability to distinguish between good and bad developers

• Number of hours billed & lines of code typed become indicators of capability
• The best and the laggards are treated equally. 
• No chance given to either to improve further. 
• This often leads to the good ones leaving when the first opportunity is available.

5. Religious adherence to processes and templates at the expense of..... well everything else

•  The whole work stops when we have a time-sheet/audit report/"process enhancement document" to fill.
• Good leadership requires a healthy disregard for processes that are bureaucratic & the ones that don't achieve the goals of the organisation in the correct manner.

Are these happening in your team?