Most people (and especially younger people) don’t like to use the business software their company gives them. They think it sucks. This seems to be especially true in the market we’re in: “human capital software” or HCM. HCM software is business software ostensibly designed to help people improve and get stuff done. Yet, mostly it seems to frustrate and annoy people. It is notoriously sucky. Why is this so?

The immediate and obvious answer is design. In general, business software is not designed the same way and with as much attention to end-users as consumer software. Consumer software is built with one goal: to have people want to use it. Consumer software has no compliance requirement, no forced process, nobody asking you if you’ve filled out your TPS form. It has to be useful and make you want to use it, fast. Thus, the design challenge to engage people.

Unfortunately, most business software firms are not set up to focus software designers on building stuff people are engaged by. Instead, they are optimized to build software that sales people think software buyers want to see: lots of features, fancy charts, bland language, compliance & control focused, with every possible scenario modeled. The exact opposite of the design of the most engaging successful consumer software, which are defined by their minimalism and simplicity.

Why? There’s not much incentive in enterprise software to care about end users. If you’re focused on selling to buyers (HR pros) who don’t have to use your software (everyone else in the company) then your priorities are in the wrong place.

When you spend most of your time thinking about features and services that will make a small group of enterprise buyers satisfied you necessarily spend less effort on delighting users. The traditional business software model focuses the entire firm on the stated needs of the buyers of software at the expense of the problems of regular users.

The people who build and sell Enterprise HR software aren’t stupid or lazy. They’re well meaning people caught in a broken system that forces them to follow a crazy process – and build bad software. The good news is that we can rebuild it.

Problem: It’s designed by the way it’s sold

There’s an old expression: garbage in/garbage out. No matter how good your design team, a process that gets garbage inputs can only produce garbage outputs.

Who owns the inputs for the enterprise HR software you use? Odds are it isn’t you. It’s probably a committee. Today’s enterprise HR software comes from sales-centered companies, which means the inputs into their design process are owned by these committees of buyers and sales people.

We know all about this. We were part of building a successful company called Workbrain, which taught us the ins and outs of design-by-sale. We learned, for example, that the typical sales cycle goes something like this:

• Buyers are handed a problem to solve. They look around for an existing vendor with a widget to fill the problem-sized hole. Since the selection/implementation/deployment window is a one shot deal, they try to fit in every conceivable request that might or could come up. This all goes into a lengthy and complicated RFP, often co-written by one of the very firms who will end up getting the job.
• Widget makers pounce on the RFP and stretch their truths to fit over its pointy bits. Their salespeople are driven by numbers and the need to make them at any cost, so they commit to things their development and implementation teams often can’t deliver. They spend their time wining, dining, demo-ing, and selling fantastic and complicated software perfectly optimized to solve buyer problems.
• The implementation/development team is handed a steaming pile of crap work order. It almost never aligns with the roadmap for the product and includes all kinds of custom widgets for this particular client that turn the code base into spaghetti. Implementations take months (or even years), maintenance costs skyrocket to accommodate all of the custom code, and time consuming processes like ‘design’ fall off the schedule in order to meet unrealistic deadlines.
• The behemoth finally ships to its end users. The actual people who have to use the software — the managers and employees — are the last and least in getting a say in it. They’re an afterthought who now have to deal with the consequences, which they often do by rejecting the new system. The history of enterprise projects is littered with colossal failures and no group, from HR to supply chain management, is exempt.

Solution: Sell it differently

Software-as-a-Service (SaaS) companies like Rypple, Xactly, Zendesk, Atlassian, Box.net, Zuora, Xobni, MindTouch, and PBWorks have turned this model upside down. They essentially build consumer software for use in the enterprise, working closely with the end users to shape it to their needs and requirements. Buyers are still welcome to the table, but it’s no longer for romantic candle-lit dinners over lengthy RFPs. Now it’s about freemium, which gives users access to the actual application to try it out on real world data before they make a purchasing agreement. Deployment windows and lengthy implementations by teams of professional services people are a thing of the past. Enter your credit card and you’re up and running.

