

Enterprise Software Doesn't Have to Suck - jsatok
http://blog.rypple.com/2010/09/3-reasons-enterprise-software-doesnt-have-to-suck/

======
Locke1689
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 f __k
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.

~~~
jaygoldman
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.

Keep the comments coming!

Thanks,

Jay

~~~
Locke1689
Thanks Jay, I love to have open dialog.

 _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.

------
Poiesis
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.

~~~
jnoller
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?

------
jnoller
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.

~~~
ido
That's the point tho, isn't it?

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.

~~~
jman73
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>

------
Flemlord
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.

~~~
jman73
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.

~~~
omh
"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.

~~~
jman73
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.

~~~
ido

        if the primary goal is user experience.
    

That's a pretty big if :)

~~~
jman73
totally agree... but that's the if the post rides on!

------
petrilli
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.

------
jaygoldman
Dan (jman73) has posted a follow-up: 4 Steps to Becoming a Killer. Comments
and discussion welcome! Post: <http://rypp.ly/9XKdvm> HN thread:
<http://news.ycombinator.com/item?id=1744613>

