I think some people who write about enterprise software either haven't worked on really big enterprise software or don't realize how it came to be bad. The problem isn't that suddenly your product started sucking -- mostly it's that inefficiencies or poor design decisions made 3 years ago suddenly start biting you in the ass.
In other words, software ages like people -- year to year there's not a huge difference, but 10 years later you look back and say "what the fk happened?!"
Now, some software just clearly wasn't designed with usability in mind. Much more, however, was probably designed with a limited goal that was forced to quickly adapt to more complex situations. Startups and web companies have it relatively easy -- you can simply change your code on your server and suddenly everyone's up to date. Other companies have to deal with backwards compatibility and standards and shipping and all the pains of large projects in general. The people who come in saying "Well the people in charge are just idiots. If I were in charge we'd have SCRUM and new languages and modern development practices and everything would fix itself immediately!" really don't know what they're talking about.
I think that the article has some good points (not getting involved enough with the actual users is a big one), but they're really too young to say "we have found the Holy Grail!" Removing features, especially, strikes me as something which sounds like a good idea but can really hurt you as a business. When your customer is a 300 person mid-size corporation you can easily say, "well, we had to make some changes here and that feature had to go." When your customer is a retail giant employing 300,000 people all over the country, you think very, very carefully about removing that feature.
Thanks for the comment Locke1689. You make some excellent points.
(In the interest of full disclosure, I'm the Head of Marketing for Rypple.)
Rypple itself may be young, but the guys who co-founded it are very experienced in the world of traditional, capital-E, Enterprise software. They were the head of sales and marketing at Workbrain, which they grew to $100m in revenue providing serious Enterprise solutions to the biggest companies in the world. They intimately understand how this world works and so they are well qualified to say that our approach is a much better one.
You're absolutely right about it being easier when you're SaaS. We're confident that this is not a fad, for the very reasons you mention. Salesforce.com is hardly a startup anymore and is a significant player in the Enterprise space with an entirely SaaS-based solution. The next version of Office is rumored to be a Cloud solution. Even consumer-focused products like the AppleTV have gone from client-side storage to the Cloud.
The strongest reaction to this post is around the idea of removing features, with lots of people saying "You can't do that!" and "Your customers will revolt!". We get that. It's the natural reaction after years of building software in the traditional way. Here's the thing though: our customers celebrate when we take features out. We get emails from them thanking us for keeping the app simple and jettisoning the cruft. We sometimes pull something out that we do get a strong reaction to, and then we work closely with the users who felt strongly to make the feature awesome and put it back in.
Rypple itself may be young, but the guys who co-founded it are very experienced in the world of traditional, capital-E, Enterprise software. They were the head of sales and marketing at Workbrain, which they grew to $100m in revenue providing serious Enterprise solutions to the biggest companies in the world. They intimately understand how this world works and so they are well qualified to say that our approach is a much better one.
I didn't mean to insinuate that the companies are somehow unqualified to make those judgements. It's usually the armchair experts that make these kind of comments. When I referred to the young age of the company I was really referring to the company model itself instead of the people inside. I wish you the best of luck but my point was mainly that knowledge and acumen are great, but when it gets down to it the proof is in the pudding. I hope you guys will still be here in 10-15 years and it will be great if you are and the model does scale into the long term, but I think it's premature to say it's definitely succeeded before the eggs have hatched.
The strongest reaction to this post is around the idea of removing features, with lots of people saying "You can't do that!" and "Your customers will revolt!". We get that. It's the natural reaction after years of building software in the traditional way. Here's the thing though: our customers celebrate when we take features out. We get emails from them thanking us for keeping the app simple and jettisoning the cruft. We sometimes pull something out that we do get a strong reaction to, and then we work closely with the users who felt strongly to make the feature awesome and put it back in.
I think this really depends. Mainly it depends on what kinds of features you're removing. One thing I'd really caution against is changing your API every couple months. That is the kind of thing that can drive your company into a hole they can't crawl out of.
I agree. Server based software makes it easier to fix things in a continuous manner - ensuring that software doesn't suck over a period of time.
Also agree with the "getting involved with real users" point. One of the ways to achieve this is to build and market for smaller firms - these tend to operate less bureaucratically, and also have a good chance that the buyer and user is same. This also allows for the software to be built in a more organic manner - the most crucial aspects first and then features that are incrementally useful.
The article gets it right in defining the classic problem: buyers are not generally users. And when they are, they're not qualified to make informed decisions about design.
Where the article gets it wrong is the solution. At least in my limited experience, enterprises are slow to change things if they "work", however painful. They also do not always entertain SAAS for a variety of reasons, two of which are probably inertia and a different sales process than they're used to.
Couple that with IT departments that block "productivity" or "personal storage" sites and you can see where alternatives can't even work their way in slowly.
I think the solution described is the best chance we have of getting better enterprise apps, but it's by no means going to be easy. It does seem that over time things will get better. It's already been far, far too long. I hate using broken tools.
It's not easy, but in my estimation - it has to be done, or we're going to be stuck with the crap we've had for years and it will just keep going and going.
It's going to hurt; but man - can you imagine if it succeeded?
I completely agree - so much midtier and enterprise software is a complete mess because of these things. People have to be willing to listen to customers, but say no when it serves the greater good. You must kill ruthlessly - but you must have the metrics to know what to kill, and you have to examine those metrics as part of the process.
Feature bloat is especially painful, for the longest time "enterprise" has been synonymous with "a ton of mostly unused features and confusing UI". Don't make your product into something which resembles a pile of tools in the crap-drawer in your kitchen. Say no - kill things, make it clean, organized and usable.
Your users will thank you. On the other hand, the guys who make more money than you every year "consulting" on how to "properly use and setup" you bloated confusing product will hate you.
It isn't about making good software, it's about making good money. Since the people who buy the software are not the people who use it, what you need to optimize isn't the software's ease of use, but ease of selling to the people on top.
If the users are happy or not is comparatively inconsequential, after all - they are not the ones making the decision.
Well, the point I guess is that the people who use it are more and more the people who make the decision, b/c the channels of distribution have changed, even for biz software. http://web.hbr.org/email/archive/dailystat.php?date=092110
If you're not optimizing for your users - the poor schmucks who are forced to use you day after day, you're abusing them and making their lives hell.
If you're in the business of abusing your users because they're not the people writing the checks, I hope you fail (even though I know you won't). Making money and caring about your users are not incompatible goals.
Had me right until the end: "Solution: Kill features. Often."
In most enterprise environments, that's not realistic. Unless you've really screwed your design process, features are in there because clients need them. Even refactoring a feature into something that makes it a better product for 99% of your users will greatly annoy the one user who needs the feature and is used to having it implemented in a certain way.
It's much better to negotiate with the users on the front-end for a better product or avoid overly-demanding users that will hurt your product. Because once the feature is in there, it's there to stay.
Hey - I think we disagree on the basic premise. I don't think most features are there because the clients "need them". The point of the post is that many are there because they think they need them, and thus, through a sales process they were "required". Of course, one size does NOT fit all... many specialized apps do require more features... but in general, you can kill features, especially if based on data that shows nobody really uses them.
"Killing" a feature before it's rolled out would be great, but it's hard to start talking a potential customer out of a feature request if there's a chance it will put them off your product. Doubly so if it's a salesperson talking to them who doesn't have detailed technical experience.
And killing features after is always a problem. If you've got lots of users then some of them are probably using every single feature, no matter how dumb it is.
Totally agree... but again, point of the post was that when you are selling bottom up, and your "customer" is the end user, you are less locked by a singular buyer who think that something is required. No doubt that this approach can cause some friction, and it is way easier before release... but it can be done...if the primary goal is user experience.
The problem, as I've seen in a few big organizations, is that everyone thinks they need an "all singing, all dancing" piece of software (like SAP or Siebel, for example), which has 18-quadrillion knobs to adjust. The problem is, nobody has the slightest clue how to adjust those knobs to fit your business, but the sales person convinces the customer that somehow, magically, it will be a perfect fit.
What ends up happening? The customer has to change their business to match the "default" behavior of the infinitely flexible software, because nobody can overcome it's intrinsic infinite complexity.
In other words, software ages like people -- year to year there's not a huge difference, but 10 years later you look back and say "what the fk happened?!"
Now, some software just clearly wasn't designed with usability in mind. Much more, however, was probably designed with a limited goal that was forced to quickly adapt to more complex situations. Startups and web companies have it relatively easy -- you can simply change your code on your server and suddenly everyone's up to date. Other companies have to deal with backwards compatibility and standards and shipping and all the pains of large projects in general. The people who come in saying "Well the people in charge are just idiots. If I were in charge we'd have SCRUM and new languages and modern development practices and everything would fix itself immediately!" really don't know what they're talking about.
I think that the article has some good points (not getting involved enough with the actual users is a big one), but they're really too young to say "we have found the Holy Grail!" Removing features, especially, strikes me as something which sounds like a good idea but can really hurt you as a business. When your customer is a 300 person mid-size corporation you can easily say, "well, we had to make some changes here and that feature had to go." When your customer is a retail giant employing 300,000 people all over the country, you think very, very carefully about removing that feature.