As Aaron Levi of Box.net recently wrote:

Rather than trying to build aggressive sales teams, many enterprise software startups are focusing on product execution as the best means of acquiring customers. The days of “elephant hunting” are quickly disappearing. Consumption and subscription-based billing, in contrast to the traditional licensing model, forces vendors to build amazing software that your customers need and use, not just software that you can sell better than anyone else. In today’s world, you only get paid if people are using your product.

Problem: It’s designed by the wrong people for the wrong people

The people who own the inputs design the software. Buyers may not realize it, but the many hours they spend crafting the perfect RFP are really spent designing the software that comes out the other end. The salespeople who unquestioningly say “Yes!” have unintentionally adopted the mantle of designers. No one is being nefarious on purpose, but merely acting out their roles in a very broken process.

But, this is not the way things should be done. Enterprise software should be designed the same way and with as much attention to end-users as consumer software. Consumer software is built with one goal: to have people want to use it by creating delightful experiences. It has to be useful and make you want to use it, fast. Consumer software has no compliance requirement, no forced process, nobody asking you if you’ve filled out your TPS form.

Therefore, the perfect RFP is no RFP. The perfect salesperson sells what the user has already started to use. The perfect design process starts and ends with the user, bypassing intermediaries.

Solution: the right people should design for the right people’s uses

Most people assume that the people who buy Rypple must be in HR because we talk about feedback, performance, and coaching. That’s a bad assumption. In reality 70% of Rypple buyers are not in HR. They’re CEOs, directors, managers – the people who spend most of their time managing teams of people. We built Rypple around their needs, not the HR department.

As a result, our users tell us about their Rypple love regularly and are happy to go out and be our best ambassadors. All of that happens because we care very deeply about our users having delightful experiences in our application. Designing for the end-user has decreased our cost of selling; people share what they like. The key to this is having dedicated designers – and a design thinking model – at the core of how you build your software.

We’re not alone in this. All of our colleagues at the cutting edge of the SaaS movement feel the same way and have dedicated User Experience (UX) design resources as part of their teams. This is not lip service (or even lipstick on a pig), but a fundamental part of the way we design and build software. We involve users before we do anything, we talk to them through the process, and we get their feedback and feature requests when we’re done. Most importantly: none of this critical information comes from buyers, RFPs, or competitive feature lists.

Problem: It’s bloated and unusable because it “has to be”

We’ve all heard the story about how sharks have to keep swimming or they die — their gills only work by having water flow across them, so no forward motion means no oxygen. Some sharks also lack flotation bladders, meaning they can’t “hover” in one place or they sink to the bottom.

Sound familiar? Enterprise software companies have no choice but to keep adding features in order to keep the revenues flowing. Upgrade fees are what keep them afloat, so their businesses are highly optimized to add new features, build next year’s monolithic release, and then force their trapped users to ante up. Our friends over at Kinaxis captured this perfectly in the third episode of their awesome Suitemates series:

That’s funny largely because it’s true. And that’s sad.

Solution: Kill features. Often.

We pride ourselves on taking features out. When’s the last time you heard a vendor say that? We’ve taken way more features out of Rypple than we’ve put in. We celebrate developers who can prove a feature should be killed.

And the way we prove a feature should be killed… mostly by watching what people actually use. Most enterprise software firms don’t do this. They put stuff in because they needed it to close deals. And then, it is there forever. Very few vendors go back (like consumer software vendors) to cull the features that most users don’t use.

To be clear: it’s not that we don’t want to build the features our customers are asking for. It’s that we understand the bigger picture of where Rypple is going and of the problems we’re trying to solve. A user may request a feature because it solves an immediate problem for them, while we see their individual problem as a symptom of a much larger issue. Implementing their request is a choice like everything else in our business. Spending time on that means not spending time on other things. The important thing is that we’re listening to them and they have a seat at our product design table.

UPDATE: Check out the follow-up post, 4 Steps to Becoming a Killer.

Shark photo by Jeff Kubina. Licensed under CC.