Jason's right: the buyers aren't the users

By Jason, I mean Jason Fried. His blog entry, "Why Enterprise Software Sucks" was a (deserved) wack in the face for those of us in the vendor space.

His answer to the question?

"The people who buy enterprise software aren’t the people who use enterprise software. That’s where the disconnect begins. And it pulls and pulls and pulls until the user experience is split from the buying experience so severely that the software vendors are building for the buyers, not the users. The experience takes a back seat to the feature list, future promises, and buzz words."

Well, exactly!

Jason’s point that, “The people who buy ... aren’t the people who use...” is the crux of the issue. As outside-in development practitioners know, there are four groups of stakeholders who dramatically affect most SW products. They are:

- the principals or business sponsors; these are the executive purchasers.

- the end users (who too often get stuck with hard to use UIs).

- the partners; these can be the enterprise IT shop operations folks, or VARs or ISVs who have to deal with the product too.

- the insiders; the folks inside the vendor software shop who have their own goals. Such as financials, architecture guidelines, process models, and the like.

(You can read more about outside-in development in the article in JavaWorld, or take a look at some of the work that Scott Sehlhorst has done to expand on outside-in development notions at TynerBlain.)

Back to Jason's post. Lots of people commented - he clearly hit a hot button. A couple of folks also pointed to the checklist mentality so prevalent in development. All about checklists, not about helping stakeholders meet their goals (especially end-users). Yes, all too often, development prioritization is all about feature lists.

One approach to deal with this is called “consumability.” The idea is to give teams credit for full fledged line items that serve to make a product more consumable to clients. This could mean easier install, better screens, easier debug or fix application. Ultimately all of these items and more.

We’ve put in place a metrics model (because SW development shops tend to be metrics driven) to keep the focus and to indicate release-to-release improvements. This is also a fundamental part of outside-in development.



(Image attribution: http://www.flickr.com/photo_zoom.gne?id=422215562&size=m; by Helico)