Symphonious

Michael Krigsman sticks it to Nick Carr and includes an interesting assertion: that how good software is can be decided by how much revenue it drives:

Nick, please let the market decide whether enterprise software is “good” or not. There’s a simple metric for measuring this: it’s called revenue. Just for kicks, compare the revenue of enterprise companies, such SAP or Oracle, to consumer-oriented firms such as Twitter (click to follow me).

Interesting point, but wrong. The amount of revenue software drives is determined by a number of factors (go ask an economist for the full list), some of the really key ones in the enterprise vs consumer questions include:

• The ability to pay of the target market. It doesn't matter how good the software is, if the customer only has $10 that's all they can pay for it.
• The size of the market it targets. Brilliant software for a niche market will generate less revenue that average software for a big market.
• The amount of and quality of competition. This is the really big point that Michael misses - if you are the only solution to a big problem for people who can afford to pay a lot, you will make money hand over fist almost regardless of how bad the software is.

A much better way of judging how good software is for a mature market, would be how much room there is for a new competitor. If someone can enter the market and solve the problem better than you they'll take away your customers and make money instead. Unfortunately, this is a particularly complex metric because you also have to factor in how rapidly the entire market is growing etc.

This of course leads us to the question, is the enterprise software arena ripe for an upstart with a far more sexy, usable product to come in and take a lot of market share? To a degree yes, but only if they can also solve the existing problems that are well served by enterprise software - support, scalability etc. All the things that the enterprise sales process currently focuses on.

The conversation around enterprise software goes on, with a couple of good responses to my last post that I want to highlight. Firstly, ddoctor (aka Dylan Just who recently started working here at Ephox) in the comments:

I’m thinking of making this one of my career goals - making enterprise software not suck.

Then you're very much in the right place - that's what we do…. He goes on to give some very good advice on designing good UIs, but it misses a key point that I was trying to make in my last post:

Enterprise software doesn't suck because the engineers can't do better, it sucks because the sales process prioritises things in a way that guarantees that it will.

If you want to fix enterprise software, you have to fix the sales process - you have to get real end users involved in making the purchasing decisions and clearly demonstrate the financial benefits of good UIs in terms of user productivity etc. Our product manager, Damien Fitzpatrick1 makes this case quite well:

For example, lets take a team of 50 knowledge workers getting paid about $30 an hour each. As part of their daily tasks they have to add information to a wiki, to a blog and perhaps to a content management system. To do this our hypothetical knowledge workers will be using my favourite web word processing interface; EditLive!. Conservatively I’m going to assume that we can save each one of these people 10 minutes a day (that’s only about 60 clicks a day). Over the course of the year this means a saving of $62,500 just through a few less clicks.

That's the kind of argument you need to get into the sales process for enterprise software because it's simply not on any of the request for tender checklists or feature requirements right now.

Discipline and Punish2 also picked up on my post with an interesting take on things. I particularly agree with:

Bad usability and poor extensibility are thus only symptoms of the underlying disease: a lot of enterprise software is clearly built with centralization as its founding principle. It's designed to appeal to managers and executives but especially a particular kind of manager who wants top-down, command-and-control abilities over her organization.

It's true, most enterprise systems focus on the management of data rather than the creation or the actual use of data, however I suspect there's some confusion between the trends in the consumer space and the trends in the enterprise space:

A natural consequence of this mindset is that Google's done an excellent job building an open, extensible, and inclusive platform that most enterprise vendors can only describe in their marketing literature. If Google does disrupt enterprise software it won't be because of its army of PhDs or any kind of "Google Magic." Rather it will be yet another data point in the long, long history of "big", open technologies disrupting "small", closed technologies.

The catch here is that the trend towards open technologies with a horde of small vendors developing plugins, widgets or whatever they happen to be called, is very much a consumer trend. There's no such trend in the enterprise world, in fact it's quite the opposite - enterprises are more and more inclined to consolidate on one big vendor that supplies the entire stack. This trend is picked up on in all the major reports I've read (Gartner, CMSWatch etc) and is showing through in the number of deals we're seeing with multiple CMSs being replaced by a single instance from one vendor. It's also showing through in the success big vendors are starting to have in the new collaboration and social software market which until very recently has only been filled by small players. Expect those small players to either grow up fast, or be run down by the big players. It's very difficult to do well in the enterprise market if you're a small company and impossible if you're a small company without good partnerships and relationships with the big players.

