As I was sitting down with the family enjoying some Baskin Robbins (Peanut Butter Chocolate rules!) last night I began to wonder why all this cool new “2.0” stuff didn’t originate in the existing companies providing software to enterprises?
Since the new web is a lot about enabling people to share information, it seems likely that some portal vendor would have nailed this years ago…
I used to manage the portal product line for PeopleSoft. We spent a lot of time talking with customers, consultants, and analysts, yet we didn’t go anywhere near the direction of Web 2.0. In fact, no portal vendor did. However, now that tools like blogs, wikis, and social networking are becoming mainstream, they are being incorporated into portals by nearly every vendor in the space, including Oracle.
So what happened? Why didn’t all this social, open goodness show up in these products and by these companies? We’ll, if you understand the way products are driven, it will become clear that they could never have started there. I’ll save you the suspense before I dive deeper; the new web couldn’t happen for business customers first, because they are business customers. Let me explain…
You see, when you are selling software to enterprises you actually have a buyer (this goes for small vendors and large ones). This buyer has certain things they are looking for that are non-negotiable. In the case of portals, you had to have the ability to let admins post content (and not let others post content), users needed homepage personalization, search was a must, and the list goes on. Incidentally, this list of must have features was in most cases the same list that the analysts used to evaluate if your product was “enterprise class”.
The truth is that this list of capabilities was a joint effort between the analysts and customers. Customers call analysts with questions and analysts listen to their issues. Over time, analysts convince customers that the analyst list is important enough to look out for, and analysts learn a thing or two about what real users are facing. What emerges from this process is a super set of features that no product can hope to achieve (not everyone can be a “leader” or what point is the evaluation?).
So here you are. Managing a product that has a set of requirements you can’t meet fully, but nonetheless you have a set of deep problems to solve and a mandate to solve them. If you skip anything on either the customer or the analyst list, you will have sales complaining that you are losing in head-to-head evaluations or you have analysts leaving you in the dreaded lower left of whatever report they care to print. If you need to keep your job, to earn the money, that pays the bills, and keeps the kiddies in ipods, we’ll…the path is clear. Fill in those RFP checkboxes pronto!
You see, it turns out that resources are not infinite. Imagine if you were running a product and saw a really cool new idea come up. One that no customer or analyst had even mentioned or noticed yet. They hadn’t put the pieces together, but you had. You’re a wizard at this, a veritable Nostradamus. So you go to your manager and share this stroke of genius, fully expecting to be showered with praise and end your days being fanned and fed grapes.
Alas, no luck. Mr. manager wonders if you have customers asking for this? Uh, no. Mr. Manager asks if it’s a part of the latest analyst evaluation criteria? Uh, nope. Now, Mr. Manager is no fool. He sees the value in the idea and thinks its supercool, so he asks about resources, got enough to do it? Now you’re excited, cause you knew this was coming. You proudly say, you’ve found a way to do it by just reducing the scope a bit in a few areas. Mr. Manager spins his chair around, stares out the window into skyline, pondering your idea. He wants to do it. He’s dying to innovate and show everyone what he’s got, but if those darn analysts drop us in the next magic square we’ll be in real trouble – people look at those things, ya’know?
It all really comes down to priorities. There is a lot of known value to be fulfilled and a lot of unknown value to be created. With limited resources, people do the known and the unknown loses every time. This of it as an internal product development view of the 9x problem.
Now let’s look at the world of a two guys (or gals) in a garage. Not the funded team, but the two folks just doing something cause they love it. Trying something new because it is new. Because it is different. No boss to answer to. No customers to respond to (yet). No analysts to pander to. These guys don’t think they’ll look bad in the quadrant – they don’t even plan on being in it. In fact, they don’t really care about analysts at all because end users are their customers and as we all know, they don’t buy analyst reports. So they hunker down and code the new world.
Now at some point this all changes. Investors come on board, customers ask for features, and code can’t be refactored every time a new idea comes up. Progress becomes more linear and more directionally obvious. You can’t afterall re-invent yourself every time a new idea comes up. You have to stand for something lest you become confusing. This is why all revolutionary companies become evolutionary. At some point, they just get a bit better at the same thing with each release. How much better is the new Mac OS X going to be than the current version? Not a lot.
In my experience, the most innovative products are new to the orgnization. They also tend to find a new way of doing the same old thing that everyone already understands and it already trying to solve – but they do it in a novel way.
ipod: At some distant point in the past, there was no mp3 player sold by Apple. Everyone had a walkman, so we knew we needed to carry around music, but this one changed the game. Now they just get bigger in storage, smaller in price, and prettier color choice.
iphone: Apple never offered a phone, but everyone knows what a phone is, and why you need one. They just made it dramatically better. Where do they go from here? Ringtones, new colors…evolution my friend.
TiVO: Everyone had a vcr. We all wanted to record shows, but couldn’t get that damn clock to stay set. TiVO is just a joy to use. Now what? HD, two tuners, etc. A steady climb up the feature hill.
Digg: We have read newspapers for news, listened to the radio, and even used pages like MyYahoo and the New York Times. We all need our news, but Digg gave us a better way. What now? I don’t know, but I can guarantee you it will be evolutionary, and it wont be big.
You get the idea. Once you have a product with customers your path is set. It is one of the reasons why the new Microsoft Office 12 release is so gutsy. It comes about as close to revolution as you see in software. I am not sure it will pay off – personally, I am having a hard time with it, but time will tell.
From an Oracle perpective, understanding this history is important because it speaks to why we like our lab approach. Of course, we aren’t the first company to have a lab, but the model is sound. Let people experiment with new, sometimes crazy, ideas. See what works. Take the small wins and plug them in to existing products. Take the really revolutionary stuff and create new products. For any lab, one of the metrics for success should be how much of what you do makes it into real product. If we do our jobs well, I expect to see some of our stuff in customer’s hands in the coming years.
Cheers!
Excellent description of this issue. I’d add a couple more things:
1) Enterprise software is a long train. It’s 2 to 3 years from when work starts on a product until it ships to customers. What did wikis and blogs look like 3 years ago?
2) Enterprise software can’t fail in the marketplace — for a large company like Oracle, if your products are good, they can’t be great because there’s more risk in being great. Apple didn’t release revolutionary OS X until MacOS 9 became terrible, Microsoft didn’t release revolutionary Office 12 until most of there customers were still on Office 2000 (we are). It’s not gutsy for MS, it’s necessary to stay alive. For every 1 good wiki, there are 10 terrible ones, so not having one is better than having a terrible one if it’s not something your customers demanded when you started development.
Excellent description of this issue. I’d add a couple more things:
1) Enterprise software is a long train. It’s 2 to 3 years from when work starts on a product until it ships to customers. What did wikis and blogs look like 3 years ago?
2) Enterprise software can’t fail in the marketplace — for a large company like Oracle, if your products are good, they can’t be great because there’s more risk in being great. Apple didn’t release revolutionary OS X until MacOS 9 became terrible, Microsoft didn’t release revolutionary Office 12 until most of there customers were still on Office 2000 (we are). It’s not gutsy for MS, it’s necessary to stay alive. For every 1 good wiki, there are 10 terrible ones, so not having one is better than having a terrible one if it’s not something your customers demanded when you started development.
Thanks Paul,
Having just left the world of enterprise software to try to ‘code the new world’, your post summed up pretty much everything that led me here.
Gordon 🙂
Thanks Paul,
Having just left the world of enterprise software to try to ‘code the new world’, your post summed up pretty much everything that led me here.
Gordon 🙂