I have a friend whose company recently got funded.  Their idea: to introduce a new payments system.  If you read their response to the question “What makes you different from Paypal and Google Checkout?”, their answer was simple: “It doesn’t suck.”  I was very envious of the big balls it takes to make that statement, but then realized that the statement is representative of a giant paradigm shift – one that I need the balls to talk about.

Here’s the OH SNAP zinger:

“In Higher Education today, the RFP process kills good products, and committee driven purchasing kills great design.”

We get questions all the time that sound something like this: “Yeah, but what does it DO!”  Somehow, the idea that we have software that’s simple, usable, and sticky, doesn’t yet register as purchasing priorities in quite a bit of the Higher Ed crowd.  But, these should be the top priorities.

The RFP and procurement process for software has traditionally been about Features.  What features does your software have?  We’re putting out an RFP for software with all of these Features.  And if two software packages have the same Features, well you go with the one with the lower price, right?  This process, in theory, creates a competitive environment in which the school saves money and yet satisfies their software needs.

But this process kills the potential for great products and also kills the possibility of creating great companies, and instead the RFP/Feature-based purchasing creates incentives for feature rich software that, while it may meet a laundry list of requirements, is either entirely unusable or aggravates almost everyone that uses it.

There are often a million little design decisions that total up into a great user experience.  These can’t be listed out in line-item form.  If they were, there would be a thousand things like this: “Appropriate use of white space.  Consistently fast load times using memcache.  Social Proof accompanied with calls to action.”    There are also a million little efforts and characteristics that go into providing good service, many of which just go deep into the SOUL of the company that creates the software.  Equally, there’s no checklist for this.  It would sound like “Always friendly when I get them on the phone.  The person helping me has direct access to engineering and product development.”

Feature driven software may suffice in the previous paradigms associated with administrative software.  In administrative software, like ERP, SIS, CRM and other acronyms, you can write inane manuals and hold week long training sessions (which cost boatloads), and you can hire consultants to come in and augment the broken system to make it do what it promised it would do in the first place.  Even more fun for these companies, you can hide a lot of the total cost of adoption in these services.

But obviously, in the face of consumer technology that works all the time and retains its allegiance to simplicity, usability, and stickiness, everyone in Higher Education is looking at their technology stack with a great degree of impatience.  Everyone I’ve ever talked to in Higher Education talks about most of their software as a POS, even the ones that do solve their problems or process their workflow.

Look at my friend Daniel Rabinovich’s presentation at Web 2.0.  Daniel is the CTO of the EBay of South America.  They are an enormous and successful company, and the presentation is all about the fight to reduce complexity and get your design down to its Simple, Usable, and Sticky essence.

When you’re making user-centered software, having a lot of features is almost impossible.  Casual users do not read manuals.  They do not go to training.  You can’t sell them consulting.

Well, actually, for some reason in Higher Ed there are consultants who train administrators to strategize around and use easy-to-use consumer technology like Facebook, but why they are so prolific or anyone finds them really necessary is beyond me.  I think it has something to do with the fact that administrators, before they dive in, assume that this kind of training and planning is necessary because of their past experience with technology. I’ve been asked many times over to come speak or do some consulting.  But I refuse out of principle.  There are plenty of great consultants in Higher Education.  But there’s a dearth of great products.  Introducing a great product is Inigral’s mission.)

So, forget your old RFP, here’s the new RFP:

• Don’t suck.
• Keep your software simple, usable, and sticky.
• Solve at least one problem for me really, really well.
• Don’t complicate my life.  It’s already complicated.
• Don’t stress me out.  I’m already stressed.
• Be human.  Give me a level of service that makes me like you.
• Surprise me with something elegant.

This post was written by Michael Staton