Enterprise software will become more usable over time, but it won't be because of the threat of Google or openness running it down - it will be because enterprises start to realize the true productivity cost and you'll start seeing the argument Damien put forward more and more in enterprise sales. Better quality software directly helps your bottom line. That's where the changes need to drive from if they're going to succeed - not the desire for developers to make the world a better place.

It may be sad, but money makes the world go round.

1 - who seriously needs to blog more often….↩

2 - I couldn't find an actual person's name anywhere on the site….↩

Technology is a funny thing - we spend so much time and effort trying to make things as simple and efficient as possible for our users that we sometimes lose track of the big picture and wind up making things worse. This is particularly a problem when developing components for other's to intgrate, rather than a product that ships directly to end users. When another developer is between you and the end user a few fairly unique dynamics come into play:

• They have the power and ability to implement their own code. To build on things and improve them.
• They are probably using your product to save time so the less they have to do the better (ie: we have to make things simple and efficient for our developer users and our end users)
• Since they are trying to save time, they will probably learn the minimum amount possible about your product and do the minimum amount of work.

Not everyone integrator has all three of those attributes - certainly we have a lot of clients that know our APIs backwards and build all kinds of cool stuff, bu the majority are pressed for time and wanting to drop your solution in and move on.

The trouble is, sometimes a simple drop in solution simply can't provide the high standard of end user experience that you'd want. In other words, sometimes you get a trade off between making it really simple for the integrator or really good for the end user. As an example, EditLive! introduced "inline editing" recently which allows the page to load really quickly and display the content in a standard DIV. When the user clicks on the DIV the editor loads there and they can begin editing. Click a different DIV and the editor switches over to there. It turns out to be a really good user experience with just one flaw: how does the user know that they should click to edit and where to do so?

