Unsuck the Enterprise

There’s something strangely appealing about trying to make enterprise software not universally despised. I guess I believe in a utopian vision where enterprise software is useful, usable, and (gasp!) enjoyable.

But until we get there, I think we can all agree that enterprise software mostly still sucks. And I think it sucks mainly for two reasons:

1. A lack of empathy for end users.
2. Too much legacy.

The lack of empathy issue is an understandable outcome of the process. See, we have this piece of software that we sell to company leaders, who care about things like control, configurability, compliance, and how many features the thing has. But the piece of software is mostly used by people who have very different needs.

The people who use the software every day only care about one thing: getting stuff done effectively. And if they can’t do that, a really ugly death spiral happens. As more people realize they can’t get anything done with the software, fewer people want to use it, until eventually no one uses it anymore.

In short, a buyer-focused product strategy builds for features and timelines. A user-focused product strategy builds for the Job-to-be-Done. Those are very different things.

Second, there’s too much legacy that drags large corporations down. There are waterfall processes masquerading as “agile,” well-established and well-defended functional silos, and many layers of bureaucracy. The result is something Jon Kolko sums up well in “Dysfunctional Products Come from Dysfunctional Organizations”:

How can we unsuck this predicament? Four things have helped me, and continue to help me as we make this transition toward designing in leaner, more empathetic ways.

Show the business value of design#section2

The 2014 Design Value Index report just came out, and it showed something quite compelling about design-led companies:

So we know design-led companies make more money. But is it also possible for design to save on development costs?

This chart is based on data from the book Software Engineering: A Practitioner’s Approach, and it shows how much cheaper it is to make changes to software before or during development. This quote from Marty Cagan also makes the point really well:

This is a way to tie user-centered design to both revenue increase and cost reduction. That’s an essential (and compelling) combination to get people to take design and user empathy seriously.

Shrink user-centered design to fit#section3

The biggest reservation that teams at enterprise software companies usually have about research and user experience work is that it takes too long and costs too much. Our job is to show teams that we can still get enormous value from UX methods, even if the budget is relatively small.

That’s the beauty of user-centered design: it shrinks to fit. Can’t do an ethnographic study? Do some phone interviews. Can’t build out a full HTML prototype? Make a clickable prototype in Axure, or heck, make a paper sketch. Can’t do a full usability study? Go to Starbucks Stumptown^¹ and ask someone if you can buy them a coffee in exchange for some feedback:

Turn sales into a product design function#section4

This is a big one. I’ve seen enough animosity between sales teams and product teams to last a lifetime. And both sides usually have legitimate points.

Product teams usually complain that the sales team sells stuff that doesn’t exist in the product—and even worse, promises release dates—which means they have no flexibility to base their roadmaps on user feedback and strategic direction.

Sales teams usually complain that product teams don’t see them as partners, and ignore their feedback constantly. This is a huge mistake, because sales teams often know the product’s capabilities and shortcomings the best of anyone in the organization. They should absolutely be part of the development process.

How do you do this? What’s worked for me is to provide a framework that allows both teams to speak a common language. For me, that framework, is Jobs-to-be-Done, and more specifically, the Product Forces Framework.

For someone to move from their existing behavior (a product they’re currently using) to new behavior (switching to a new product), there are two types of forces at work: progress-making forces, and progress-hindering forces.

Progress-making forces move people from their existing behavior to the new behavior, and consist of the push of the current situation (things they’re not happy with in the current product) and the pull of the new idea (things that sound appealing about the new product).

Progress-hindering forces hold people back from switching to new behavior. They consist of allegiance to the current behavior (things they really like about the current product) and the anxiety of the new solution (worries about learning curves and not being able to accomplish their goals with the new solution).

For someone to switch from an existing product to a new product, the progress-making forces have to be stronger than the progress-hindering forces. This might seem obvious, but applying this model to your product planning can inject an extremely healthy dose of reality. Is the product really that much better than a current solution? What does the new product have to do to overcome people’s allegiance to what they’re currently using?

This is not only a very good sales strategy, it’s also a good way to gather product feedback and come to agreement on what will make the product better (and help it sell better!).

As for putting a stop to selling features that don’t exist yet… I’ll be honest, that can take some time. But the more the sales team and the product team collaborate (keep reading for more on that) and have a common language, the better this will get as well. There is hope.

Break down silos through collaboration#section5

“Collaboration” has become a pretty overused word, and it’s now difficult to know exactly what we mean by it. So let’s be clear: just because you sat in a meeting with a different team doesn’t mean you collaborated. Collaboration, to me, means that you made something together. There is always some output during collaboration—from a solid idea that a designer can go work on, to personas that everyone worked on together, to piles of sticky notes that eventually become a customer journey map.

This kind of collaboration is especially important in the enterprise, where a designer’s role is often mostly about facilitation.

There are several techniques to encourage real product collaboration:

• Product discovery aligns teams on the user needs, business goals, and core competencies of the organization. It then goes through a process of divergent thinking (trying as many options as possible to solve a problem) and convergent thinking (narrowing down to the best options). The process also lets a team build consensus about the most important things to work on. For more, see my A List Apart article “Usable yet Useless: Why Every Business Needs Product Discovery.”
• Design studio gives teams an opportunity to try a wide variety of design options, and come to an agreement on the best solution to go with. It uses the entire team to iterate quickly to a hypothesis that can be prototyped and tested with users. For more on how to run a design studio, see Design Studio Workshop: Adding Up the Benefits.
• User research might seem like a solitary sport, but it’s not. Taking team members along on field visits and usability testing gives them a real sense of how users interact with the product. It also has the power to make them depressed about how difficult something is to use. But most people break through that really quickly, and move on to solving the problem effectively.

If I can further summarize a way to bring empathy-driven design to an enterprise, here are the methods that I try to communicate to teams I work with:

1. Show them why it’s important.
2. Show them it’s not going to make their lives difficult.
3. Give them a framework that covers the whole product.
4. Make them part of the process.

So if you’re someone who works in enterprise software, come a bit closer—I need to tell you something…

I know the work can be difficult. I know there are an infinite number of factors involved in getting product live, and sometimes what gets launched isn’t what you had in mind. I know there are sleepless nights about this sometimes. But don’t give up. Don’t think that enterprise design has to be boring or tasteless. With a little bit of effort and a lot of tenacity, it’s possible to create great enterprise product. We need you to make it happen, though. Who else is going to do it?