Enterprise Software Doesn't Have to Suck
blog.rypple.com
blog.rypple.com
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.
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.
(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.
Keep the comments coming!
Thanks,
Jay
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.
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 going to hurt; but man - can you imagine if it succeeded?
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.
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.
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.
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.
if the primary goal is user experience.
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.