The best possible answer in this case is that the integrator takes a bit of time to fit the functionality into their UI and make it intuitive for users. Depending on the environment the editable section is in changes the way you should indicate the editable section. For example, if the entire page is a form specifically designed for editing, the simplest way to make the user see that the DIV is editable is to apply a border that makes it look like a text area. Users expect to be able to click in a text area and start editing so it becomes a natural reaction. Sometimes you want in context editing so the page should look as much like the final output as possible - perhaps just a tooltip on the DIV is the right answer or maybe a specific cursor (probably combined with some user training since this isn't as natural). Whatever UI is in place it should also fit in with the rest of the site and only the integrator can do that.

Unfortunately, I went off and got married and when I came back they'd shoved a hideous pencil into the product to indicate where user's can click. So when the user hovers over an editable section it gets a blue border and a hideous yellow pencil floats over the content. It has to be the single most jarring part of the user experience anywhere in our products - particularly when blue and yellow aren't part of your site's color scheme. Now I can understand the logic behind adding it, the alternative was to have no visual indication to the user at all which is clearly even worse. We wanted to make it easy for integrators to use the functionality and not force them to implement their own way of indicating editability. There's a problem though - now we've taken ownership of that indicator, if it looks ugly it's our fault or if it isn't intuitive enough, it's our fault. There's very little we can do about it though, the only person who can create the right UI for this is the person who's laid out the rest of the editing page and knows the color scheme and knows how to fit the right UI in (including just writing Click To Edit under the DIV). The integrator is busy though, so they see a UI in place, however terrible it must be, and just go with it. We've managed to make the UI "good enough" for the integrator to ignore, but still terrible for end users. If we'd done nothing the integrator would have felt compelled to do it themselves and would most likely have created a much better UI for their users.

On the plus side, we did add an option to turn off our default rendering so that you can do what's best for your own users. Just call editlive.disableObviousEditableSections(); There's a good example over on LiveWorks!

Bottom line: sometimes you need to be cruel to be kind - if you can't do the job right, make sure you do it badly enough that others will feel compelled to act. Avoid the zone of mediocrity.

PS: I really miss Kathy Sierra's blogging.

Alex Iskold has an interesting article "Rethinking 'Crossing The Casm'" which asks how to maintain the interest of early adopters in the face of such an overwhelming number of new products:

According to Wikipedia in 2006, Tom Byers, Faculty Director of Stanford Technology Ventures Program, described "Crossing the Chasm" as "still the bible for entrepreneurial marketing 15 years later." It is certainly a powerful and proven theory, but it does need to be adjusted. The fact that so many things are thrown into the market changes things. Early adopters are enticed by new things much more often today than 15 years ago. Expanding on how to retain the early adopters would be good thing to do in the next edition.

It seems to me that the answer is classic Porter's 5 Forces1 - you need to negate the threat of new entrants, the threat of substitute products and invest in areas that don't have exceptionally intense competitive rivalry. In other words, you need to build a product that is not just compelling now, but also has something that competitors can't easily add.

The first thing to realize is that the early adopters in one niche are usually different people to the early adopters for a different niche. There are some people always on the look out for a new social network that aren't interested in a new chilli source. So you need to pick a niche to invest in that doesn't have such intense rivalry that makes it so difficult to maintain attention.

More importantly though, whatever industry you're investing in, you need to make sure that you have some key advantage over the other players - maybe you happen to know more about music categorization than anyone else (Pandora), maybe you have awesome peer to peer networking technology that massively reduces bandwidth costs (Skype and now Joost), maybe you have a massive farm of servers which makes hard drive space insanely cheap for you (GMail) or maybe you just have key relationships that give you a unique channel to market. There has to be something that you have or that you can acquire that other people will take time to acquire and it has to be a game changer. Then design your product to make the most of that strength. You're creating barriers to entry for your competitors and making it harder for them to take over from you.

To reduce your threat to substitute products you need to provide some benefit to your users that makes it hard for them to switch. The old technique for this was to lock in their data but that's generally frowned upon these days2 so you'll have more success with things like building a community around your product or even just building a brand name for yourself. If no one ever got fired for buying your product, you're in a really nice position.

The most important thing to do though is to keep innovating. Just because you got the attention of the early adopters doesn't mean you should kick back and wait while they carry you across the chasm, you have to keep working hard to keep them happy, to keep providing remarkable aspects to your products that maintains their attention. You have to keep doing what you did to get their attention only different - keep inventing cool stuff, but not the same stuff you've already invented, that's old and boring.

In buzz words, to cross the chasm you have to invent a purple cow to get the early adopters attention then milk that cow while inventing the blue and green cows, followed by the flying horse and a silent rooster to keep giving your sneezers something to sneeze about until everyone catches the cold. Clear?

1 - actually, just basic business but Porter's 5 forces gives me a simple framework to categorize strategies by↩

2 - rightfully so by the way↩

As of next week I'll officially be a product manager instead of an engineer. I'll no longer be spending my days coding and for our core products I won't be allowed to make changes to them. I will however be doing a bunch of prototypes and smaller integrations of our products etc so it's still a hands on role.

Obviously I need to keep my general technical skills really high so that I can quickly whip up prototype integrations and stay on top of new technologies etc. For general technology issues like that I'll probably need to be more on top of things than I am now, and I'll wind up working in a much wider range of languages and with a much wider range of technologies. Definitely interesting stuff ahead. What I'm not sure about though is how in touch I should keep with the Ephox development team and how they are going about developing our products. I clearly need to know what the new features they've added are, but I'm not sure how much of the implementation details I'll need.

There's a couple of factors at play here. Firstly, I need to be focussing on finding out what clients want and be living in the client world more than the technical world so if keeping in touch pulls me away from that it's a problem. At the same time, when you're doing integration work, there's a lot of advantages in knowing some of the implementation details as that knowledge can give you some extra flexibility and power to get what you want done. It also makes it easier to track down problems when things go wrong. I suspect what I need to do is find an efficient way to keep my overview level understanding of the products up to date. Maybe that will happen just from the fact that I'll be in the same office with the engineering team or maybe I'll have to skim commit logs or something. I suspect I will at the very least keep a copy of the source code checked out and reasonable up to date for reference, but hopefully I won't need to actually look at it too often (otherwise we need to improve our docs).