Silicon Alley Insider ran an interesting poll this week How do you feel about Facebook? Of the 900 who took the pole, most were not too happy with Facebook to which Nicholas Carlson  added his own anecdotal data.

This jibes with our own anecdotal data. Friends and colleagues tell us they use Facebook all the time, but they don’t actually “like” it. They feel stuck with it.

Such comments reminded me of when AOL increased the monthly fees for internet access just after the purchase of Time Warner in 2000. It went from $19.99 to like $20.99 and I remember reading that it was not a sign of trouble at AOL but more a move of strength. We all know what happened after that. Though in 2000 AOL looked to be on top of the world because they had such a lock on their customers, heck they could even increase the price and see no ill effects. But underneath it all customers had begun to hate AOL. They didn’t see the price increase as a fair exchange but more a sign that they needed to do everything they could to migrate away from AOL. As the following years would show, people hated AOL and felt trapped.

Now that doesn’t sound all that different from the comments Nicholas Carlson is hearing about Facebook. I doubt Facebook will fall as far as AOL did, but companies should be weary when their customers feel trapped. All those supposed lock-ins can fade quickly. AOL had a long list of lock-ins – email, chat, credit card data. It made switching harder but it didn’t stop what eventually became a mass exodus. How many of Facebook’s supposed lock-ins will fade?

In the post, What Happened to Yahoo, legendary programmer Paul Graham dives into how Yahoo! fell from grace. I was at Yahoo! around the same time as Paul, we even worked on a few projects together and I agree with much of his post. The availability of easy money allowed Yahoo! to truck along without ever actually defining what it was.

But what Yahoo really needed to be was a technology company, and by trying to be something else, they ended up being something that was neither here nor there. That’s why Yahoo as a company has never had a sharply defined identity.

Yahoo! still doesn’t understand what it is. It’s almost comical how to this day they still try to hedge around actually defining themselves. Even a 100 million dollar ad campaign can do little for them.

Lack of identity meant it was impossible to be strategic

Paul explains Yahoo!’s other mistake was to not take programming seriously. Unlike Google where they are manic about hiring the best Engineers, Yahoo! was content to take on mediocre Engineering talent. As Paul says, the Product Managers were in charge. I of course was one of those annoying Product Managers and while I never felt we had mediocre Engineers I certainly felt the lack of direction all stemming from Yahoo!’s inability to define itself.

I liken corporate strategy to football. Say it’s been a tough game, we’ve played our hearts out and we’re still tied going into halftime.  In the locker room we’re all looking to our coach for direction, for a plan that can ensure us the win. But all too often the senior executives lack a clear actionable plan, they may think they have one (ala Yahoo!) but all it amounts to is, “Play harder and we’ll win”. It can be heart felt and emotional but if there isn’t a strategy it falls flat the minute we retake the field. What we need to hear in the locker room is a plan, “we’re a running team so we’re going to run the ball down their throats until they leave our star receiver open, then we’ll get it to him in the in zone”.

As Paul pointed out, all Yahoo! knew about itself is that it was winning in 1999. When things turned ugly they’re locker room speech came up hollow – I know, I was there. Paul believes Yahoo! might have still saved itself if it had been a home for the best and brightest Engineers. Another way to look at it is to expect the players to come up with their own strategy, for the star player to take it on their shoulders to pull out the win. I don’t disagree but I doubt they could have pulled out the win. Google is a good example, their Engineers have done some great things but they’ve also come up short a few times as of late – Google Wave and the privacy fiasco around Buzz come to mind.Google has a mission – to organize the world’s information and make it universally accessible and useful. The closer their Engineers execute toward that the better, the farther they stray the more questionable the results. Anyone remember Google Lively?

In the end it’s a team sport. If you don’t have a strategy you can hope some star players manage to pull out a hat trick. I for one would rather have the coach come into the locker room at halftime with a plan.

The other day I was meeting with a company and was a bit shocked when they openly admitted to not writing specs. And before you ask, yes the company is rather successful and been in business for years – all without formalized a spec process. As a product manager I find it difficult to image, I’ve seen companies with an overtly detailed process before but none? Then I began to question, is it better to have no spec process or an overly detailed one?

I once worked for a very successful Internet company that also worked under the Waterfall model. This was my only experience working outside of an Agile shop and I can safely say that if you aren’t doing mission critical stuff, like building a plane, you should never use the Waterfall model. Any-who this company also had a very detailed spec process to go along with it. The Product Manager outlined the product, the Project Manager would translate that into a spec, it would then go to Engineering, etc. What you got at the end of it all was an engineering team that basically did paint by numbers. They only did what was asked and nothing more. They were more worried about covering their ass than pointing out faults with a spec. Of course saying that implies that they knew what we were building, I think most saw the numbers and simply painted. This is certainly not the Engineering team you want when building innovative products.

Compare that with an Agile company that works off of lite specs. Lite because they’re always changing and also because most people don’t read them fully (any part that is unread is wasted effort as Eric Ries points out and startups are about eliminating waste). So the spec is incomplete by its nature so everyone has to add to it in their own way. But how do you know what to add or not to add? That comes down to communication within the company, having a clear vision. Where as with the example above the responsibility was pushed to an all encompassing spec, with a lite Agile process the responsibility is shared with the spec and the communication within the company. With a company that doesn’t use a spec the responsibility must be all on the communication.

Of course adding a lite spec process to where there was none before can be helpful,  likely facilitating more communication. However changing the spec process at a company with a detailed process doesn’t yield much gain. If it’s been years you might have departments in serious atrophy as the one I had to work with. So I’d say no spec process is better than an overly detailed one.